><COPYRIGHT.BODY>Cayenne Software, Inc. </COPYRIGHT.BODY
><COPYRIGHT.BODY>14 Crosby Drive </COPYRIGHT.BODY
><COPYRIGHT.BODY>Bedford, MA 01730 </COPYRIGHT.BODY
><COPYRIGHT.BODY>The information in this document is subject to change without notice. Cayenne Software, Inc. makes no warranty of any kind regarding this material and assumes no responsibility for any errors that may appear in this document. </COPYRIGHT.BODY
><COPYRIGHT.BODY>Terrain, S&truehy;CASE, and BACHMAN are registered trademarks of Cayenne Software, Inc. </COPYRIGHT.BODY
><COPYRIGHT.BODY>Cayenne, Cayenne Software, Cayenne Software, Inc., the Cayenne logo, Cayenne 2000, Cayenne DB2 Catalog Extract, Cayenne/GroundWorks Capture, Cayenne/GroundWorks Link, Cayenne/Business Rules Capture, Cayenne/DDL Generator, Cayenne/Function Point Analyst, Cayenne/Generator, Cayenne/Production DBA, Cayenne/Reports, Cayenne/Shared Work Manager, GroundWorks, Serveyor, Terrain 100/O, Terrain 100/S, Terrain AppGen for PowerBuilder, Terrain for DB2, TerrainMap, Terrain.net, and PepperSeed are trademarks of Cayenne Software, Inc. </COPYRIGHT.BODY
><COPYRIGHT.BODY>Cadre, Cadre Technologies, Inc., CASEteam, CodeMap, Data Driven Re&truehy;Engineering, DB Data Analyzer, Design by Example, DocConnect, Ensemble, ObjectTeam, PathMap, SoftAnalyst, SymTrace, TeamWork, the TeamWorklogo, TeamWork/ACCESS, TeamWork/Ada, TeamWork/C Rev, TeamWork/C Source Builder, TeamWork/DocGen, TeamWork/DSE, TeamWork/FORTRAN Rev, TeamWork/IM, TeamWork/IPSE_toolkit, TeamWork/RqT, TeamWork/RT, TeamWork/SA, TeamWork/SD, TeamWork/SIM, TeamWork/TestCase, and Unified CASE are registered trademarks of Cadre Technologies Inc., a wholly owned subsidiary of Cayenne Software, Inc. </COPYRIGHT.BODY
><COPYRIGHT.BODY>VantageTeam is a trademark of Cadre Technologies Inc., a wholly owned subsidiary of Cayenne Software, Inc. </COPYRIGHT.BODY
><COPYRIGHT.BODY>Any other company and product names used herein may be the trademarks or registered trademarks of their respective companies. </COPYRIGHT.BODY
><COPYRIGHT.BODY>RESTRICTED RIGHTS: Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFAR 252.227&truehy;7013 (48 CFR). Contractor/Manufacturer is Cayenne Software, Inc., 14 Crosby Drive, Bedford, Massachusetts 01730. </COPYRIGHT.BODY
><COPYRIGHT.BODY>NOTICE: Notwithstanding any other lease or license agreement that may pertain to or accompany the delivery of this restricted computer software, the rights of the Government regarding use, reproduction, and disclosure are as set forth in subparagraph (c)(1) and (2) of Commercial Computer Software&truehy;Restricted Rights clause at FAR 52.227&truehy;19.</COPYRIGHT.BODY
><SECTION><S.SECTION.HEAD>List of Book Titles</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>The collection of ObjectTeam online books is divided into seven sets. When you open the ObjectTeam online book collection, DynaText displays the seven set titles. When you open a set, DynaText displays all the books in that set.</B.BODY
><B.BODY>Below is a brief description of the books that appear in each set.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Installation Set</L.LABEL
><B.BODY>These books are most useful to the ObjectTeam administrator. </B.BODY
><RBW-PARABODY><CX5FX5FFILE.NAME>ObjectTeam System Administrator’s Guide</CX5FX5FFILE.NAME
>. Describes the architecture of the ObjectTeam product; the backup, restore and conversion tools provided with the product; and how to maintain the ObjectTeam environment.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>User Set</L.LABEL
><B.BODY>These books are intended for all ObjectTeam users.</B.BODY
>. Describes the primary features of ObjectTeam and provides a brief tutorial of the product. If you are a new user, this book is strongly recommended as your starting point.</RBW-PARABODY
>. Describes the project management features of the product: version and configuration management, user environment settings, use of corporate groups, and access control.</RBW-PARABODY
> Describes the interface of the Cayenne repository and the syntax of the object&truehy;oriented Tcl extensions used to access the repository.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Integrations Set</L.LABEL
><B.BODY>These books are intended for users of ObjectTeam integrations. Use the book appropriate for your product.</B.BODY
> Describes the integration of ObjectTeam with Razor, a version control management tool.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
></SECTION
><SECTION><S.SECTION.HEAD>About the Documentation</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Platform differences</L.LABEL
><B.BODY>Most ObjectTeam features are available on both UNIX and Microsoft Windows. Where a guide applies to both platforms, paths are represented in the Microsoft style, in which a backslash (<CX5FX5FPROCEDURE.NAME>\</CX5FX5FPROCEDURE.NAME
>) separates individual directories. For instance:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Object names and user interface features, such as commands, window titles, buttons, and field labels</CELLBODY
></ENTRY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>The Class Diagram editor...</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Pipe symbol ( | )</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Successive menu items</CELLBODY
><RBW-PARABODY>Cayenne Training/Consulting Services can help you get the most out of Cayenne products by providing information about training courses and consulting services.</RBW-PARABODY
><RBW-PARABODY>The Informix OnLine CD (if you are using Informix as your repository)</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>In addition, to complete the installation successfully, for the computer onto which you intend to install the ObjectTeam server software, you should have the following:</B.BODY
><B.BODY>To decide the type of installation that you want to perform, you must first determine which computers will be running each of these sets of software.</B.BODY
><B.BODY>This section helps you answer these questions. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>ObjectTeam client and server software</L.LABEL
><B.BODY>ObjectTeam has a <CX5FX5FTERM>client/server</CX5FX5FTERM
> design. This means that the software can be distributed over a network of computers, with client computers and server computers executing different types of processes.</B.BODY
><B.BODY>Client computers run the ObjectTeam <CX5FX5FTERM>client software</CX5FX5FTERM
>. End&truehy;users use the client software, for example, to edit diagrams, run reports, and generate code. Model data created by users is stored centrally in a database on the server. Generated code and documents are stored on a user’s own machine.</B.BODY
><B.BODY>A client computer can be a UNIX workstation or a PC running Windows 95 or Windows NT.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Server computers</SL.SUBLABEL
><B.BODY>A server computer runs the ObjectTeam <CX5FX5FTERM>server software</CX5FX5FTERM
>, and database software for storing users’ project data. The server software is usually started at system boot time, and does things like interact with the database and coordinate requests from clients. Users generally do not directly invoke server software.</B.BODY
><B.BODY>A server computer is a UNIX workstation. </B.BODY
><B.BODY>A client/server configuration allows multiple users to work simultaneously with ObjectTeam, and thus share data. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>ObjectTeam database</L.LABEL
><B.BODY>ObjectTeam stores project data in a database. The database management system (DBMS) used is either Informix or Oracle. You must install the database software before installing ObjectTeam. </B.BODY
><B.BODY>If you are using Informix, then the Informix OnLine software is supplied on a separate CD in your package. Oracle software is not supplied with ObjectTeam. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>ObjectTeam license manager</L.LABEL
><B.BODY>The various features of ObjectTeam, such as browsers and code generators, are all licensed individually. In ObjectTeam, a licensing system maintains a count of the usage of each feature. The license management system used by ObjectTeam is FLEXlm from Globetrotter Software. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Installation types</L.LABEL
><B.BODY>ObjectTeam distinguishes between the following types of machine:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>This is a machine that runs all the ObjectTeam server software as well as the client software. There must always be a single Master server present in your network. </CELLBODY
><CELLBODY>The Master server can also run the DBMS software and the License server software.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>This is an optional server running on a separate machine from the Master server. You can choose to install one or more Slave servers to distribute the server load. </CELLBODY
><CELLBODY>A Slave server runs a subset of the ObjectTeam server and DBMS software as well as the ObjectTeam client software.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>This is a machine that only runs the client software. </CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example configurations</L.LABEL
><B.BODY>Which installation you perform on a machine depends on what kind of overall configuration in which you want to run ObjectTeam. The following examples show some default configurations covered by the instructions in this guide.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Standalone</SL.SUBLABEL
><B.BODY>This is the simplest configuration. A single machine is configured as Master server, and is running the ObjectTeam server software, ObjectTeam client software, DBMS software and FLEXlm license software. </B.BODY
><B.BODY>In this example, a machine configured as Master server is running the ObjectTeam server and client software and is serving multiple client machines. The DBMS software and FLEXlm license software been installed on separate machines from the ObjectTeam Master server.</B.BODY
><B.BODY>The easiest way to configure an ObjectTeam client is to mount the ObjectTeam product files from the Master server on the client machine. Alternatively you can install a separate set of product files on the client.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Distributed Master and Slave servers</SL.SUBLABEL
><FA.FIGURE.ANCHOR>In this example, to spread the load on the Master server, a separate machine has been configured as an ObjectTeam Slave server and is serving several of its own clients. </FA.FIGURE.ANCHOR
><B.BODY>The easiest way to configure a Slave server is to mount both the ObjectTeam product files from the Master server and the DBMS files from the machine running the DBMS. This is useful where you want to reduce the load on the Master server’s CPU, but your network is not a bottleneck. Alternatively, to further reduce network traffic between the Master and Slave, you can install a separate set of ObjectTeam product files on the Slave server and configure the Slave server as a DBMS <CX5FX5FTERM>client</CX5FX5FTERM
>.</B.BODY
><B.BODY>ObjectTeam client machines can run off either the Master or Slave server. By default, the maximum number of client computers you can attach to a server is unlimited.</B.BODY
><B.BODY>For details on the requirements for these packages, read the Certification matrix. Hardware requirements for your workstation are displayed during the installation procedure. </B.BODY
><B.BODY>You should also read the ObjectTeam Read Me First Notes before starting installation. These contain last&truehy;minute product information that may affect the installation. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Reading the ObjectTeam Certification matrix and Read Me First Notes</L.LABEL
>Network Software and Daemon Processes</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Network Software</L.LABEL
><B.BODY>If the installation is taking place in a multi&truehy;computer environment, i.e., if files need to be sent over a network, the correct network software must be installed and working. Most of the checks also apply to standalone installations. The correct daemon processes must also be active. The following network software and daemon processes are needed:</B.BODY
><RBW-PARABODY>If NIS is not installed, on each machine that is to run ObjectTeam, check that the /etc/inet/hosts file (Solaris) or the /etc/hosts file (HP&truehy;UX, AIX, D&truehy;UX) exists and that it contains entries for each host running ObjectTeam.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Check Users</L.LABEL
><B.BODY>Check whether the users are known on the platforms used by the product:</B.BODY
><B.BODY>This chapter describes how to carry out a standard installation of ObjectTeam on UNIX machines. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Upgrading</SL.SUBLABEL
><B.BODY>If you are upgrading from a previous ObjectTeam installation, go to Chapter 3, Upgrading from a Previous Release, instead.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Installing on Windows</SL.SUBLABEL
><B.BODY>For details on how to install ObjectTeam on PCs running Windows 95 or Windows NT, refer to the <CX5FX5FTITLE>ObjectTeam Installation Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> <CX5FX5FTERM>for Microsoft Windows</CX5FX5FTERM
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Which installation to perform</L.LABEL
><B.BODY>This chapter covers the following installations:</B.BODY
><B.BODY>Before you install ObjectTeam, you must decide which machine you want to make Master server. There can only be one Master server in your system. The Master server can also run the client software. </B.BODY
><B.BODY>In this chapter the installation directory is indicated as <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
>. The recommended location is /usr/cayenne/objectteam. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Reading the Read Me First Notes</L.LABEL
><B.BODY>The Read Me First Notes contain last&truehy;minute product information that may affect the installation. You must read these notes before starting installation.</B.BODY
><B.BODY>To read the Read Me First Notes, open the file /cdrom/readme.txt in a text editor, or open the file /cdrom/readme.htm in a Web browser.</B.BODY
><B.BODY>For details of the supported Operating Systems and DBMS versions, open the file /cdrom/certify.htm in a web browser.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Before you start</L.LABEL
><B.BODY>Before you start, you should have created a user cayenne and installed DynaText as described in the CD insert.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY><CX5FX5FFILE.NAME>Oracle users only: <RBW-XREF REFID="28079" TYPE="XREF-TEXTCOPY">Create an Oracle User and Tablespace</RBW-XREF
><B.BODY>This step only applies if you are using Informix as your repository database.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>If you do not have an Informix installation</SL.SUBLABEL
><B.BODY>A version of Informix for your UNIX platform is supplied with your ObjectTeam package. For details on how to install Informix, refer to Appendix C, Installing Informix.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>If you already have an Informix installation</SL.SUBLABEL
><B.BODY>If you already have Informix installed, read Appendix C, Installing Informix, for details on configuring your Informix installation to work with ObjectTeam.</B.BODY
><B.BODY>Once you have installed or configured Informix, proceed to <RBW-XREF REFID="38599" TYPE="XREF-TEXTCOPY">Install Your License</RBW-XREF
><LT.LIST.TEXT>where Demo is the SQL*Net database specification string.</LT.LIST.TEXT
><LT.LIST.TEXT>A successful connection results in a prompt like the following:</LT.LIST.TEXT
><EM.EXAMPLE.MONO>sql></EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Creating an Oracle tablespace</L.LABEL
><B.BODY>You must create a new Oracle tablespace. This tablespace will be used as the default tablespace of the Oracle User to be created. The Oracle User will contain the Cayenne repository. Otherwise the Cayenne repository will be created in the “system” tablespace reserved for system data.</B.BODY
><B.BODY>The following shows an example of creating a new tablespace:</B.BODY
><B.BODY>This creates a tablespace called “cayennesp”. In addition, the file cayennesp01.dbf is created in your oradata directory. The oradata directory is created at Oracle installation time. Its location can vary.</B.BODY
><B.BODY>To install ObjectTeam 7.1.1, you must configure licensing. How you do this depends on whether you have a temporary or permanent license:</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Temporary license</SL.SUBLABEL
><B.BODY>You must install your ObjectTeam license as described in this section.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Permanent license</SL.SUBLABEL
><B.BODY>You must install a license server, as decribed in Appendix B, Configuring a License Server. After you have done that, continue to <RBW-XREF REFID="13560" TYPE="XREF-TEXTCOPY">Install the ObjectTeam Product Files</RBW-XREF
><RBW-PARABODY>Via email, copy and paste the new feature information into an empty text file and save it as <CX5FX5FFILE.NAME>/usr/cayenne/flexlm/license/cayenne.dat</CX5FX5FFILE.NAME
><RBW-PARABODY>Via fax, enter the new feature information by hand into an empty text file, and save it as <CX5FX5FFILE.NAME>/usr/cayenne/flexlm/license/cayenne.dat</CX5FX5FFILE.NAME
></RBW-PARABODY
></LB2.LIST.BULLET.2
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Obtaining a permanent license</L.LABEL
><B.BODY>Your temporary license allows you to install and run ObjectTeam for a limited period. </B.BODY
><B.BODY>If after installing ObjectTeam, you decide you want to make your installation permanent, you need to obtain a permanent license. For details on how to obtain a permanent license, see Appendix B, Configuring a License Server. </B.BODY
><B.BODY>On every (UNIX) machine on which ObjectTeam is used, an internet service must be configured for communication with Broker processes. This is done using the services file. </B.BODY
><B.BODY>The services file defines the service/port number combination. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Contents of the services file</SL.SUBLABEL
><B.BODY>The services file contains a single entry for each known service on the network. Each line in the file contains the following information:</B.BODY
><EWM.EXAMPLEW.MONO>servicename port_number/protocol name_aliases # some comments</EWM.EXAMPLEW.MONO
> and <CX5FX5FVARIABLE>port_number</CX5FX5FVARIABLE
> are arbitrary, they must be unique within the file and they must be identical on all computers running ObjectTeam server or client software. </B.BODY
><B.BODY>To prevent conflicts, most computers running in a network are installed with a Network Information System. In such a system all network information is stored centrally in the services file. Computers can access the information by sending a request to the Network Information Server (NIS). </B.BODY
><B.BODY>In the format shown above for the services file, <CX5FX5FVARIABLE>name_aliases</CX5FX5FVARIABLE
> is optional and can be added. However, this facility is not supported in ObjectTeam. All text after the “<CX5FX5FFILE.NAME>#”</CX5FX5FFILE.NAME
> is interpreted as comments and can be used to specify for which utility the service has been added.</B.BODY
><B.BODY>Before you can use ObjectTeam, you must set various ObjectTeam environment variables. This is done by running the m4create_env script.</B.BODY
><RBW-PARABODY>If you are running the license server software on this machine, or your license file is stored locally, the default is /usr/cayenne/flexlm/license/cayenne.dat. </RBW-PARABODY
><RBW-PARABODY>If you are running the license server software on another machine, you must identify the port being used by the license service on the server and the host name of the server. On the license server, open the license file cayenne.dat in a text editor. The port appears as the last field on the SERVER line. Cayenne Software uses the port number 7126 by default. For example:</RBW-PARABODY
>If LM_LICENSE_FILE is set in your environment for some other vendor’s software, enter the displayed path with the location of your ObjectTeam license file appended to the end, separated from the previous path by a colon (:).</N2.NOTE.2
><RBW-PARABODY>You are asked to specify the type of installation. Options are Master server, Slave server, or Client. Accept the default of Master.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>A warning is displayed that various environment files are created by the script.</LR.LIST.RESULT
><RBW-PARABODY>You are asked to specify the value of the LC_CTYPE environment variable. The default is C. Press return to accept the default or specify a value.</RBW-PARABODY
><RBW-PARABODY>You are asked to specify the value of the LC_COLLATE environment variable. The default is C. Press return to accept the default or specify a value.</RBW-PARABODY
> You are asked to specify the value of the LC_NUMERIC environment variable. The default is C. Press return to accept the default or specify a value. Note that this may affect other numeric&truehy;based applications.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The default printer is displayed. </LR.LIST.RESULT
><RBW-PARABODY>You are asked if you want to change the default printer or printer command for ASCII printing. Specify the printer command or change the default printer. </RBW-PARABODY
><RBW-PARABODY>You are asked if you want to change the default printer or printer command for graphical (PostScript) printing. Specify the printer command or change the default printer. </RBW-PARABODY
><RBW-PARABODY>For FrameMaker users, you are asked if you want to accept the default version of FrameMaker (International English) or if you want to change to the US English version. Press Return to accept the default or type N to change to the US version.</RBW-PARABODY
><RBW-PARABODY>You are asked what kind of license you have. Press Return if you have a Temporary license or type 2 if you have a Permanent license.</RBW-PARABODY
><RBW-PARABODY>You are asked for the name of your repository DBMS home directory. The default is the directory you set in INFORMIXDIR or ORACLE_HOME. Press Return to accept the default.</RBW-PARABODY
><RBW-PARABODY>If you are using Oracle as your repository, you are asked to specify the Oracle SID. The default is the value you set in ORACLE_SID. Press Return to accept the default.</RBW-PARABODY
><RBW-PARABODY>If you are using Informix as your repository, you are asked to specify the name of the Informix server. The default is the value you set in INFORMIXSERVER. Press Return to accept the default or type 2 to change the server.</RBW-PARABODY
><RBW-PARABODY>If you have a $HOME/.Xdefaults file, merge the file /usr/cayenne/objectteam/etc/Xdefaults with your existing .Xdefaults file. </RBW-PARABODY
><RBW-PARABODY>While logged on to the Master server as cayenne, check that the Cayenne Repository Broker service (ot_broker) is running. If it is not, enter:</RBW-PARABODY
><RBW-PARABODY>Fill in the fields, then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>A Monitor window is started which runs the dbserver command to create the repository. If the repository is created successfully, it becomes selected in the Corporate Management tool.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Fields</L.LABEL
><B.BODY>The New Repository dialog always contains the following fields:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The name of your repository. This will appear as the corporate object (that is the top level) in the ObjectTeam Browser.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Make this repository the default</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>This makes this repository the one that will be displayed in your Browser.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Directory in which to create the repository</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The full pathname of the directory in which the file&truehy;system part of the repository is stored. The recommended location is /usr/cayenne/repos.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Optional. The directory in which all generated files, such as code files, are stored. The value specified here is assigned to the corporate&truehy;level File System Path Part property. Cayenne strongly recommends that you specify a directory on a network drive.</CELLBODY
>. If SQL*Net is installed, specify the Oracle database specification string (ORACLE_SID), e.g., oracle7. </CELLBODY
><CELLBODY>If SQL*Net is not installed, enter “default” in this field and set the ORACLE_SID environment variable to the system identifier of the database that you want to use.</CELLBODY
><B.BODY>Once you have tested your installation, it is convenient to configure the Cayenne Repository broker and license server to start automatically at boot time. </B.BODY
><B.BODY>You can enter any numbers after S and K as long as startup and shutdown are done in the correct order. It is important that the DBMS server start before the ot_broker starts, and that the ot_broker stop before the DBMS server stops.</B.BODY
><RBW-PARABODY>If the license server is running on this machine, check the location of the FLEXlm installation and the ObjectTeam license file:</RBW-PARABODY
><RBW-PARABODY>If this host is the license server, look for the following text:</RBW-PARABODY
></LN.LIST.NUM
><EWM.EXAMPLEW.MONO># If this script is run on the host used as license server,</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO># uncomment one of the next two start&truehy;up instructions and</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO># uncomment the line with ‘lmdown’ at the end of this file.</EWM.EXAMPLEW.MONO
><LT.LIST.TEXT>and uncomment the appropriate lines depending on whether you want the license server to run with logging (default) or not. Do not uncomment these lines if you have a temporary license.</LT.LIST.TEXT
><RBW-PARABODY>Access the Master server’s <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
> directory and the DBMS installation by mounting them using NFS. This is useful where you want to reduce the load on the Master server’s CPU, but your network is not a bottleneck.</RBW-PARABODY
><RBW-PARABODY>Install the ObjectTeam product files and a DBMS client locally on the Slave server machine. This has the advantage of further reducing network traffic between the Master and Slave.</RBW-PARABODY
> is mounted, the directory hierarchy, including the location of the repository directory (the directory where all repository files reside), is automatically the same on both the Master server and Slave server. If the ObjectTeam product files are installed locally on the Slave server, the repository directory on the Master server must be mounted on the Slave in the same location.</B.BODY
><B.BODY>Before you can install an ObjectTeam Slave server, you must have installed an ObjectTeam Master server, as described in <RBW-XREF REFID="17595" TYPE="XREF-TEXTCOPY">Installing an ObjectTeam Master Server</RBW-XREF
>.</B.BODY
><B.BODY>The user cayenne must also be known on the Slave server.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section covers the following topics:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="29700" TYPE="XREF-TEXTCOPY">Accessing a Mounted Installation from the Slave Server&rbwtab;2–19</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="28210" TYPE="XREF-TEXTCOPY">Installing the Product Files on the Slave Server&rbwtab;2–22</RBW-XREF
>Accessing a Mounted Installation from the Slave Server</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This is the simplest way of installing a Slave server. With this type of installation, you access the ObjectTeam installation on the Master server.</B.BODY
><B.BODY>The Master must be configured as an NFS server and the file system to be mounted must be exported.</B.BODY
><B.BODY>You can enter any numbers after S and K as long as startup and shutdown are done in the correct order. It is important that the DBMS server start before the ot_broker starts, and that the ot_broker stop before the DBMS server stops.</B.BODY
><RBW-PARABODY>If this host is the license server, look for the following text:</RBW-PARABODY
></LN.LIST.NUM
><EWM.EXAMPLEW.MONO># If this script is run on the host used as license server,</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO># uncomment one of the next two start&truehy;up instructions and</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO># uncomment the line with ‘lmdown’ at the end of this file.</EWM.EXAMPLEW.MONO
><LT.LIST.TEXT>and uncomment the appropriate lines depending on whether you want the license server to run with logging (default) or not. Do not uncomment these lines if you have a temporary license.</LT.LIST.TEXT
><RBW-PARABODY>To access the product documentation, select Help | Product Documentation in the ObjectTeam Browser.</RBW-PARABODY
></P.PROCEDURE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Running ObjectTeam as a normal user on the Slave server</L.LABEL
><B.BODY>If you want to work on the Slave server as a normal user, you must configure a client, as described in <RBW-XREF REFID="12020" TYPE="XREF-TEXTCOPY">Accessing a Mounted Installation from the Client</RBW-XREF
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Set the broker to start automatically</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Mount the repository directory</L.LABEL
><B.BODY>Mount the repository directory from the Master server. The repository directory must be mounted on the Slave in the same location as on the Master server.</B.BODY
><RBW-PARABODY>When you installed the Master server, you added a service in the services file on the Master service. If NIS is not used, you must add a service for ObjectTeam on the Slave server also:</RBW-PARABODY
><RBW-PARABODY>If you are running the license server software on this machine, or your license file is stored locally, the default is /usr/cayenne/flexlm/license/cayenne.dat. </RBW-PARABODY
><RBW-PARABODY>If you are running the license server software on another machine, you must identify the port being used by the license service on the server and the host name of the server. On the license server, open the license file cayenne.dat in a text editor. The port appears as the last field on the SERVER line. Cayenne Software uses the port number 7126 by default. For example:</RBW-PARABODY
>If LM_LICENSE_FILE is set in your environment for some other vendor’s software, enter the displayed path with the location of your ObjectTeam license file appended to the end, separated from the previous path by a colon (:).</N2.NOTE.2
><RBW-PARABODY>You are asked to specify the type of installation. Options are Master server, Slave server, or Client. Select Slave server.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>A warning is displayed that various environment files are created by the script.</LR.LIST.RESULT
><RBW-PARABODY>You are asked to specify the value of the LC_CTYPE environment variable. The default is C. Press return to accept the default or specify a value.</RBW-PARABODY
><RBW-PARABODY>You are asked to specify the value of the LC_COLLATE environment variable. The default is C. Press return to accept the default or specify a value.</RBW-PARABODY
> You are asked to specify the value of the LC_NUMERIC environment variable. The default is C. Press return to accept the default or specify a value. Note that this may affect other numeric&truehy;based applications.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The default printer is displayed. </LR.LIST.RESULT
><RBW-PARABODY>You are asked if you want to change the default printer or printer command for ASCII printing. Specify the printer command or change the default printer. </RBW-PARABODY
><RBW-PARABODY>You are asked if you want to change the default printer or printer command for graphical (PostScript) printing. Specify the printer command or change the default printer. </RBW-PARABODY
><RBW-PARABODY>For FrameMaker users, you are asked if you want to accept the default version of FrameMaker (International English) or if you want to change to the US English version. Press Return to accept the default or type N to change to the US version.</RBW-PARABODY
><RBW-PARABODY>You are asked what kind of license you have. Press Return if you have a Temporary license or type 2 if you have a Permanent license.</RBW-PARABODY
><RBW-PARABODY>You are asked for the name of your repository DBMS home directory. The default is the directory you set in INFORMIXDIR or ORACLE_HOME. Press Return to accept the default.</RBW-PARABODY
><RBW-PARABODY>If you are using Oracle as your repository, you are asked to specify the Oracle SID. The default is the value you set in ORACLE_SID. Press Return to accept the default.</RBW-PARABODY
><RBW-PARABODY>If you are using Informix as your repository, you are asked to specify the name of the Informix server. The default is the value you set in INFORMIXSERVER. Press Return to accept the default or type 2 to change the server.</RBW-PARABODY
><B.BODY>You can enter any numbers after S and K as long as startup and shutdown are done in the correct order. It is important that the DBMS server start before the ot_broker starts, and that the ot_broker stop before the DBMS server stops.</B.BODY
><RBW-PARABODY>If the license server is running on this machine, check the location of the FLEXlm installation and the ObjectTeam license file:</RBW-PARABODY
><RBW-PARABODY>If this host is the license server, look for the following text:</RBW-PARABODY
></LN.LIST.NUM
><EWM.EXAMPLEW.MONO># If this script is run on the host used as license server,</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO># uncomment one of the next two start&truehy;up instructions and</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO># uncomment the line with ‘lmdown’ at the end of this file.</EWM.EXAMPLEW.MONO
><LT.LIST.TEXT>and uncomment the appropriate lines depending on whether you want the license server to run with logging (default) or not. Do not uncomment these lines if you have a temporary license.</LT.LIST.TEXT
><RBW-PARABODY>Installed an ObjectTeam Master server, as described in <RBW-XREF REFID="17595" TYPE="XREF-TEXTCOPY">Installing an ObjectTeam Master Server</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section covers the following topics:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="12020" TYPE="XREF-TEXTCOPY">Accessing a Mounted Installation from the Client&rbwtab;2–30</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="18541" TYPE="XREF-TEXTCOPY">Installing the Product Files on the Client&rbwtab;2–32</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><SUBSECTION><SS.SUBSEC.HEAD>Accessing a <RBW-ANCHOR ID="12020"></RBW-ANCHOR
>Mounted Installation from the Client</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This is the simplest way of installing a client. With this type of installation, you access the ObjectTeam installation on the Master server or Slave server. </B.BODY
><B.BODY>The Master must be configured as an NFS server and the file system to be mounted must be exported.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to access the mounted Master server installation</L.LABEL
><RBW-PARABODY>Log in to the client as yourself, and copy either of the environment files .m4_profile or .m4_login from /usr/cayenne to your home directory, depending on which shell you use.</RBW-PARABODY
><RBW-PARABODY>If you are running the license server software on this machine, or your license file is stored locally, the default is /usr/cayenne/flexlm/license/cayenne.dat. If you are running the license server software on another machine, you must identify the port being used by the license service on the server and the host name of the server. On the license server, open the license file cayenne.dat in a text editor. The port appears as the last field on the SERVER line. Cayenne Software uses the port number 7126 by default. For example:</RBW-PARABODY
>If LM_LICENSE_FILE is set in your environment for some other vendor’s software, enter the displayed path with the location of your ObjectTeam license file appended to the end, separated from the previous path by a colon (:).</N2.NOTE.2
><RBW-PARABODY>You are asked to specify the value of the LC_CTYPE environment variable. The default is C. Press return to accept the default or specify a value.</RBW-PARABODY
><RBW-PARABODY>You are asked to specify the value of the LC_COLLATE environment variable. The default is C. Press return to accept the default or specify a value.</RBW-PARABODY
> You are asked to specify the value of the LC_NUMERIC environment variable. The default is C. Press return to accept the default or specify a value. Note that this may affect other numeric&truehy;based applications.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The default printer is displayed. </LR.LIST.RESULT
><RBW-PARABODY>You are asked if you want to change the default printer or printer command for ASCII printing. Specify the printer command or change the default printer. </RBW-PARABODY
><RBW-PARABODY>You are asked if you want to change the default printer or printer command for graphical (PostScript) printing. Specify the printer command or change the default printer. </RBW-PARABODY
><RBW-PARABODY>For FrameMaker users, you are asked if you want to accept the default version of FrameMaker (International English) or if you want to change to the US English version. Press Return to accept the default or type N to change to the US version.</RBW-PARABODY
><RBW-PARABODY>You are asked what kind of license you have. Press Return if you have a Temporary license or type 2 if you have a Permanent license.</RBW-PARABODY
><RBW-PARABODY>You are asked for the broker port used to connect to the server. The default is 1825. This must agree with the number you specified when installing the Master server.</RBW-PARABODY
><B.BODY>This chapter describes how to upgrade an existing installation of ObjectTeam from versions 5.1.1, 5.2.1 or 6.1.1 to version 7.1.1 on UNIX machines.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Upgrading on Windows</SL.SUBLABEL
><B.BODY>For details on how to upgrade ObjectTeam on PCs running Windows 95 or Windows NT, refer to the <CX5FX5FTITLE>ObjectTeam Installation Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> <CX5FX5FTERM>for Microsoft Windows</CX5FX5FTERM
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Before you start</L.LABEL
><B.BODY>Before starting this upgrade procedure, you must have:</B.BODY
><B.BODY>In this chapter, the installation directory for the ObjectTeam product files is indicated as <CX5FX5FTERM>M4_home</CX5FX5FTERM
>. By default, this is /usr/cayenne/objectteam, however you can install ObjectTeam elsewhere on your machine.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Reading the Read Me First Notes</L.LABEL
><B.BODY>The Read Me First Notes contain last&truehy;minute product information that may affect the installation. You must read these notes before starting installation.</B.BODY
><B.BODY>To read the Read Me First Notes, open the file /cdrom/readme.txt in a text editor, or open the file /cdrom/readme.htm in a Web browser.</B.BODY
><B.BODY>For details of the supported Operating Systems and DBMS versions, open the file /cdrom/certify.htm in a web browser.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY><CX5FX5FFILE.NAME>Oracle users only: <RBW-XREF REFID="32991" TYPE="XREF-TEXTCOPY">Create an Oracle User and Tablespace</RBW-XREF
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="26225" TYPE="XREF-TEXTCOPY">Move Your Repository Directory and Convert Your Data</RBW-XREF
><B.BODY>In ObjectTeam, a repository consists of a database part and a file system part. The directory in which the file system part is stored is called the repository directory. This contains individual directories for each repository, called corporate directories. </B.BODY
><B.BODY>To convert your repository data to ObjectTeam 7.1.1, you must first dump the data from each repository to disk. The ObjectTeam dump facility dumps data from a single repository into its corresponding corporate directory. The result is a structure like the following:</B.BODY
>By default, your 5.x or 6.1.1 repositories were created in the <CX5FX5FTERM>M4_home</CX5FX5FTERM
>\corproot<CX5FX5FFILE.NAME> </CX5FX5FFILE.NAME
>directory. If you created a repository in some other directory, either within or outside <CX5FX5FTERM>M4_home</CX5FX5FTERM
>, you can choose to dump the database part to that directory instead. Make sure you also back up that directory after dumping your repository. </N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Upload user environment files</L.LABEL
><B.BODY>Before you dump your repository you should make sure it is complete by uploading the working versions of files in the file system, such as generated source files.</B.BODY
>Back Up Your ObjectTeam Installation</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Once you have dumped and backed up all repositories, you should make a complete backup of your ObjectTeam installation AND your repository databases. If for any reason you want to go back to your previous installation you can then restore your entire environment.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>6.1.1 upgrade only</SL.SUBLABEL
><B.BODY>The upgrade also requires that you move your ObjectTeam installation to a separate location on the same disk.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Backing up your ObjectTeam installation </L.LABEL
>If you have dumped any repositories to directories outside <CX5FX5FTERM>M4_home</CX5FX5FTERM
>, be sure to back up these directories as well.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Copying your ObjectTeam installation to a separate location</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>6.1.1 upgrade only</SL.SUBLABEL
><B.BODY>ObjectTeam 7.1.1 installs by default into /usr/cayenne/objectteam. If you are upgrading from ObjectTeam 6.1.1, and your installation is in /usr/cayenne/objectteam, you need to move your installation to a separate location for the upgrade to work properly.</B.BODY
><B.BODY>Install Informix 7.2 as described in Appendix C, Installing Informix.</B.BODY
><B.BODY>You can install Informix 7.2 on the same node on which Informix 7.1 was installed. Before installing Informix 7.2, shut down any ObjectTeam and Informix processes. It is recommended that you do not delete the Informix 7.1 directory structure and database until you are sure the upgrade has been successful.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Installing Oracle 7.3.x</L.LABEL
><B.BODY>Install Oracle 7.3.x as described in your Oracle documentation.</B.BODY
><B.BODY>For the exact version number, refer to the certification matrix on the CD.</B.BODY
><LT.LIST.TEXT>where Demo is the SQL*Net database specification string.</LT.LIST.TEXT
><LT.LIST.TEXT>A successful connection results in a prompt like the following:</LT.LIST.TEXT
><EM.EXAMPLE.MONO>sql></EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Creating an Oracle tablespace</L.LABEL
><B.BODY>You must create a new Oracle tablespace. This tablespace will be used as the default tablespace of the Oracle User to be created. Otherwise the ObjectTeam repository will be created in the “system” tablespace reserved for system data.</B.BODY
><B.BODY>The following shows an example of creating a new tablespace:</B.BODY
><B.BODY>This creates a tablespace called “cayennesp”. In addition, the file cayennesp01.dbf is created in your oradata directory. The oradata directory is created at Oracle installation time. Its location can vary.</B.BODY
><B.BODY>To upgrade to ObjectTeam 7.1.1, you must configure licensing. How you do this depends on whether you have a temporary or permanent license:</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Temporary license</SL.SUBLABEL
><B.BODY>You must install your ObjectTeam license as described in this section</B.BODY
> You must install a license server, as decribed in Appendix B, Configuring a License Server. After you have done that, continue to <RBW-XREF REFID="15578" TYPE="XREF-TEXTCOPY">Install the ObjectTeam Product Files</RBW-XREF
> You should already have a license server installed. If you have received a permanent license with your ObjectTeam 7.1.1 package, make sure you have write permission to /usr/cayenne/flexlm/license, then follow the instructions in <RBW-XREF REFID="21534" TYPE="XREF-TEXTCOPY">Installing a Permanent License on page B–10</RBW-XREF
>, then proceed to <RBW-XREF REFID="15578" TYPE="XREF-TEXTCOPY">Install the ObjectTeam Product Files</RBW-XREF
><RBW-PARABODY>Via email, copy and paste the new feature information into an empty text file and save it as <CX5FX5FFILE.NAME>/usr/cayenne/flexlm/license/cayenne.dat</CX5FX5FFILE.NAME
><RBW-PARABODY>Via fax, enter the new feature information by hand into an empty text file, and save it as <CX5FX5FFILE.NAME>/usr/cayenne/flexlm/license/cayenne.dat</CX5FX5FFILE.NAME
><B.BODY>Before you can use ObjectTeam, you must set various ObjectTeam environment variables. This is done by running the m4create_env script.</B.BODY
><RBW-PARABODY>If you are running the license server software on the Master server, the default is your existing setting of LM_LICENSE_FILE. If you do not have this variable set, the default is /usr/cayenne/flexlm/license/cayenne.dat. </RBW-PARABODY
><RBW-PARABODY>If you are running the license server software on another machine, you must identify the port being used by the license service on the server and the host name of the server. On the license server, open the license file cayenne.dat in a text editor. The port appears as the last field on the SERVER line. Cayenne Software uses the port number 7126 by default. For example:</RBW-PARABODY
>If LM_LICENSE_FILE is set in your environment for some other vendor’s software, enter the displayed path with the location of your ObjectTeam license file appended to the end, separated from the previous path by a colon (:).</N2.NOTE.2
><RBW-PARABODY>You are asked to specify the type of installation. Options are Master server, Slave server, or Client. Accept the default of Master.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>A warning is displayed that various environment files are created by the script.</LR.LIST.RESULT
><RBW-PARABODY>You are asked to specify the value of the LC_CTYPE environment variable. The default is C. Press return to accept the default or specify a value.</RBW-PARABODY
><RBW-PARABODY>You are asked to specify the value of the LC_COLLATE environment variable. The default is C. Press return to accept the default or specify a value.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The default printer is displayed. </LR.LIST.RESULT
><RBW-PARABODY>You are asked if you want to change the default printer or printer command for ASCII printing. Specify the printer command or change the default printer. </RBW-PARABODY
><RBW-PARABODY>You are asked if you want to change the default printer or printer command for graphical (PostScript) printing. Specify the printer command or change the default printer. </RBW-PARABODY
><RBW-PARABODY>For FrameMaker users, you are asked if you want to accept the default version of FrameMaker (International English) or if you want to change to the US English version. Press Return to accept the default or type N to change to the US version.</RBW-PARABODY
><RBW-PARABODY>You are asked what kind of license you have. Press Return if you have a Temporary license or type 2 if you have a Permanent license.</RBW-PARABODY
><RBW-PARABODY>You are asked for the name of your repository DBMS home directory. The default is the directory you set in INFORMIXDIR or ORACLE_HOME. Press Return to accept the default.</RBW-PARABODY
><RBW-PARABODY>If you are using Oracle as your repository, you are asked to specify the Oracle SID. The default is the value you set in ORACLE_SID. Press Return to accept the default.</RBW-PARABODY
><RBW-PARABODY>If you are using Informix as your repository, you are asked to specify the name of the Informix server. The default is the value you set in INFORMIXSERVER. Press Return to accept the default or type 2 to change the server.</RBW-PARABODY
><B.BODY>Your 6.1.1 repositories should be in /usr/cayenne/objectteam_old/corproot. Move the contents of the corproot directory to the new default location:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The name of the Oracle database specification string. If SQL*Net is installed, specify for dbname the Oracle SID. If running this program on an installation without SQL*Net, specify as dbname “default” and make sure the ORACLE_SID environment variable is set to the system identifier of the database to connect.</CELLBODY
><B.BODY>Once you have finished the upgrade, it is convenient to configure the ObjectTeam broker and license server to start automatically at boot time. </B.BODY
><B.BODY>You can enter any numbers after S and K as long as startup and shutdown are done in the correct order. It is important that the DBMS server start before the ot_broker starts, and that the ot_broker stop before the DBMS server stops.</B.BODY
><RBW-PARABODY>If this host is the license server, look for the following text:</RBW-PARABODY
></LN.LIST.NUM
><EWM.EXAMPLEW.MONO># If this script is run on the host used as license server,</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO># uncomment one of the next two start&truehy;up instructions and</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO># uncomment the line with ‘lmdown’ at the end of this file.</EWM.EXAMPLEW.MONO
><LT.LIST.TEXT>and uncomment the appropriate lines depending on whether you want the license server to run with logging (default) or not. Do not uncomment these lines if you have a temporary license.</LT.LIST.TEXT
><B.BODY>Now your new installation is working, you should activate the modules for which your site is licensed. For more details, see Chapter 4, Activating Modules.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customization files</L.LABEL
><B.BODY>Due to the addition of new features in this version of ObjectTeam, customizations made in previous versions may no longer work. If you have customized any Tcl files in <CX5FX5FTERM>M4_home</CX5FX5FTERM
>/tcl, It is recommended that you recreate your customizations based on the new Tcl files.</B.BODY
><B.BODY>Note that some Tcl files have now moved and can be found in various modules. Note also that the names of some customization files have changed from previous versions. For more information on customizations and on modules, see the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>User roles</L.LABEL
><B.BODY>If you had assigned roles to user ot4omt in your previous version of ObjectTeam, you should assign these roles to user cayenne in ObjectTeam 7.1.1. You should also remove the user ot4omt from ObjectTeam 7.1.1.</B.BODY
><B.BODY>For details on adding and deleting users in ObjectTeam, refer to the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Removing your old installation</L.LABEL
><B.BODY><CX5FX5FFILE.NAME>Upgrade from 5.x:</CX5FX5FFILE.NAME
> If your old ObjectTeam installation was in /usr/ot4omt, then if you are satisfied that the new installation is working correctly, you can remove the directory tree. Log in as ot4omt and enter the following command:</B.BODY
><B.BODY><CX5FX5FFILE.NAME>Upgrade from 6.1.1:</CX5FX5FFILE.NAME
> If your old ObjectTeam installation was in /usr/cayenne, then if you are satisfied that the new installation is working correctly, you can remove the directory tree. Log in as ot4omt and enter the following command:</B.BODY
><B.BODY>Since the old databases are created by user ot4omt, these cannot be removed as cayenne. This should be done by user Informix or user system in the case of Oracle. </B.BODY
><RBW-PARABODY>Do a new Slave server install, as described in <RBW-XREF REFID="29343" TYPE="XREF-TEXTCOPY">Installing an ObjectTeam Slave Server on page 2–18</RBW-XREF
><RBW-PARABODY>Do a new client install, as described in <RBW-XREF REFID="28366" TYPE="XREF-TEXTCOPY">Installing an ObjectTeam Client on page 2–29</RBW-XREF
><B.BODY>ObjectTeam consists of a base product and a number of optional features. Each optional feature is implemented as an ObjectTeam module. To use the feature, you must activate the module. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Licensing</L.LABEL
><B.BODY>Most modules require a valid license. If ObjectTeam displays license&truehy;related error messages, you may not have a valid license. </B.BODY
><B.BODY>Refer to <RBW-XREF REFID="19159" TYPE="XREF-TEXTCOPY">Appendix B, Configuring a License Server</RBW-XREF
> for more information.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Modules and repository levels</L.LABEL
><B.BODY>The instructions here cover how to activate modules on Corporate level for an entire corporate repository. You must have root access to do this. Modules activated on Corporate level are available by default for all users of this repository on every level.</B.BODY
><B.BODY>You do not have to activate all modules on Corporate level. Users can activate them on any other level in the repository, as long as they are licensed.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Which ObjectTeam modules are available</L.LABEL
><B.BODY>A <CX5FX5FTERM>module</CX5FX5FTERM
> is a directory of files that implement an optional ObjectTeam feature. The directory name is the module name. By default, all modules are stored in the modules directory of your <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
> directory.</B.BODY
><B.BODY>Modules on the following features are supplied with ObjectTeam. </B.BODY
>Not all modules are available on all platforms. </N.NOTE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Code Generation</SL.SUBLABEL
><B.BODY>In previous releases of ObjectTeam, target language for code generation was set using the variables M4_package and M4_target_lang. This mechanism has been replaced by modules. These variables are no longer used. </B.BODY
>The C++ code generation implemented in the <CX5FX5FFILE.NAME>C++ Code Generation</CX5FX5FFILE.NAME
> module is different from previous versions of ObjectTeam. The previous implementation of C++ code generation is available in the compatibility module <CX5FX5FFILE.NAME>Persistent C++ Generation</CX5FX5FFILE.NAME
>. For more details, see chapter on compatibility in the <CX5FX5FTITLE>ObjectTeam Code Generation Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for C++.</N.NOTE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>User&truehy;defined modules</SL.SUBLABEL
><B.BODY>You can create your own ObjectTeam modules. For details, see <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="13855"></RBW-ANCHOR
>How to Activate a Module on Corporate level</L.LABEL
>Because of the way customization files are read by ObjectTeam, you have to clone (or restart) the Browser if you want the changes made to <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> files on Corporate level and User Customization level to take effect.</N2.NOTE.2
><B.BODY>Customization files on these levels are only read at start&truehy;up.</B.BODY
> customization file contains one or more module specifications. Each module specification activates or deactivates a module. A <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> customization file can exist at any Browser level, from corporate level through user level</B.BODY
> files are incrementally read by ObjectTeam. The specifications in a <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file on Corporate level, for example, are read when a user starts ObjectTeam, whereas those in a <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file on Project level are read when a user opens the Project in the ObjectTeam Browser.</B.BODY
><B.BODY>The set of module specifications on a certain Browser level is the result of ObjectTeam’s adding module specifications from all the <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> files on higher levels.</B.BODY
><B.BODY>This implies that if you want the changes made in a certain <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file to take effect, you first have to make ObjectTeam read the <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
>If you made changes to a <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file on Corporate level or User Customization level, you cannot move up one level anymore; the changes only take effect if you either clone or restart the Browser.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>If the <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file was changed on Project level, in a project called ProjectX, for example, you should first move up (by selecting the Corporate object in the Navigation Area, for example). If you then open ProjectX again, ObjectTeam adds the module specifications in this file to the current set of module specifications.</B.BODY
><B.BODY>The Module Availability Editor is the tool with which you create, activate, delete and manipulate ObjectTeam module specifications. It starts up if you edit the customization file <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Brings up an information dialog box listing details, such as module type, module directory location and required modules</CELLBODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Checks if all the modules required by the modules in the Display Area have been added</CELLBODY
><CELLBODY>See Required Modules on page –13</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Filter on Current </CELLBODY
><CELLBODY>File Entries</CELLBODY
></ENTRY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Use this option if you only want to see those module specifications in the Display Area that can be edited on the current level.</CELLBODY
><B.BODY>Certain ObjectTeam modules require other modules to work properly, others are only supporting other modules, and some modules exclude each other. </B.BODY
><B.BODY>Every module directory contains a file called <CX5FX5FFILE.NAME>properties.properties</CX5FX5FFILE.NAME
>. This file contains certain fields through which dependencies between modules and module types are specified. These fields are discussed in this section.</B.BODY
><B.BODY>If a particular module require other modules in order to operate properly, the following fields can be used in the <CX5FX5FFILE.NAME>properties.properties</CX5FX5FFILE.NAME
><B.BODY>Users of the Module Availability Editor can see which modules and module types are required by a module by selecting Edit | Info. for that module. The Information Box that appears lists, among other things, the required modules and module types, if applicable.</B.BODY
><B.BODY>In this field, a list of required modules, separated by spaces, can be specified. If a module that requires other modules is selected in the Module Editor, the required module(s) will be automatically added to the <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file too.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>requiredModuleTypes</L.LABEL
><B.BODY>If a module requires another module, but there is more than one module of that type available, a list of required module <CX5FX5FEMPHASIS>types</CX5FX5FEMPHASIS
> is specified. If a module that requires other module types is selected in the Module Editor, a dialog box appears, listing all the available modules of that type. After a user of the Module Editor selects the module of his choice, this module is added to the <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file.</B.BODY
><B.BODY>In the <CX5FX5FFILE.NAME>properties.properties</CX5FX5FFILE.NAME
> file of the module C++ Code Generation, for example, the following module types are specified as requiredModuleTypes:</B.BODY
><B.BODY>You can check if all the requirements have been met for all the modules by selecting Check | Requirements in the Module Availability Editor. If there are any requirements missing, an Information dialog box will list them.</B.BODY
><B.BODY>Certain modules exclude each other: if the module C++ Code Generation is active for a particular system, for example, the module Java Code Generation cannot be active at the same time.</B.BODY
><B.BODY>The following fields in the <CX5FX5FFILE.NAME>properties.properties</CX5FX5FFILE.NAME
> file can be used to specify conflicting modules:</B.BODY
>A user of the Module Editor is still able to add a module that conflicts with another module, but will get an error message when he attempts to save the <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Saving a conflicting modules.modules file</L.LABEL
><B.BODY>When you try to save a <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file that contains conflicts, the following dialog box appears.</B.BODY
><B.BODY>The file is not saved. You should correct the conflict(s) by deactivating one of the conflicting modules (see Resolving Conflicting Modules on page –1 for details). </B.BODY
><B.BODY>Use Check | Conflicts to find out which modules are conflicting.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>No</SL.SUBLABEL
><B.BODY>All the modules in the <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file that cause a conflict are deactivated, after which the file is saved.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Cancel</SL.SUBLABEL
><B.BODY>Cancels the operation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Viewing conflicting module (types)</L.LABEL
><B.BODY>Users of the Module Availability Editor can see which modules or module types are defined as conflicting with the module by selecting Edit | Info for that module. The Information Box that appears lists, among other things, the conflicting modules and module types, if applicable.</B.BODY
><B.BODY>In this field, a list of modules that are supposed to conflict with the current module can be specified. The list is separated by commas.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>conflictingModuleTypes</SL.SUBLABEL
><B.BODY>In this field, a list of module <CX5FX5FEMPHASIS>types</CX5FX5FEMPHASIS
> that are supposed to conflict with the current module are listed. The list is separated by commas.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Checking for conflicts</L.LABEL
><B.BODY>You can check for conflicts in the Module Availability Editor by selecting Check | Conflicts. If there are any conflicts, an Information dialog box will list them.</B.BODY
>Module specifications and browser levels</L.LABEL
><B.BODY>The Module Availability Editor displays the current set of module specifications: the result of incrementally read <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> files (see Checking if a module is active on page –1). You can only edit or delete the modules that have been added on the current level</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example of a module conflict</L.LABEL
><B.BODY>You could encounter a situation in which you would like to add and activate a module that conflicts with a module that has been added and activated on a higher level. For example, the C++ Code Generation module is activated on Corporate level, but for one particular Project you would like to generate Java code.</B.BODY
><RBW-PARABODY>Open the customization file <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> on the Browser level of your choice.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>The specifications you are going to add to this file will be valid on the current Browser level and below. (Project level and below, for example)</LT.LIST.TEXT
><RBW-PARABODY>In the Module Availability Editor, add the same module as the one on a higher level that is causing the conflict (C++ Code Generation, for example)</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>Use Edit | New to bring up the Select Module dialog box. Select the module of your choice from this box.</LT.LIST.TEXT
><RBW-PARABODY>Add the module that would conflict if the conflicting module on a higher level were not deactivated (Java Code generation, for example).</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>Make sure its state is <CX5FX5FEMPHASIS>on</CX5FX5FEMPHASIS
>.</LT.LIST.TEXT
><B.BODY>The new module is now only active for the configuration, phase, project or system for which the customization file <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
><B.BODY>Supporting modules are modules that are required by other modules, but are not useful independently. As users usually do not need to know about supporting modules, they are, by default, not listed in the Select Module dialog box. This box appears if a user of the Module Editor selects Edit | New.</B.BODY
><RBW-PARABODY>You have a DocExpress feature line in your ObjectTeam license file. DocExpress also uses the FLEXlm license management software. For more details on FLEXlm licensing, and how to add features to your license file, see <RBW-XREF REFID="19159" TYPE="XREF-TEXTCOPY">Appendix B, Configuring a License Server</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Reading the DocExpress online manuals</L.LABEL
><B.BODY>The DocExpress documentation is part of the ObjectTeam product documentation and is installed with ObjectTeam. </B.BODY
><SUBSECTION><SS.SUBSEC.HEAD>How to Uninstall DocExpress</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>If you have an older version of DocExpress, the installation for Version 2.3.9 will automatically rename the current directory to doc_<CX5FX5FTERM>xxx</CX5FX5FTERM
>, where <CX5FX5FTERM>xxx</CX5FX5FTERM
> is a dynamic process number allocated by the operating system to the installation script at run time.</B.BODY
><B.BODY>However, you can also choose to remove the current version of DocExpress instead.</B.BODY
><B.BODY>You are now ready to install the new DocExpress version.</B.BODY
></LABEL
></SUBSECTION
><SUBSECTION><SS.SUBSEC.HEAD>How to Make the Installation Directory</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>You must make an installation directory, if one doesn’t already exist. The recommended installation directory is /usr/ata, although you can install elsewhere. </B.BODY
><RBW-PARABODY>Create a symbolic link /ata that points to the installation directory. For example, if your installation directory is /usr/ata, create the following link:</RBW-PARABODY
><LT.LIST.TEXT>Follow the instructions.</LT.LIST.TEXT
></LABEL
></SUBSECTION
><SUBSECTION><SS.SUBSEC.HEAD>How to Install the DocExpress Templates</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>If you are using a temporary ObjectTeam license, the DocExpress installation will only install sample templates for FrameMaker and Interleaf. These templates include:</B.BODY
><B.BODY>If you have a permanent ObjectTeam license including a feature license for DocExpress, you can install the full set of DocExpress templates.</B.BODY
><B.BODY>For more details on temporary and permanent licenses, refer to <RBW-XREF REFID="19159" TYPE="XREF-TEXTCOPY">Appendix B, Configuring a License Server</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to install the DocExpress templates:</L.LABEL
><LR.LIST.RESULT>The DocExpress templates are installed and configured.</LR.LIST.RESULT
></LABEL
></SUBSECTION
><SUBSECTION><SS.SUBSEC.HEAD>Configuring DocExpress for Use With FrameMaker</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>By default, DocExpress is set up at installation to work with FrameMaker 5.1. If you wish to use DocExpress with FrameMaker 4 or 5.0, you must configure it.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to configure DocExpress for use with FrameMaker</L.LABEL
><RBW-PARABODY>While still logged in as an authorized user, create a symbolic link to your FrameMaker installation. For example, if you want to work with FrameMaker 5.01, carry out the following steps:</RBW-PARABODY
>If you are using International FrameMaker, you must also configure DocExpress, as described in Using DocExpress with International FrameMaker on page A–10 before you set up your user environment.</N.NOTE
></LABEL
></SUBSECTION
><SUBSECTION><SS.SUBSEC.HEAD>Setting Up the User Environment </SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>All users must set up their environment before using DocExpress.</B.BODY
>It is recommended that users run DocExpress from a C&truehy;shell, so that the .cshrc file is read. You should also have a .Xdefaults file in their home directory. HP&truehy;UX users should also read the chapter on customization in the <CX5FX5FTERM>DocExpress User Guide </CX5FX5FTERM
>Using DocExpress with International FrameMaker</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>If you intend using DocExpress with the International English version of FrameMaker, you must make some extra configurations to the DocExpress environment:</B.BODY
><RBW-PARABODY>Establish links for DocExpress API Clients.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to modify the DocExpress configuration file</L.LABEL
><B.BODY>Some aspects of DocExpress operations are controlled by settings in a DocExpress configuration file. When DocExpress initiates any of its operations (e.g., Load, Build, etc.) it examines this file. To run DocExpress with International FrameMaker, you must modify the configuration file. </B.BODY
><B.BODY>DocExpress supplies templates for FrameMaker and FrameBuilder. DocExpress needs to know where these templates for International FrameMaker are located. </B.BODY
><RBW-PARABODY>How to obtain a permanent license</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Master server</SL.SUBLABEL
><B.BODY>You must follow the instructions in this chapter before you install or upgrade an ObjectTeam Master server. If you are installing a Slave server or Client, you must already have installed a Master server, so you can skip this chapter.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Demo installation</SL.SUBLABEL
><B.BODY>If you only want to install a demonstration copy of ObjectTeam for trial purposes, you can skip this chapter. A demo installation does not need a license server.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Related documentation</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Required reading</SL.SUBLABEL
><B.BODY>You should read the <CX5FX5FTITLE>FLEXlm End User Manual</CX5FX5FTITLE
> before installing the FLEXlm license software. The FLEXlm manual provides valuable information on network license management and site customization; for example, it provides details about the license file and various license administration tools. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Recommended reading:</SL.SUBLABEL
><B.BODY>For more information on network license management and UNIX system administration, read the <CX5FX5FTITLE>FLEXlm Programmer’s Guide</CX5FX5FTITLE
> (available from Globetrotter Software, Inc.) and <CX5FX5FTITLE>Essential System Administration</CX5FX5FTITLE
> by Aeleen Frisch (published by O’Reilly & Associates, ISBN 0&truehy;937175&truehy;80&truehy;3).</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="14820" TYPE="XREF-TEXTCOPY">Licensing in ObjectTeam&rbwtab;B–3</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="37096" TYPE="XREF-TEXTCOPY">Installing the License Server Software&rbwtab;B–7</RBW-XREF
>If you are not interested in how licensing works and just want to get on with installation, skip to Installing the License Server Software on page B–7.</T.TIP
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>License components</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>License server</SL.SUBLABEL
><B.BODY>In an ObjectTeam installation, a single machine in the network acts as <CX5FX5FTERM>license server</CX5FX5FTERM
>. By default, this is the same machine as the ObjectTeam Master server. The license server consists of the following components:</B.BODY
>, that is started automatically when the machine is booted. This daemon receives requests for features from other workstations on the network and assigns them to the Cayenne daemon.</RBW-PARABODY
>, that points to the address of the license server</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Temporary licenses</L.LABEL
><B.BODY>To use ObjectTeam, you must obtain a license from Cayenne. Licenses are keyed to the id of the machine on which you are running the license server. So before we can supply a license, you must inform us of this <CX5FX5FTERM>hostid</CX5FX5FTERM
> using the license request form.</B.BODY
><B.BODY>Issuing the license can take a day or so, so to get you started in the meantime, Cayenne supplies a <CX5FX5FTERM>temporary license</CX5FX5FTERM
> that is not linked to a hostid. This temporary license is valid for a limited period and usually comes on a floppy in your ObjectTeam package, though you may also receive it via email or fax.</B.BODY
><B.BODY>The temporary license file is made up of <CX5FX5FTERM>feature lines</CX5FX5FTERM
>, each controlling the use of a single ObjectTeam feature. This is an example of a feature line:</B.BODY
><B.BODY>Until you receive the permanent license, you must install a copy of the temporary license on every workstation on which you install ObjectTeam software. The temporary license then controls access to all features on that machine itself; you cannot run a license server with a temporary license. </B.BODY
><B.BODY>During installation of ObjectTeam, you are prompted to set the LM_LICENSE_FILE variable to point to the location of your local temporary license file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Permanent licenses</L.LABEL
><B.BODY>A permanent license is what Globetrotter refers to in the <CX5FX5FTERM>FLEXlm End User Manual</CX5FX5FTERM
> as a <CX5FX5FTERM>floating license</CX5FX5FTERM
>. This means it is installed on a particular machine in the network that acts as a license server. The license server controls the usage of ObjectTeam features by any workstation connected to the license server.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Contents of a permanent license file</L.LABEL
><B.BODY>A license file is made up of a <CX5FX5FTERM>server line</CX5FX5FTERM
>, a <CX5FX5FTERM>daemon line</CX5FX5FTERM
> and a number of <CX5FX5FTERM>feature lines</CX5FX5FTERM
>. This is an example of a floating license:</B.BODY
><RBW-PARABODY>The server line identifies the name and (encrypted) hostid of the license server, and the port on which it receives license requests.</RBW-PARABODY
><RBW-PARABODY>A feature line identifies a particular ObjectTeam licensed feature, the version of ObjectTeam for which it is valid, the expiry date and the number of workstations that can use it simultaneously. If this is a nodelocked feature, the hostid is also specified.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Replacing a temporary license with a permanent license</L.LABEL
><B.BODY>Once you receive your permanent license, you:</B.BODY
><RBW-PARABODY>Reset LM_LICENSE_FILE on each machine running ObjectTeam to point to the license server. On a machine other than the license server, LM_LICENSE_FILE has the format <CX5FX5FTERM>port</CX5FX5FTERM
>@<CX5FX5FTERM>server</CX5FX5FTERM
>, where <CX5FX5FTERM>port</CX5FX5FTERM
> is the TCP/IP port being used by the license server, and <CX5FX5FVARIABLE>server</CX5FX5FVARIABLE
> is the host name of the server running the license service. These are identified in the server line of the license file. </RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Licensing process</L.LABEL
><B.BODY>Once the license server is running, it controls the use of ObjectTeam features. When a user tries to start an ObjectTeam feature, such as a Browser, ObjectTeam:</B.BODY
><RBW-PARABODY>Examines LM_LICENSE_FILE to find the address of the license server. On a client for example, this has the format <CX5FX5FTERM>port</CX5FX5FTERM
><RBW-PARABODY>Makes a request for a feature with the appropriate name (such as, OT_BROWSER_UNIX). The request is passed to the license server at the specified address. </RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>The license manager daemon on the license server:</B.BODY
><RBW-PARABODY>Searches the license file for the feature with the specified name. On the feature line is also listed the name of the daemon which is responsible for controlling this feature, namely <CX5FX5FTERM>cayenne</CX5FX5FTERM
><RBW-PARABODY>Passes the request to the cayenne daemon, which then grants or denies a license based on the number of licenses available.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing license files</L.LABEL
><B.BODY>Normally, your license file contains all the features that you need to use ObjectTeam. If you subsequently decide that you would like to use additional features of ObjectTeam, you can order additional licenses for each feature. To make a new license available, you simply add a new feature line to your existing license file.</B.BODY
><RBW-PARABODY>To add a new feature, type (or copy and paste) the new feature line into the file. If you are typing the license information, be careful to avoid typing mistakes.</RBW-PARABODY
>Installing the License Server Software</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Before you install or upgrade an ObjectTeam Master server, you must configure a machine in your network as a license server. This can be the same machine as the Master server, or some other machine. </B.BODY
><B.BODY>This section assumes you are installing the license software on the ObjectTeam Master server. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="32637"></RBW-ANCHOR
>How to install the license management software</L.LABEL
><RBW-PARABODY>You are asked in which directory you wish to install FLEXlm. The default is /usr/cayenne/flexlm. Press Return to accept this default or enter a location of your choosing. (The rest of this chapter assumes you accept the default location.)</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>Once installation is complete, the /usr/cayenne/flexlm/bin directory contains the FLEXlm daemon and a collection of FLEXlm utilities. For more information about the utilities, see the FLEXlm End User Manual.</LR.LIST.RESULT
><RBW-PARABODY>Permanent license, install the permanent license and start the license server, as described in Installing a Permanent License on page B–10.</RBW-PARABODY
><B.BODY>To obtain a permanent license, you must find out the host ID of your machine and submit it to Cayenne using the License Request Form. </B.BODY
><B.BODY>Carry out the steps in this section while logged into the license server as cayenne.</B.BODY
><RBW-PARABODY>Go to the license request form provided on Cayenne Software’s World Wide Web page at: <CX5FX5FFILE.NAME>http://www.cayennesoft.com/license</CX5FX5FFILE.NAME
><RBW-PARABODY>Print out the form provided on the CD&truehy;ROM (/cdrom/lic_req.txt or /cdrom/lic_req.htm), fill it in and fax it to us at 617&truehy;273&truehy;0618.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LT.LIST.TEXT>If you are ordering from outside the United States, contact your Cayenne sales office.</LT.LIST.TEXT
><B.BODY>Cayenne will send you a new license for the product by electronic mail or by fax. </B.BODY
><B.BODY>Once you receive a permanent license, carry out the instructions in Installing a Permanent License on page B–10. </B.BODY
><B.BODY>Once you receive a permanent license, you can start the license server. Carry out the steps in this section while logged into the license server as cayenne.</B.BODY
><RBW-PARABODY>Via email, copy and paste the new feature information into an empty text file and save it as <CX5FX5FFILE.NAME>/usr/cayenne/flexlm/license/cayenne.dat</CX5FX5FFILE.NAME
><RBW-PARABODY>Via fax, enter the new feature information by hand into an empty text file, and save it as <CX5FX5FFILE.NAME>/usr/cayenne/flexlm/license/cayenne.dat</CX5FX5FFILE.NAME
><RBW-PARABODY>Open the license file in a text editor and check that the DAEMON line points to the correct location of the cayenne daemon, for example:</RBW-PARABODY
>If LM_LICENSE_FILE is set in your environment for some other vendor’s software, add the above path to the end of the line, separated from the previous path by a colon (:).</N2.NOTE.2
><RBW-PARABODY>Identify the port being used by the License Service on the server and the host name of the server. On the license server, open the license file cayenne.dat in a text editor. The port appears as the last field on the SERVER line. Cayenne Software uses the port number 7126 by default. For example:</RBW-PARABODY
><RBW-PARABODY>How to install and configure an Informix client</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Installing Informix for the First Time</L.LABEL
><B.BODY>If you are installing ObjectTeam for the first time, Informix license cards with Serial Numbers and Keys are included. A license Serial Number and Key are required to complete the Informix installation. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><RBW-PARABODY>Make sure that the file system containing the Informix installation has enough free disk space to store the informix database by using:</RBW-PARABODY
><LT.LIST.TEXT>Informix will reserve the space that will be allocated later. The space is determined by the Root Size field as described in Setting Up Informix Client on page C–19. The default setting for ObjectTeam is 100 MB. </LT.LIST.TEXT
> The preferred network connection type between Informix and the database server is onipcstr. To set this up, edit the $INFORMIXDIR/etc/onconfig file and add the line:</RBW-PARABODY
></LN.LIST.NUM
><EM.EXAMPLE.MONO>NETTYPE &rbwtab;&rbwtab;ipcstr,,, #Configure poll thread(s) for nettype</EM.EXAMPLE.MONO
><LT.LIST.TEXT>If you are running NIS or NIS+, this file may be on another node in your network, the one that maintains a global services file.</LT.LIST.TEXT
><LT.LIST.TEXT>You should verify that socket 1225 is not being used for another service.</LT.LIST.TEXT
><RBW-PARABODY>Check if you are user informix by the command id or whoami. </RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>This is very important because the following menu&truehy;driven program must be started as user informix (otherwise errors will occur). On some platforms, specific settings are needed to allow Informix utilities to display properly.</LT.LIST.TEXT
><RBW-PARABODY>Choose option Parameters, then Initialize.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>Using the tab or return keys, it is possible to switch between fields. A backtab can be done using an up&truehy;arrow. The following shows values which can be used for a new installation. After installation, these parameters can be changed.</LT.LIST.TEXT
><LT.LIST.TEXT>These settings assume that INFORMIXDIR is /usr/informix. Replace /usr/informix with the correct full path of your Informix installation. Your screen should look similar to the following when complete:</LT.LIST.TEXT
><RBW-PARABODY>The Shared Memory form will now be shown.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>The Server Name field must be set. The default is the hostname of the machine you are installing on. If you do not know your machine's host name, use the <CX5FX5FINPUT>hostname</CX5FX5FINPUT
> or <CX5FX5FINPUT>uname &truehy;n</CX5FX5FINPUT
> UNIX commands. </LT.LIST.TEXT
><LT.LIST.TEXT>For ObjectTeam, you also need to increase the default number of LOCKS. The number of locks at the field Max # of Locks must be increased to at least 5000. The recommended starting value is 16394. Depending on the product usage, you may need to increase this number further. The maximum number of locks is 256,000. The Max # of Logical Logs must also be changed to 256.</LT.LIST.TEXT
><LT.LIST.TEXT>Your screen should look similar to the following when complete:</LT.LIST.TEXT
><LT.LIST.TEXT>The next screen is data replication. Change Lost & Found to the proper directory for your Informix installation, (or any valid directory), and hit Return.</LT.LIST.TEXT
><LT.LIST.TEXT>The screen looks like this:</LT.LIST.TEXT
><LT.LIST.TEXT>The next screen is <RBWAUTO-0005>Diagnostics</RBWAUTO-0005
>. The Console Msgs. parameters should be changed so that messages written to console will instead be written to a file, (e.g. /usr/informix/console.log).</LT.LIST.TEXT
><RBW-PARABODY>Onmonitor will return to the Parameters menu and Informix will be in quiescent mode. (See the status bar &truehy;&truehy;&truehy;&truehy;&truehy;). </RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>To bring Informix from Quiescent to Online, make the following menu choices: Exit, Mode, On&truehy;Line. Informix will now be in On&truehy;Line mode. (See the status bar &truehy;&truehy;&truehy;&truehy;&truehy;).</LT.LIST.TEXT
><RBW-PARABODY>Exit onmonitor with the following two menu choices:</RBW-PARABODY
></LN.LIST.NUM
><EM.EXAMPLE.MONO>Exit, Exit</EM.EXAMPLE.MONO
><LT.LIST.TEXT>Note: All the parameter values are stored in the $INFORMIXDIR/etc/onconfig file. After installation some of these parameters can be changed, manually or through onmonitor.</LT.LIST.TEXT
>Do NOT drop the sysmaster database. This will destroy your informix installation.</N.NOTE
><B.BODY>If you see any error messages during this test, or if this test fails for any reason, please check the installation steps and the Informix OnLine release notes. The Informix OnLine release notes are listed in the $INFORMIXDIR/release/ONLINE_7.x file. Most errors are a result of operating system resource limitations (e.g., shared memory)</B.BODY
><EM.EXAMPLE.MONO>fatal error in shared memory initialization </EM.EXAMPLE.MONO
><B.BODY>check the error log ~informix/online.log for more information.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Situation</L.LABEL
><B.BODY>You get the following error when starting the Informix server either from within onmonitor or on the command line with the oninit &truehy;y command:</B.BODY
><EM.EXAMPLE.MONO>Fatal error in shared memory initialization.</EM.EXAMPLE.MONO
><RBW-PARABODY>Check that the INFORMIXSERVER environment variable is set.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Situation</L.LABEL
><B.BODY>You get the following message after running ./installonline, or running any Informix utilities like tbinit, tbmonitor, or dbaccess:</B.BODY
><EWM.EXAMPLEW.MONO>Unknown error message number '32766' Installation failed. </EWM.EXAMPLEW.MONO
><B.BODY>You don't have the environment variable INFORMIXDIR set. This variable should point to the Informix directory that was created during the installation. You should also ensure that the informix/bin directory is in the path. See How to install Informix files on page C–2 for details on setting these variables. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Situation</L.LABEL
><B.BODY>When trying to bring Informix online you get an error message that the network is down OR when running dbaccess you get an error that the network is not trusted.</B.BODY
><B.BODY>To fix this, add the node names for the server (and clients, if applicable) to the /etc/hosts.equiv file on the machine running the Informix server.</B.BODY
><B.BODY>Note that the entries should contain the fully qualified name of the machine.</B.BODY
><B.BODY>Machines set up as an ObjectTeam Master server or Slave server need to be configured as an Informix client if the Informix server installation is located on another host. </B.BODY
><B.BODY>If you are installing ObjectTeam under Solaris or HP&truehy;UX, you can either mount the Informix file system on the Master server and any Slave servers, or install the Informix product files on the Master server and any Slave servers.</B.BODY
><B.BODY>If you are installing ObjectTeam under D&truehy;UX or AIX, you must install the Informix product files on the ObjectTeam Master server and any Slave servers.</B.BODY
><B.BODY>This section describes how to set up a locally installed Informix client.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Before you start</L.LABEL
><B.BODY>The Master server must have an entry in its .rhosts or /etc/hosts.equiv file that permits the user informix on the Slave server to start a remote shell on the Master server. </B.BODY
> The preferred network connection type between Informix and the database server is onipcstr. To set this up, edit the $INFORMIXDIR/etc/onconfig file and add the line:</RBW-PARABODY
></LN.LIST.NUM
><EM.EXAMPLE.MONO>NETTYPE &rbwtab;&rbwtab;ipcstr,,, #Configure poll thread(s) for nettype</EM.EXAMPLE.MONO
><LT.LIST.TEXT>If you are running NIS or NIS+, this file may be on another node in your network, the one that maintains a global services file.</LT.LIST.TEXT
><LT.LIST.TEXT>You should verify that socket 1225 is not being used for another service.</LT.LIST.TEXT
><LR.LIST.RESULT>Set up of the Informix client is complete.</LR.LIST.RESULT
><B.BODY>If something fails during the installation, the best solution is to uninstall ObjectTeam and run the setup program again. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Error messages</L.LABEL
><B.BODY>Many errors start with the message “Cannot initialize client context”. The important lines to look at are the last two or three lines. These usually contain some clear indication of the cause of the problem.</B.BODY
><B.BODY>When troubleshooting, be aware that some error messages only pop up after a timeout limit has been reached. These are usually set to one minute. If nothing happens, wait at least this time before taking action.</B.BODY
></LABEL
><SECTION><S.SECTION.HEAD>Changes Made During Installation</S.SECTION.HEAD
><RBW-PARABODY>The variable M4_home is set as an environment variable. All ObjectTeam tools use this variable. The default value is /usr/cayenne/objectteam.</RBW-PARABODY
>/etc/objservers.objservers is modified when you create a repository. For more details, see the <CX5FX5FTITLE>ObjectTeam System Administrator’s Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
><CX5FX5FTERM> for UNIX&truehy;based Systems</CX5FX5FTERM
><RBW-PARABODY>The variable M4_home is set as an environment variable. All ObjectTeam tools use this variable. The default value is /usr/cayenne/obejctteam.</RBW-PARABODY
><RBW-PARABODY>The variable M4_home is set as an environment variable. All ObjectTeam tools use this variable. The default value is /usr/cayenne/obejctteam.</RBW-PARABODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Various internationalization and printing&truehy;related variables.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Error messages</L.LABEL
><B.BODY>When troubleshooting, be aware that some error messages only pop up after a timeout limit has been reached. These are usually set to five minutes. If nothing happens, wait at least this time before taking action.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>General troubleshooting</L.LABEL
><B.BODY>In the event of problems, check the <CX5FX5FTERM>M4_home</CX5FX5FTERM
>/logs/ot_brok.log file as well as the status of the ObjectTeam broker service.</B.BODY
><EWM.EXAMPLEW.MONO>ERROR [120072]: Remote implementation ‘levelpath’ not found. </EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [121001]: Implementation with id ‘levelpath’ not registered in implementation repository</EWM.EXAMPLEW.MONO
><B.BODY>The M4_levelpath is not set correctly.</B.BODY
><B.BODY>Set the ObjectTeam variable M4_levelpath to point to an existing repository, for example, <CX5FX5FINPUT>M4_levelpath=/corporate;RW</CX5FX5FINPUT
>.</B.BODY
><B.BODY>This variable is defined in <CX5FX5FTERM>M4_home</CX5FX5FTERM
>/etc/m4env.m4env or in the .Meta4UserEnv file in your login directory. </B.BODY
><B.BODY>The XBMLANGPATH variable is not set correctly.</B.BODY
><B.BODY>Set XBMLANGPATH to $M4_home/%T/%B:$M4_home/%T/%B.xpm</B.BODY
><B.BODY>Alternatively, you may have run out of colors. If you are running color&truehy;intensive applications, quit them and start ObjectTeam again.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Starting the browser </L.LABEL
><EWM.EXAMPLEW.MONO>ld.so.1: /usr23/cayenne/objectteam/bin/otk: fatal: libcyntcl.so: can’t open file: errno=2</EWM.EXAMPLEW.MONO
><B.BODY>The LD_LIBRARY_PATH variable is not set correctly.</B.BODY
><B.BODY>Set LD_LIBRARY_PATH (only for platforms supporting shared libraries). The ObjectTeam shared libraries are in <CX5FX5FTERM>M4_home</CX5FX5FTERM
>/lib.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Starting the browser</L.LABEL
><EWM.EXAMPLEW.MONO>/usr23/cayenne/objectteam/bin/ot: /usr23/cayenne/objecttea/bin/otk: not found</EWM.EXAMPLEW.MONO
><B.BODY>The M4_home variable is not set correctly.</B.BODY
><B.BODY>Set the ObjectTeam environment variable M4_home to point to the installation directory of ObjectTeam. The default is /usr/cayenne/objectteam.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Starting the browser</L.LABEL
><EWM.EXAMPLEW.MONO>ERROR [115024]: Cannot obtain corporate id for ‘corporate’.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [120051]: Name request for Corporate service ‘corporate’ not invoked.</EWM.EXAMPLEW.MONO
><B.BODY>The M4_home variable is not set correctly.</B.BODY
><B.BODY>Set the ObjectTeam environment variable M4_home to point to the installation directory of ObjectTeam. The default: is /usr/cayenne/objectteam.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Starting the browser</L.LABEL
><EWM.EXAMPLEW.MONO>ERROR [115024]: Cannot obtain corporate id for ‘levelpath’.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [120051]: Name request for Corporate service ‘levelpath’ not invoked.</EWM.EXAMPLEW.MONO
><B.BODY>Check if the ot_broker is running on the server. If not start the broker by entering $M4_home/bin/ot_broker &</B.BODY
><B.BODY>Check if the value for the broker port (M4_brokerport) is correct. Set the ObjectTeam environment variable M4_brokerport to a number via which the broker can be reached. This variable is defined in <CX5FX5FTERM>M4_home</CX5FX5FTERM
>/etc/m4env.m4env or in the .Meta4UserEnv file in your login directory. The default value is 1825.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Starting the browser</L.LABEL
><EWM.EXAMPLEW.MONO>ERROR [123002]: Could not checkout license for OT_BROWSER_UNIX</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [123001]: FLEXlm: Cannot find license file (&truehy;1,73:2) No such file or directory</EWM.EXAMPLEW.MONO
><B.BODY>The LM_LICENSE_FILE variable is not set correctly.</B.BODY
><B.BODY>Set the FLEXlm system environment variable LM_LICENSE_FILE to point to:</B.BODY
><B.BODY>a. A valid local license file, e.g., /usr/cayenne/flexlm/license/cayenne.dat</B.BODY
><B.BODY>b. <CX5FX5FTERM>port</CX5FX5FTERM
>@<CX5FX5FTERM>host</CX5FX5FTERM
>, if you are running a license server on another machine. To identify the port, log on to your machine running the license server and open the license file cayenne.dat The port appears as the last field on the server line, e.g. 7126@capella</B.BODY
><B.BODY>Note: If LM_LICENSE_FILE is set in your environment for some other vendor’s software, enter the displayed path with the location of your ObjectTeam license file appended on the end, separated from the previous path by a colon (:).</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Starting the browser</L.LABEL
><EWM.EXAMPLEW.MONO>ERROR [115024]: Cannot obtain corporate id for ‘corporate’.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [120051]: Name request for Corporate service ‘corporate’ not invoked.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [121013]: Server ‘dbserver’ reports failure:</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [123002]: Could not checkout license for OT_SERVER_UNIX</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [123001]: FLEXlm: cannot find license file (&truehy;1,72:2) No such file or directory</EWM.EXAMPLEW.MONO
><B.BODY>The LM_LICENSE_FILE variable was not set correctly at the time the ot_broker was started.</B.BODY
><B.BODY>Set the LM_LICENSE_FILE correctly as explained below, kill the broker, then start it again by entering $M4_home/bin/ot_broker &.</B.BODY
><B.BODY>Set the FLEXlm system environment variable LM_LICENSE_FILE pointing to:</B.BODY
><B.BODY>a. A valid local license file, e.g., /usr/cayenne/flexlm/license/cayenne.dat</B.BODY
><B.BODY>b. <CX5FX5FTERM>port</CX5FX5FTERM
>@<CX5FX5FTERM>host</CX5FX5FTERM
>, if you are running a license server on another machine. To identify the port, log on to your machine running the license server and open the license file cayenne.dat The port appears as the last field on the server line, e.g. 7126@capella.</B.BODY
><B.BODY>Note: If LM_LICENSE_FILE is set in your environment for some other vendor’s software, enter the displayed path with the location of your ObjectTeam license file appended on the end, separated from the previous path by a colon (:).</B.BODY
><EWM.EXAMPLEW.MONO>ERROR [121013]: Server ‘dbserver’ reports failure:</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [112152]: Error occurred while opening a repository</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [110032]: Failed to execute query: ‘CONNECT TO <name@server>’</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [000146]: Unable to load locale categories</EWM.EXAMPLEW.MONO
><B.BODY>The INFORMIXDIR variable was not set correctly at the time the ot_broker was started.</B.BODY
><B.BODY>Set the INFORMIXDIR variable to point to the Informix installation directory and kill the broker, then start it again by entering $M4_home/bin/ot_broker &. The default value is /usr/informix.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Starting commands in a shell (dbdump etc.)</L.LABEL
><EWM.EXAMPLEW.MONO>ERROR [210040]: (Message not available)</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [001004]: Module 210 not initialized.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [001001]: Error while reading message file ‘etc/message/message.210’.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>SYSERR [000002]: No such file or directory</EWM.EXAMPLEW.MONO
><B.BODY>The M4_home variable is not set correctly</B.BODY
><B.BODY>Set the ObjectTeam environment variable M4_home to point to the installation directory of ObjectTeam. The default is /usr/cayenne/objectteam.</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="32992" TYPE="XREF-TEXTCOPY">Backing Up Your System&rbwtab;1–8</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="18228" TYPE="XREF-TEXTCOPY">Creating a User Directory (Windows 95 Only)&rbwtab;1–10</RBW-XREF
><B.BODY>To decide the type of installation that you want to perform, you must first determine which computers will be running each of these sets of software.</B.BODY
><B.BODY>This section helps you answer these questions. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Client/server Architecture</L.LABEL
><B.BODY>ObjectTeam has a <CX5FX5FTERM>client/server</CX5FX5FTERM
> design. This means that the software can be distributed over a network of computers, with client computers and server computers executing different types of processes.</B.BODY
><B.BODY>Client computers run the ObjectTeam <CX5FX5FTERM>client software</CX5FX5FTERM
>. End&truehy;users use the client software, for example, to edit diagrams, run reports, and generate code. Model data created by users is stored centrally in a database on the server. Generated code and documents are stored on a user’s own machine.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Server computers</SL.SUBLABEL
><B.BODY>A server computer runs the ObjectTeam <CX5FX5FTERM>server software</CX5FX5FTERM
>, and database software for storing users’ project data. The server software usually starts up at system boot time, and does things like interact with the database and coordinate requests from clients. Users generally do not directly invoke server software. By default, the maximum number of client computers you can attach to a server is unlimited.</B.BODY
><B.BODY>A client/server configuration allows multiple users to work simultaneously with ObjectTeam, and thus share data. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>ObjectTeam database</L.LABEL
><B.BODY>ObjectTeam stores project data in a database. The database management system (DBMS) used is Sybase SQL Anywhere. By default, the installation program automatically installs the database software on the server.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>ObjectTeam license manager</L.LABEL
><B.BODY>The various features of ObjectTeam, such as browsers and code generators, are all licensed individually. In ObjectTeam, a licensing system maintains a count of the usage of each feature. The license management system used by ObjectTeam is FLEXlm from Globetrotter Software. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Installation types</L.LABEL
><B.BODY>ObjectTeam distinguishes between the following types of machine:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>This is a machine that runs all the ObjectTeam server software as well as the client software. There must always be a single Master server present in your network. </CELLBODY
><CELLBODY>In a default installation, the Master server also runs the SQL Anywhere software and the License server software.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>This is an optional server running on a separate machine from the Master server. You can choose to install one or more Slave servers to distribute the load of the Master server. </CELLBODY
><CELLBODY>A Slave server runs a subset of the ObjectTeam server and SQL Anywhere software. You can also choose to install the client software together with the Slave server software. </CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>This is a machine that only runs the client software. </CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example configurations</L.LABEL
><B.BODY>Which installation you perform on a machine depends on what kind of overall configuration in which you want to run ObjectTeam. The following examples show some default configurations covered by the instructions in this guide.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Standalone</SL.SUBLABEL
><B.BODY>This is the simplest configuration. A single machine is configured as Master server, and is running the ObjectTeam server software, ObjectTeam client software, SQL Anywhere software and FLEXlm license software. You might use this if you are working on a laptop for example.</B.BODY
><B.BODY>You can run a standalone ObjectTeam installation under Windows 95 or Windows NT. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Client/server</SL.SUBLABEL
><B.BODY>In this example, a machine configured as Master server is running the ObjectTeam server and client software and is serving multiple client machines. The SQL Anywhere software and FLEXlm license software are also installed on the Master server. </B.BODY
><B.BODY>In a client/server installation, the server only runs on Windows NT. Client software runs on both Windows 95 and Windows NT.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Distributed Master and Slave servers</SL.SUBLABEL
><FA.FIGURE.ANCHOR>In this example, to spread the load on the Master server, a separate machine has been configured as an ObjectTeam Slave server and is serving several of its own clients. </FA.FIGURE.ANCHOR
><B.BODY>In a Master/Slave configuration, the Master and Slave must be running under Windows NT Server rather than Windows NT Workstation.</B.BODY
><B.BODY>The Master server runs SQL Anywhere <CX5FX5FTERM>server</CX5FX5FTERM
> software. Slave servers run SQL Anywhere <CX5FX5FTERM>client</CX5FX5FTERM
> software. The correct database software is installed along with the ObjectTeam software when you install a Master or Slave server. ObjectTeam clients do not run any SQL Anywhere software.</B.BODY
><B.BODY>ObjectTeam client machines can run off either the Master or Slave server. By default, the maximum number of client computers you can attach to a server is unlimited.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Custom installations</L.LABEL
><B.BODY>The default ObjectTeam installation automates where components such as the database and license manager software are installed. Depending on the size of your ObjectTeam installation, you may want to customize your installation to improve performance.</B.BODY
><B.BODY>For details on the requirements for these packages, read the Certification matrix. Hardware requirements for your workstation are displayed during the installation procedure. </B.BODY
><B.BODY>You should also read the ObjectTeam Read Me First Notes before starting installation. These contain last&truehy;minute product information that may affect the installation. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Reading the ObjectTeam Certification matrix and Read Me First Notes</L.LABEL
><B.BODY>The ObjectTeam client software requires the system to be configured with Microsoft TCP/IP network software. Note that your PC must have a static IP address.</B.BODY
><B.BODY>Refer to your operating system documentation (from Microsoft) for information on how to enable the TCP/IP protocol.</B.BODY
><B.BODY>Before you perform any installation, it is best to do a backup of all important data on your system, including the registries. If your backup software doesn’t support backing up registries, back these up separately following the instructions below.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>The Windows Registry</L.LABEL
><B.BODY>When you perform an installation on Windows NT or 95, various changes are made to the registry. This file is used by Windows to set its environment at start up. If this file becomes corrupted—for example, because of a problem during an installation—Windows will not be able to start up. </B.BODY
><B.BODY>It is therefore recommended that you save your registry to a file and back it up both <CX5FX5FTERM>before</CX5FX5FTERM
> and <CX5FX5FTERM>after</CX5FX5FTERM
> installing or upgrading ObjectTeam (or any other software). That way, if something goes wrong during the installation, and the registry becomes corrupted, you can restore it.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to back up your registry</L.LABEL
><B.BODY>Usually when you install an application, information about that application is written to the registry, and the previous contents of the registry are copied to a backup file. Windows keeps several backups. You can force Windows to make a backup of the current registry using the Repair Disk Utility.</B.BODY
><RBW-PARABODY>Click on Create Emergency Disk.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>A dialog appears prompting you to insert a floppy. This option creates a floppy from which you can boot, in the event that your registry becomes completely corrupted.</LR.LIST.RESULT
><RBW-PARABODY>Press the space bar and follow the instructions to restore the previous configuration.</RBW-PARABODY
></LN.LIST.NUM
><B.BODY>If your registry is completely corrupted and all copies have been lost, you must boot from the emergency floppy you made earlier.</B.BODY
></LABEL
></SECTION
><SECTION><S.SECTION.HEAD>Creating a <RBW-ANCHOR ID="18228"></RBW-ANCHOR
>User Directory (Windows 95 Only)</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>ObjectTeam reads and writes environment variables to and from a file in the user’s home directory. In order to startup, users must have their own directory.</B.BODY
><B.BODY>Under Windows NT, this is set by default. Under Windows 95, you must set this option.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Creating a User Profile on Windows 95</L.LABEL
><B.BODY>Before users can use the ObjectTeam product on Windows 95, a profiles environment must be created. A user profile allows a user to customize his or her own preferences and desktop settings. </B.BODY
><B.BODY>The amount of virtual memory required to run ObjectTeam depends, in part, on the size of your projects. Initially, Cayenne recommends 75 to 125 MB. As you continue to use the product and your projects grow, you might need to adjust the virtual memory setting on your workstation. You can specify the amount of virtual memory for any local drive that has space available for permanent memory. You must specify virtual memory as permanent.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to check and set virtual memory for Windows NT 4.0</L.LABEL
><RBW-PARABODY>In the Virtual Memory box, check to see that the total paging file size for all disk volumes is in the 75&truehy;125 MB range. If it is not, select the Change button.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>Reset the total paging file size in the Virtual Memory window and select OK.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to check and set virtual memory for Windows 95</L.LABEL
><B.BODY>This chapter guides you through the installation of the ObjectTeam software. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Upgrading</SL.SUBLABEL
><B.BODY>If you are upgrading from a previous ObjectTeam installation, go to <RBW-XREF REFID="21035" TYPE="XREF-TEXTCOPY">Chapter 3, Upgrading From a Previous Release</RBW-XREF
>, instead.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Backing up</L.LABEL
><B.BODY>As a precaution, before installing this or any product, you should perform a backup of your system. For details, see <RBW-XREF REFID="32992" TYPE="XREF-TEXTCOPY">Backing Up Your System</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Default directory</L.LABEL
><B.BODY>In this chapter, the installation directory for the ObjectTeam product files is indicated as <CX5FX5FTERM>M4_home</CX5FX5FTERM
>. By default, this is C:\Cayenne\Tools\.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><RBW-PARABODY>In standalone configuration under Windows NT or Windows 95</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>For more information on these configurations, see <RBW-XREF REFID="12336" TYPE="XREF-TEXTCOPY">Choosing an Installation Type</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Requirements</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Windows NT</SL.SUBLABEL
><B.BODY>If you are installing in client/server configuration, you must be running Windows NT server. If you are installing in standalone configuration, you can use Windows NT Server or Windows NT Workstation.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Windows 95</SL.SUBLABEL
><B.BODY>If you are installing in standalone configuration under Windows 95, make sure you have user profiles configured, as described in <RBW-XREF REFID="18228" TYPE="XREF-TEXTCOPY">Creating a User Directory (Windows 95 Only)</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Steps</L.LABEL
><B.BODY>Installation of an ObjectTeam Master server (including in standalone configuration) involves the following steps:</B.BODY
><B.BODY>To install ObjectTeam 7.1.1, you must configure licensing. How you do this depends on whether you have a temporary or permanent license:</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Temporary license</SL.SUBLABEL
><B.BODY>You must install your ObjectTeam license, as described in this section.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Permanent license</SL.SUBLABEL
><B.BODY>You must install a license server, as decribed in <RBW-XREF REFID="19159" TYPE="XREF-TEXTCOPY">Appendix B, Configuring a License Server</RBW-XREF
>. After you have done that, continue to <RBW-XREF REFID="39892" TYPE="XREF-TEXTCOPY">Install the ObjectTeam Product Files</RBW-XREF
><RBW-PARABODY>Via email, copy and paste the new feature information into an empty text file and save it as C:\cayenne\flexlm\license\cayenne.dat</RBW-PARABODY
><RBW-PARABODY>Via fax, enter the new feature information by hand into an empty text file, and save it as C:\cayenne\flexlm\license\cayenne.dat</RBW-PARABODY
></LB2.LIST.BULLET.2
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Obtaining a permanent license</L.LABEL
><B.BODY>Your temporary license allows you to install and run ObjectTeam for a limited period. </B.BODY
><B.BODY>If after installing ObjectTeam, you decide you want to make your installation permanent, you need to obtain a permanent license. For details on how to obtain a permanent license, see <RBW-XREF REFID="19159" TYPE="XREF-TEXTCOPY">Appendix B, Configuring a License Server</RBW-XREF
><LT.LIST.TEXT>For details on installing DocIt or DocExpress, see <RBW-XREF REFID="16254" TYPE="XREF-TEXTCOPY">Appendix A, Installing DocExpress and DocIt</RBW-XREF
><RBW-PARABODY>To view ObjectTeam’s Read Me First Notes, click the Product Notes button. </RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>The Read Me First Notes contain last&truehy;minute product information that may affect the installation. You <CX5FX5FFILE.NAME>must</CX5FX5FFILE.NAME
> read these notes before starting installation!</LT.LIST.TEXT
><RBW-PARABODY>Click Install to proceed with the installation.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The Product Requirements dialog box shows you the complete list of hardware and software requirements for your selected components. </LR.LIST.RESULT
><RBW-PARABODY>If your workstation meets all of the listed hardware and software requirements, click Continue to proceed with installation.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The ObjectTeam install program starts up.</LR.LIST.RESULT
> A dialog box is displayed asking you to make sure that TCP/IP is configured. For details on how to do this, refer to your Windows 95 documentation or Online Help. Click OK to continue.</RBW-PARABODY
><RBW-PARABODY>The Select Products dialog box displays the default selection of components to install. For a Master server installation, select Server files, Sybase SQL Anywhere files, and Client files. Optionally, select Help files and Product Documentation files. </RBW-PARABODY
>If you want to use an existing Sybase SQL Anywhere 5.5 installation, do not select the option to install this software. However, before you can use your existing installation, you must move the SQL Anywhere settings for SQLANY and PATH to the Windows NT <CX5FX5FTERM>system</CX5FX5FTERM
> environment. If you do choose to install the SQL Anywhere software, it is installed in the <CX5FX5FTERM>M4_home</CX5FX5FTERM
>\sqlany55 directory and these variables are set automatically. </N2.NOTE.2
><RBW-PARABODY>By default, the ObjectTeam software is installed in C:\Cayenne\Tools\. If you wish to install ObjectTeam elsewhere, click on the Browse... button and select the desired location. </RBW-PARABODY
><RBW-PARABODY>The Server Broker Port Information dialog asks you to enter the broker port you want to use to communicate with clients. Click Next to accept the default of 1825. </RBW-PARABODY
>If you change this setting, you must also change it during every client and Slave server installation. If the numbers don’t match, the client will not be able to communicate with the Broker.</W2.WARNING.2
><RBW-PARABODY>If you are running the license server software on this machine, or your license file is stored locally, the default is C;\Cayenne\Flexlm\license\cayenne.dat. </RBW-PARABODY
><RBW-PARABODY>If you are running the license server software on another machine, you must identify the port being used by the license service on the server and the host name of the server. On the license server, open the license file cayenne.dat in a text editor. The port appears as the last field on the SERVER line. Cayenne Software uses the port number 7126 by default. For example:</RBW-PARABODY
>If LM_LICENSE_FILE is set in your environment for some other vendor’s software, enter the displayed path with the location of your ObjectTeam license file appended to the end, separated from the previous path by a semi&truehy;colon (;).</N2.NOTE.2
><LR.LIST.RESULT>The installation script installs menus in the Start menu, and installs the Cayenne Repository Broker as a system service. </LR.LIST.RESULT
><LR.LIST.RESULT>You are returned to the Cayenne Install Wizard.</LR.LIST.RESULT
><RBW-PARABODY>Select Now and click on OK.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Next step</L.LABEL
><B.BODY>To complete the ObjectTeam installation on the Master server, create a repository for your project data, as described in <RBW-XREF REFID="10971" TYPE="XREF-TEXTCOPY">Create a Cayenne Repository</RBW-XREF
><B.BODY>After you have installed the ObjectTeam Master server software from the CD, and rebooted your system to automatically start the ObjectTeam system services, create a repository for your project data. </B.BODY
><RBW-PARABODY>Fill in the fields, then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>A Monitor window is started which runs the dbserver command to create the repository. If the repository is created successfully, it becomes selected in the Corporate Management tool.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Fields</L.LABEL
><B.BODY>The New Repository dialog contains the following fields:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The name of the corporate repository. This will appear as the corporate object (that is the top level) in the ObjectTeam Browser.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Make this repository the default</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>This makes this repository the one that will be displayed in your Browser. You should select this.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Directory in which to create the repository</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY> The full pathname of the directory in which the file&truehy;system part of the repository is stored. The recommended value is C:\Cayenne\repos.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Optional. The directory in which all generated files, such as code files, are stored. The value specified here is assigned to the corporate&truehy;level File System Path Part property. Cayenne strongly recommends that you specify a directory on a network drive.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The full pathname of the directory in which database files are stored. The recommended value is C:\Cayenne\repos.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>You specify a password for the database here. This is used by ObjectTeam to access the database. To enter a password, click on the Enter button. This opens an entry dialog in which you can enter the password. The password must start with a letter. You cannot click OK until you have entered a password. </CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Optional. The name of the machine on which SQL Anywhere is running. Only fill this in if you are creating a repository on a Slave server. Do not fill it in if you are creating a repository on the Master server (the default situation).</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Optional: This is the name of the SQL Anywhere server. (Note this does not refer to the machine name.) Only fill this in if you are running SQL Anywhere on a machine other than the Master server. Do not fill it in if you are running SQL Anywhere on the Master server (the default situation).</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Short pathnames</L.LABEL
><B.BODY>Do not enter pathnames containing spaces in the Repository directory or Database directory fields. Use the short name instead. For example, instead of:</B.BODY
><RBW-PARABODY>In the Corporate Management tool, if the repository is not already selected, select View | Refresh and select the new repository.</RBW-PARABODY
><B.BODY>ObjectTeam consists of a base product and a number of optional features. Each optional feature is implemented as an ObjectTeam module. If you have purchased any such feature, the corresponding modules should first be activated.</B.BODY
><B.BODY>For details on how to activate modules, go to <RBW-XREF REFID="38042" TYPE="XREF-TEXTCOPY">Activating Modules</RBW-XREF
>Installing an ObjectTeam Slave Server</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This section explains how to install ObjectTeam on a machine running as Slave server in a client/server configuration under Windows NT.</B.BODY
><B.BODY>For more information on this configuration, see <RBW-XREF REFID="12336" TYPE="XREF-TEXTCOPY">Choosing an Installation Type</RBW-XREF
>.</B.BODY
><B.BODY>Before you install a Slave server, you must have an ObjectTeam Master server in your network.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Steps</L.LABEL
><B.BODY>Installation of an ObjectTeam Slave server involves the following steps:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="40681" TYPE="XREF-TEXTCOPY">Share the Disk Containing the Repository Directory</RBW-XREF
> (the directory on the Master server on which the file system portion of the repository is stored.</CELLBODY
><RBW-PARABODY>When you installed a Master server, you should have selected the option Client/Server. Selecting this enables an SQL Anywhere database client on the Slave server to connect to the SQL Anywhere server on the Master server.</RBW-PARABODY
><RBW-PARABODY>Make sure the path for the SQL Anywhere executable is correct. If it is not, click on Path and locate the executable (by default C:\Cayenne\Tools\Sqlany55\Win32\Dbsrv50.exe). </RBW-PARABODY
><RBW-PARABODY>Details of an account under which the Slave can log onto the Master to access these services</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>The ObjectTeam services must be run under this account so that the remote disk can be attached. The account should be an account in the Administrator group, in any Domain. The account must have the right “log on as a service”. If you specify an account that does not have the “log on as a service” right, then when the ot_broker attempts to start, when you reboot, you will get an error.</B.BODY
><RBW-PARABODY>Select the ObjectTeam Broker Service and click Startup, and type in the new password for the user account in the form that is displayed.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>You will get a message back that says the account has been granted the “log on as a service” right.</LR.LIST.RESULT
><LT.LIST.TEXT>For details on installing DocIt or DocExpress, see <RBW-XREF REFID="16254" TYPE="XREF-TEXTCOPY">Appendix A, Installing DocExpress and DocIt</RBW-XREF
><RBW-PARABODY>To view ObjectTeam’s Read Me First Notes, click the Product Notes button. </RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>The Read Me First Notes contain last&truehy;minute product information that may affect the installation. You <CX5FX5FFILE.NAME>must</CX5FX5FFILE.NAME
> read these notes before starting installation!</LT.LIST.TEXT
><RBW-PARABODY>Click Install to proceed with the installation.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The Product Requirements dialog box shows you the complete list of hardware and software requirements for your selected components. </LR.LIST.RESULT
><RBW-PARABODY>If your workstation meets all of the listed hardware and software requirements, click Continue to proceed with installation.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The ObjectTeam install program starts up.</LR.LIST.RESULT
> A dialog box is displayed asking you to make sure that TCP/IP is configured. For details on how to do this, refer to your Windows 95 documentation or Online Help. Click OK to continue.</RBW-PARABODY
><RBW-PARABODY>The Select Products dialog box displays the default selection of components to install. For a Slave server installation, select Server files, Sybase SQL Anywhere files, and Client files. Optionally, select Help files and Product Documentation files. </RBW-PARABODY
>If you want to use an existing Sybase SQL Anywhere 5.5 installation, do not select the option to install this software. However, before you can use your existing installation, you must move the SQL Anywhere settings for SQLANY and PATH to the Windows NT <CX5FX5FTERM>system</CX5FX5FTERM
> environment. If you do choose to install the SQL Anywhere software, it is installed in the <CX5FX5FTERM>M4_home</CX5FX5FTERM
>\sqlany55 directory and these variables are set automatically. </N2.NOTE.2
><RBW-PARABODY>By default, the ObjectTeam software is installed in C:\Cayenne\Tools\. If you wish to install ObjectTeam elsewhere, click on the Browse... button and select the desired location. </RBW-PARABODY
><RBW-PARABODY>The Slave Server Configuration dialog asks you for the Master server hostname and the UNC path. Enter these.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>The UNC (Universal Naming Convention) is the share name of the disk on the Master server on which the repository directory is stored. It must have the following format:</LT.LIST.TEXT
><RBW-PARABODY>The User Account dialog asks you for details of the user account under which the services will be started. The services must be run under this account so that the remote disk can be attached. </RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>The account should be an account in the Administrator group, in any Domain. The account must have the right “log on as a service”. If you specify an account that does not have the “log on as a service” right, then when the ot_broker attempts to start, you will get an error. For details on how to give an account this right, see <RBW-XREF REFID="13913" TYPE="XREF-TEXTCOPY">Configure a User Account</RBW-XREF
>The server name is the name (not the IP address) of the ObjectTeam Master server. </N2.NOTE.2
><LT.LIST.TEXT>The default broker port is 1825. You must enter the same number as you entered when you installed the Master server. If the numbers don’t match, the client will not be able to communicate with the ot_broker on the Master server. If you are in doubt as to the correct number, check the value of the M4_brokerport variable in the <CX5FX5FTERM>M4_home</CX5FX5FTERM
>/etc/m4env.m4env file on the Master server.</LT.LIST.TEXT
><RBW-PARABODY>The Repository Name dialog asks you for the name of the repository you want to connect to. Enter a repository name and click Next.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The repository name is entered as the M4_levelpath variable in the M4_home\etc\m4env.m4env file. </LR.LIST.RESULT
><RBW-PARABODY>If you are running the license server software on this machine, or your license file is stored locally, the default is C;\Cayenne\Flexlm\license\cayenne.dat. </RBW-PARABODY
><RBW-PARABODY>If you are running the license server software on another machine, you must identify the port being used by the license service on the server and the host name of the server. On the license server, open the license file cayenne.dat in a text editor. The port appears as the last field on the SERVER line. Cayenne Software uses the port number 7126 by default. For example:</RBW-PARABODY
>If LM_LICENSE_FILE is set in your environment for some other vendor’s software, enter the displayed path with the location of your ObjectTeam license file appended to the end, separated from the previous path by a semi&truehy;colon (;).</N2.NOTE.2
><LR.LIST.RESULT>The installation script installs menus in the Start menu, and installs the Cayenne Repository Broker as a system service. </LR.LIST.RESULT
><LR.LIST.RESULT>You are returned to the Cayenne Install Wizard.</LR.LIST.RESULT
><RBW-PARABODY>Select Now and click on OK.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Next steps</L.LABEL
><B.BODY>ObjectTeam consists of a base product and a number of optional features. Each optional feature is implemented as an ObjectTeam module. If you have purchased any such feature, the corresponding modules should first be activated.</B.BODY
><B.BODY>For details on how to activate modules, go to <RBW-XREF REFID="38042" TYPE="XREF-TEXTCOPY">Activating Modules</RBW-XREF
> Configure ObjectTeam modules as described in <RBW-XREF REFID="38042" TYPE="XREF-TEXTCOPY">Chapter 4, Activating Modules</RBW-XREF
>.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Before you begin</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Windows 95</SL.SUBLABEL
><B.BODY>Before starting, make sure you have user profiles configured, as described in <RBW-XREF REFID="18228" TYPE="XREF-TEXTCOPY">Creating a User Directory (Windows 95 Only)</RBW-XREF
><LT.LIST.TEXT>For details on installing DocIt or DocExpress, see <RBW-XREF REFID="16254" TYPE="XREF-TEXTCOPY">Appendix A, Installing DocExpress and DocIt</RBW-XREF
><RBW-PARABODY>To view ObjectTeam’s Read Me First Notes, click the Product Notes button. </RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>The Read Me First Notes contain last&truehy;minute product information that may affect the installation. You <CX5FX5FFILE.NAME>must</CX5FX5FFILE.NAME
> read these notes before starting installation!</LT.LIST.TEXT
><RBW-PARABODY>Click Install to proceed with the installation.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The Product Requirements dialog box shows you the complete list of hardware and software requirements for your selected components. </LR.LIST.RESULT
> A dialog box is displayed asking you to make sure that TCP/IP is configured. For details on how to do this, refer to your Windows 95 documentation or Online Help. Click OK to continue.</RBW-PARABODY
><RBW-PARABODY>The Select Products dialog box displays the default selection of components to install. For a Client installation, select Client files. Optionally, select Help files and Product Documentation files. </RBW-PARABODY
><RBW-PARABODY>By default, the ObjectTeam software is installed in C:\Cayenne\Tools\. If you wish to install ObjectTeam elsewhere, click on the Browse... button and select the desired location. </RBW-PARABODY
>The server name is the name (not the IP address) of the computer running the ObjectTeam Master or Slave server software. </N2.NOTE.2
><LT.LIST.TEXT>The default broker port is 1825. You must enter the same number as you entered when you installed the Master server. If the numbers don’t match, the client will not be able to communicate with the ot_broker on the server. If you are in doubt as to the correct number, check the value of the M4_brokerport variable in the <CX5FX5FTERM>M4_home</CX5FX5FTERM
>/etc/m4env.m4env file on the Master server.</LT.LIST.TEXT
><RBW-PARABODY>The Repository Name dialog asks you for the name of the repository you want to connect to. Enter a repository name and click Next.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The repository name is entered as the M4_levelpath variable in the <CX5FX5FTERM>M4_home</CX5FX5FTERM
><RBW-PARABODY>If you are running the license server software on this machine, or your license file is stored locally, the default is C;\Cayenne\Flexlm\license\cayenne.dat. </RBW-PARABODY
><RBW-PARABODY>If you are running the license server software on another machine, you must identify the port being used by the license service on the server and the host name of the server. On the license server, open the license file cayenne.dat in a text editor. The port appears as the last field on the SERVER line. Cayenne Software uses the port number 7126 by default. For example:</RBW-PARABODY
>If LM_LICENSE_FILE is set in your environment for some other vendor’s software, enter the displayed path with the location of your ObjectTeam license file appended to the end, separated from the previous path by a semi&truehy;colon (;).</N2.NOTE.2
> The installation script places menus in your Start menu, then modifies your AUTOEXEC.BAT file to set the system environment variables. </LR.LIST.RESULT
><LR.LIST.RESULT>You are returned to the Cayenne Install Wizard.</LR.LIST.RESULT
><B.BODY>ObjectTeam consists of a base product and a number of optional features. Each optional feature is implemented as an ObjectTeam module. If you have purchased any such feature, the corresponding modules should first be activated.</B.BODY
><B.BODY>For details on how to activate modules, go to <RBW-XREF REFID="38042" TYPE="XREF-TEXTCOPY">Activating Modules</RBW-XREF
>How to start the ObjectTeam Browser remotely</L.LABEL
><B.BODY>Normally you will run the ObjectTeam client software from the machine it is installed on. It is also possible to install the client software on one client or server machine and run it from another machine over the network.</B.BODY
><B.BODY>This section describes how to uninstall an ObjectTeam Master server.</B.BODY
></LABEL
><SUBSECTION><SS.SUBSEC.HEAD>Uninstalling a Master Server</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This section describes how to uninstall an ObjectTeam Master server or Standalone machine under Windows NT or a Standalone machine on Windows 95:</B.BODY
><B.BODY>Be aware that all configuration files will be removed by the uninstall. You must remove the repository directory by hand.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Process overview</L.LABEL
><B.BODY>Uninstalling ObjectTeam consists of the following tasks:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>On the Master server, remove the Cayenne Repository broker and all SQL Anywhere services.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>On every machine on which you installed ObjectTeam software, run the Uninstall program.</CELLBODY
><RBW-PARABODY>Make sure the options Database, Directory and Server entry are checked. Also make sure the the option “Shutdown dbservers before deletion” is checked.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>All ObjectTeam dbservers will shut down after all users have exited ObjectTeam applications.</LR.LIST.RESULT
><B.BODY>This chapter describes the procedures to follow if you wish to upgrade ObjectTeam version 5.x or 6.1.1 to version 7.1.1 on PCs running Microsoft Windows. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Before you start</L.LABEL
><B.BODY>Before starting this upgrade procedure, you must have:</B.BODY
><B.BODY>As a precaution, before installing this or any product, you should perform a backup of your system. For details, see <RBW-XREF REFID="32992" TYPE="XREF-TEXTCOPY">Backing Up Your System</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Default directory</L.LABEL
><B.BODY>In this chapter, the installation directory for the ObjectTeam product files is indicated as <CX5FX5FTERM>M4_home</CX5FX5FTERM
>. By default, this is C:\Cayenne\Tools\, however you can install ObjectTeam elsewhere on your machine.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Reading the Read Me First Notes</L.LABEL
><B.BODY>The Read Me First Notes contain last&truehy;minute product information that may affect the installation. You must read these notes before starting installation.</B.BODY
><B.BODY>To read the Read Me First Notes, open the file <CX5FX5FTERM>cd_drive</CX5FX5FTERM
>:\readme.txt in a text editor, or open the file <CX5FX5FTERM>cd_drive</CX5FX5FTERM
>:\readme.htm in a Web browser.</B.BODY
><B.BODY>For details of the supported Operating Systems and DBMS versions, open the file <CX5FX5FTERM>cd_drive</CX5FX5FTERM
>:\certify.htm in a web browser.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><B.BODY>In ObjectTeam, a repository consists of a database part and a file system part. The directory in which the file system part is stored is called the repository directory. This contains individual directories for each repository, called corporate directories. </B.BODY
><B.BODY>To convert your repository data to ObjectTeam 7.1.1, you must first dump the data from each repository to disk. The ObjectTeam dump facility dumps data from a single repository into its corresponding corporate directory. The result is a structure like the following:</B.BODY
><RBW-PARABODY>Before you dump your repository you should make sure it is complete by uploading the working versions of files in the file system, such as generated source files.</RBW-PARABODY
>Back Up Your ObjectTeam Installation</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Once you have dumped and backed up all repositories, you should make a complete backup of your ObjectTeam installation AND your repository databases. If for any reason you want to go back to your previous installation you can then restore your entire environment.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Backing up your ObjectTeam installation </L.LABEL
>If you have dumped any repositories to directories outside <CX5FX5FTERM>M4_home</CX5FX5FTERM
>, be sure to back up these directories as well.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customization files</L.LABEL
><B.BODY>If you have made any customizations to files on Corporate level (those in the <CX5FX5FTERM>M4_home</CX5FX5FTERM
>\etc directory and <CX5FX5FTERM>M4_home</CX5FX5FTERM
>\tcl directories) be aware that these are deleted during the upgrade to version 7.1.1. Lower&truehy;level customization files such as those on Project or System level, are stored in the repository, and are therefore not deleted by the upgrade procedure.</B.BODY
><B.BODY>You can restore files from your backup to the new module customization directories (<CX5FX5FTERM>M4_home</CX5FX5FTERM
>\modules\<CX5FX5FTERM>module</CX5FX5FTERM
>\etc) once you have run the upgrade, but be aware that customizations from 5.x or 6.1.1 may not work with 7.1.1. For more details on customization and modules, see the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
><B.BODY>Note also that the names of some customization files have changed from previous versions. For a complete list of all customization files, see the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
>Stop All ObjectTeam&truehy;Related Services</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Before you upgrade</L.LABEL
><B.BODY>When you dumped your repository data, you shutdown your ObjectTeam installation. Before you can upgrade, you must also remove any running ObjectTeam services.</B.BODY
><B.BODY>To upgrade to ObjectTeam 7.1.1, you must configure licensing. How you do this depends on whether you have a temporary or permanent license:</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Temporary license</SL.SUBLABEL
><B.BODY>You must install your ObjectTeam license, as described in this section</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Permanent license</SL.SUBLABEL
><B.BODY>You must install a license server, as decribed in <RBW-XREF REFID="19159" TYPE="XREF-TEXTCOPY">Appendix B, Configuring a License Server</RBW-XREF
>. After you have done that, continue to <RBW-XREF REFID="24896" TYPE="XREF-TEXTCOPY">Install the ObjectTeam Product Files</RBW-XREF
><RBW-PARABODY>Via email, copy and paste the new feature information into an empty text file and save it as C:\cayenne\flexlm\license\cayenne.dat</RBW-PARABODY
><RBW-PARABODY>Via fax, enter the new feature information by hand into an empty text file, and save it as C:\cayenne\flexlm\license\cayenne.dat</RBW-PARABODY
>Install the ObjectTeam Product Files</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Before you start</L.LABEL
><B.BODY>Before you install the ObjectTeam product files, check your PATH variable and remove any entries relating to your previous ObjectTeam and SQL Anywhere installation.</B.BODY
><LT.LIST.TEXT>For details on installing DocIt or DocExpress, see <RBW-XREF REFID="16254" TYPE="XREF-TEXTCOPY">Appendix A, Installing DocExpress and DocIt</RBW-XREF
><RBW-PARABODY>To view ObjectTeam’s Read Me First Notes, click the Product Notes button. </RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>The Read Me First Notes contain last&truehy;minute product information that may affect the installation. You <CX5FX5FFILE.NAME>must</CX5FX5FFILE.NAME
> read these notes before starting installation!</LT.LIST.TEXT
><RBW-PARABODY>Click Install to proceed with the installation.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The Product Requirements dialog box shows you the complete list of hardware and software requirements for your selected components. </LR.LIST.RESULT
><RBW-PARABODY>If you want to use an existing Sybase SQL Anywhere installation, select the second option. However, before you can use your existing installation, you must move the SQL Anywhere settings for SQLANY and PATH to the Windows NT system environment. The SQL software is then installed in the <CX5FX5FTERM>M4_home</CX5FX5FTERM
>\sqlany55 directory and the SQLANY and PATH variables are set automatically.</RBW-PARABODY
><RBW-PARABODY>You are asked if this is a standalone or client/server installation. For more details, see <RBW-XREF REFID="16080" TYPE="XREF-TEXTCOPY">Chapter 1, Preparing for Installation</RBW-XREF
>.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The setup program deletes your current installation. The ObjectTeam software loads into the directory you specified. A progress bar informs you of the progress of the installation.</LR.LIST.RESULT
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>This is the name of the SQL Anywhere database server. By default this is the same as <CX5FX5FTERM>host</CX5FX5FTERM
>. Note however, that <CX5FX5FTERM>server</CX5FX5FTERM
> does <CX5FX5FFILE.NAME>not</CX5FX5FFILE.NAME
> refer to the name of a machine.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
><B.BODY>For more details, type <CX5FX5FINPUT>convert61to71 &truehy;help</CX5FX5FINPUT
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The following line shows an example conversion:</B.BODY
><RBW-PARABODY>When you upgraded a Master server, you should have selected the option Client/Server. Selecting this enables an SQL Anywhere database client on the Slave server to connect to the SQL Anywhere server on the Master server.</RBW-PARABODY
><RBW-PARABODY>Make sure the path for the SQL Anywhere executable is correct. If it is not, click on Path and locate the executable (by default C:\Cayenne\Tools\Sqlany55\Win32\Dbsrv50.exe). </RBW-PARABODY
><LT.LIST.TEXT>For details on installing DocIt or DocExpress, see <RBW-XREF REFID="16254" TYPE="XREF-TEXTCOPY">Appendix A, Installing DocExpress and DocIt</RBW-XREF
><RBW-PARABODY>To view ObjectTeam’s Read Me First Notes, click the Product Notes button. </RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>The Read Me First Notes contain last&truehy;minute product information that may affect the installation. You <CX5FX5FFILE.NAME>must</CX5FX5FFILE.NAME
> read these notes before starting installation!</LT.LIST.TEXT
><RBW-PARABODY>Click Install to proceed with the installation.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The Product Requirements dialog box shows you the complete list of hardware and software requirements for your selected components. </LR.LIST.RESULT
><RBW-PARABODY>A confirmation dialog is displayed informing you of the consequence of your choice. Click Yes to continue or No to stop the upgrade.</RBW-PARABODY
><RBW-PARABODY>You are asked if you want to install SQL Anywhere. The default is Yes. (Choose No only if you want to use an existing SQL Anywhere 5.5 installation.)</RBW-PARABODY
><RBW-PARABODY>You are asked for the installation directory. The default is C:\Cayenne\Tools.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The setup program deletes your installation and the ObjectTeam software loads into the directory you specified. A progress bar indicates the progress of the installation.</LR.LIST.RESULT
><RBW-PARABODY>The User Account dialog asks you for details of the user account under which the services will be started. The services must be run under this account so that the remote disk can be attached. </RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>The account should be an account in the Administrator group, in any Domain. The account must have the right “log on as a service”. If you specify an account that does not have the “log on as a service” right, then when the ot_broker attempts to start, you will get an error. For details on how to give an account this right, see <RBW-XREF REFID="13913" TYPE="XREF-TEXTCOPY">Configure a User Account</RBW-XREF
><RBW-PARABODY>If you are running the license server software on this machine, or your license file is stored locally, the default is C:\Cayenne\Flexlm\license\cayenne.dat. </RBW-PARABODY
><RBW-PARABODY>If you are running the license server software on another machine, you must identify the port being used by the license service on the server and the host name of the server. On the license server, open the license file cayenne.dat in a text editor. The port appears as the last field on the SERVER line. Cayenne Software uses the port number 7126 by default. For example:</RBW-PARABODY
>If LM_LICENSE_FILE is set in your environment for some other vendor’s software, enter the displayed path with the location of your ObjectTeam license file appended to the end, separated from the previous path by a semi&truehy;colon (;).</N2.NOTE.2
><LR.LIST.RESULT>The installation script places an ObjectTeam menu in your Start menu, then sets some system environment variables.</LR.LIST.RESULT
><LR.LIST.RESULT>You are returned to the Cayenne Install Wizard.</LR.LIST.RESULT
><RBW-PARABODY>Select Now and click on OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The setup program then reboots your computer.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Next steps</L.LABEL
><B.BODY>ObjectTeam consists of a base product and a number of optional features. Each optional feature is implemented as an ObjectTeam module. If you have purchased any such feature, the corresponding modules should first be activated.</B.BODY
><B.BODY>For details on how to activate modules, go to <RBW-XREF REFID="38042" TYPE="XREF-TEXTCOPY">Activating Modules</RBW-XREF
><LT.LIST.TEXT>For details on installing DocIt or DocExpress, see <RBW-XREF REFID="16254" TYPE="XREF-TEXTCOPY">Appendix A, Installing DocExpress and DocIt</RBW-XREF
><RBW-PARABODY>To view ObjectTeam’s Read Me First Notes, click the Product Notes button. </RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>The Read Me First Notes contain last&truehy;minute product information that may affect the installation. You <CX5FX5FFILE.NAME>must</CX5FX5FFILE.NAME
> read these notes before starting installation!</LT.LIST.TEXT
><RBW-PARABODY>Click Install to proceed with the installation.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The Product Requirements dialog box shows you the complete list of hardware and software requirements for your selected components. </LR.LIST.RESULT
><RBW-PARABODY>The Existing Installation dialog is displayed, informing you that an existing ObjectTeam installation has been detected. Select Next to upgrade your existing installation</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>Upgrading your existing installation removes your current installation, then makes a new installation. </LR.LIST.RESULT
><RBW-PARABODY>A confirmation dialog is displayed informing you of the consequence of your choice. Click Yes to continue or No to stop the upgrade.</RBW-PARABODY
><RBW-PARABODY>You are asked for the installation directory. The default is C:\Cayenne\Tools.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The ObjectTeam software loads into the directory you specified. A progress bar informs you of the progress of the installation.</LR.LIST.RESULT
><RBW-PARABODY>A dialog is displayed asking for the location of your license file. The default is C:\Cayenne\Flexlm\license\cayenne.dat. Click Next.</RBW-PARABODY
><RBW-PARABODY>If you are running the license server software on this machine, or your license file is stored locally, the default is C:\Cayenne\Flexlm\license\cayenne.dat. </RBW-PARABODY
><RBW-PARABODY>If you are running the license server software on another machine, you must identify the port being used by the license service on the server and the host name of the server. On the license server, open the license file cayenne.dat in a text editor. The port appears as the last field on the SERVER line. Cayenne Software uses the port number 7126 by default. For example:</RBW-PARABODY
>If LM_LICENSE_FILE is set in your environment for some other vendor’s software, enter the displayed path with the location of your ObjectTeam license file appended to the end, separated from the previous path by a semi&truehy;colon (;).</N2.NOTE.2
> The installation script places an ObjectTeam menu in your Start menu, then modifies your AUTOEXEC.BAT file to set the system environment variables. </LR.LIST.RESULT
><LR.LIST.RESULT>You are returned to the Cayenne Install Wizard.</LR.LIST.RESULT
><RBW-PARABODY>Select Now and click on OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The setup program then reboots your computer.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Next steps</L.LABEL
><B.BODY>ObjectTeam consists of a base product and a number of optional features. Each optional feature is implemented as an ObjectTeam module. If you have purchased any such feature, the corresponding modules should first be activated.</B.BODY
><B.BODY>For details on how to activate modules, go to <RBW-XREF REFID="38042" TYPE="XREF-TEXTCOPY">Activating Modules</RBW-XREF
><B.BODY>ObjectTeam consists of a base product and a number of optional features. Each optional feature is implemented as an ObjectTeam module. To use the feature, you must activate the module. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Licensing</L.LABEL
><B.BODY>Most modules require a valid license. If ObjectTeam displays license&truehy;related error messages, you may not have a valid license. </B.BODY
><B.BODY>Refer to <RBW-XREF REFID="19159" TYPE="XREF-TEXTCOPY">Appendix B, Configuring a License Server</RBW-XREF
> for more information.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Modules and repository levels</L.LABEL
><B.BODY>The instructions here cover how to activate modules on Corporate level for an entire corporate repository. You must have root access to do this. Modules activated on Corporate level are available by default for all users of this repository on every level.</B.BODY
><B.BODY>You do not have to activate all modules on Corporate level. Users can activate them on any other level in the repository, as long as they are licensed.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Which ObjectTeam modules are available</L.LABEL
><B.BODY>A <CX5FX5FTERM>module</CX5FX5FTERM
> is a directory of files that implement an optional ObjectTeam feature. The directory name is the module name. By default, all modules are stored in the modules directory of your <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
> directory.</B.BODY
><B.BODY>Modules on the following features are supplied with ObjectTeam. </B.BODY
>Not all modules are available on all platforms. </N.NOTE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Code Generation</SL.SUBLABEL
><B.BODY>In previous releases of ObjectTeam, target language for code generation was set using the variables M4_package and M4_target_lang. This mechanism has been replaced by modules. These variables are no longer used. </B.BODY
>The C++ code generation implemented in the <CX5FX5FFILE.NAME>C++ Code Generation</CX5FX5FFILE.NAME
> module is different from previous versions of ObjectTeam. The previous implementation of C++ code generation is available in the compatibility module <CX5FX5FFILE.NAME>Persistent C++ Generation</CX5FX5FFILE.NAME
>. For more details, see chapter on compatibility in the <CX5FX5FTITLE>ObjectTeam Code Generation Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for C++.</N.NOTE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>User&truehy;defined modules</SL.SUBLABEL
><B.BODY>You can create your own ObjectTeam modules. For details, see <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="13855"></RBW-ANCHOR
>How to Activate a Module on Corporate level</L.LABEL
>Because of the way customization files are read by ObjectTeam, you have to clone (or restart) the Browser if you want the changes made to <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> files on Corporate level and User Customization level to take effect.</N2.NOTE.2
><B.BODY>Customization files on these levels are only read at start&truehy;up.</B.BODY
> customization file contains one or more module specifications. Each module specification activates or deactivates a module. A <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> customization file can exist at any Browser level, from corporate level through user level</B.BODY
> files are incrementally read by ObjectTeam. The specifications in a <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file on Corporate level, for example, are read when a user starts ObjectTeam, whereas those in a <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file on Project level are read when a user opens the Project in the ObjectTeam Browser.</B.BODY
><B.BODY>The set of module specifications on a certain Browser level is the result of ObjectTeam’s adding module specifications from all the <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> files on higher levels.</B.BODY
><B.BODY>This implies that if you want the changes made in a certain <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file to take effect, you first have to make ObjectTeam read the <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
>If you made changes to a <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file on Corporate level or User Customization level, you cannot move up one level anymore; the changes only take effect if you either clone or restart the Browser.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>If the <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file was changed on Project level, in a project called ProjectX, for example, you should first move up (by selecting the Corporate object in the Navigation Area, for example). If you then open ProjectX again, ObjectTeam adds the module specifications in this file to the current set of module specifications.</B.BODY
><B.BODY>The Module Availability Editor is the tool with which you create, activate, delete and manipulate ObjectTeam module specifications. It starts up if you edit the customization file <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Brings up an information dialog box listing details, such as module type, module directory location and required modules</CELLBODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Checks if all the modules required by the modules in the Display Area have been added</CELLBODY
><CELLBODY>See Required Modules on page 4–10</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Filter on Current </CELLBODY
><CELLBODY>File Entries</CELLBODY
></ENTRY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Use this option if you only want to see those module specifications in the Display Area that can be edited on the current level.</CELLBODY
><B.BODY>Certain ObjectTeam modules require other modules to work properly, others are only supporting other modules, and some modules exclude each other. </B.BODY
><B.BODY>Every module directory contains a file called <CX5FX5FFILE.NAME>properties.properties</CX5FX5FFILE.NAME
>. This file contains certain fields through which dependencies between modules and module types are specified. These fields are discussed in this section.</B.BODY
><B.BODY>If a particular module require other modules in order to operate properly, the following fields can be used in the <CX5FX5FFILE.NAME>properties.properties</CX5FX5FFILE.NAME
><B.BODY>Users of the Module Availability Editor can see which modules and module types are required by a module by selecting Edit | Info. for that module. The Information Box that appears lists, among other things, the required modules and module types, if applicable.</B.BODY
><B.BODY>In this field, a list of required modules, separated by spaces, can be specified. If a module that requires other modules is selected in the Module Editor, the required module(s) will be automatically added to the <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file too.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>requiredModuleTypes</L.LABEL
><B.BODY>If a module requires another module, but there is more than one module of that type available, a list of required module <CX5FX5FEMPHASIS>types</CX5FX5FEMPHASIS
> is specified. If a module that requires other module types is selected in the Module Editor, a dialog box appears, listing all the available modules of that type. After a user of the Module Editor selects the module of his choice, this module is added to the <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file.</B.BODY
><B.BODY>In the <CX5FX5FFILE.NAME>properties.properties</CX5FX5FFILE.NAME
> file of the module C++ Code Generation, for example, the following module types are specified as requiredModuleTypes:</B.BODY
><B.BODY>You can check if all the requirements have been met for all the modules by selecting Check | Requirements in the Module Availability Editor. If there are any requirements missing, an Information dialog box will list them.</B.BODY
><B.BODY>Certain modules exclude each other: if the module C++ Code Generation is active for a particular system, for example, the module Java Code Generation cannot be active at the same time.</B.BODY
><B.BODY>The following fields in the <CX5FX5FFILE.NAME>properties.properties</CX5FX5FFILE.NAME
> file can be used to specify conflicting modules:</B.BODY
>A user of the Module Editor is still able to add a module that conflicts with another module, but will get an error message when he attempts to save the <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Saving a conflicting modules.modules file</L.LABEL
><B.BODY>When you try to save a <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file that contains conflicts, the following dialog box appears.</B.BODY
><B.BODY>The file is not saved. You should correct the conflict(s) by deactivating one of the conflicting modules (see Resolving Conflicting Modules on page 4–14 for details). </B.BODY
><B.BODY>Use Check | Conflicts to find out which modules are conflicting.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>No</SL.SUBLABEL
><B.BODY>All the modules in the <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> file that cause a conflict are deactivated, after which the file is saved.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Cancel</SL.SUBLABEL
><B.BODY>Cancels the operation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Viewing conflicting module (types)</L.LABEL
><B.BODY>Users of the Module Availability Editor can see which modules or module types are defined as conflicting with the module by selecting Edit | Info for that module. The Information Box that appears lists, among other things, the conflicting modules and module types, if applicable.</B.BODY
><B.BODY>In this field, a list of modules that are supposed to conflict with the current module can be specified. The list is separated by commas.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>conflictingModuleTypes</SL.SUBLABEL
><B.BODY>In this field, a list of module <CX5FX5FEMPHASIS>types</CX5FX5FEMPHASIS
> that are supposed to conflict with the current module are listed. The list is separated by commas.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Checking for conflicts</L.LABEL
><B.BODY>You can check for conflicts in the Module Availability Editor by selecting Check | Conflicts. If there are any conflicts, an Information dialog box will list them.</B.BODY
>Module specifications and browser levels</L.LABEL
><B.BODY>The Module Availability Editor displays the current set of module specifications: the result of incrementally read <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> files (see Checking if a module is active on page 4–5). You can only edit or delete the modules that have been added on the current level</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example of a module conflict</L.LABEL
><B.BODY>You could encounter a situation in which you would like to add and activate a module that conflicts with a module that has been added and activated on a higher level. For example, the C++ Code Generation module is activated on Corporate level, but for one particular Project you would like to generate Java code.</B.BODY
><RBW-PARABODY>Open the customization file <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> on the Browser level of your choice.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>The specifications you are going to add to this file will be valid on the current Browser level and below. (Project level and below, for example)</LT.LIST.TEXT
><RBW-PARABODY>In the Module Availability Editor, add the same module as the one on a higher level that is causing the conflict (C++ Code Generation, for example)</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>Use Edit | New to bring up the Select Module dialog box. Select the module of your choice from this box.</LT.LIST.TEXT
><RBW-PARABODY>Add the module that would conflict if the conflicting module on a higher level were not deactivated (Java Code generation, for example).</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>Make sure its state is <CX5FX5FEMPHASIS>on</CX5FX5FEMPHASIS
>.</LT.LIST.TEXT
><B.BODY>The new module is now only active for the configuration, phase, project or system for which the customization file <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
><B.BODY>Supporting modules are modules that are required by other modules, but are not useful independently. As users usually do not need to know about supporting modules, they are, by default, not listed in the Select Module dialog box. This box appears if a user of the Module Editor selects Edit | New.</B.BODY
>In order to use DocExpress, ObjectTeam must also be installed.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Licensing</L.LABEL
><B.BODY>DocExpress is licensed by the same license server that licenses ObjectTeam. Your ObjectTeam license file should contain feature lines for DocExpress. For more details on FLEXlm licensing, and how to add features to your license file, see <RBW-XREF REFID="19159" TYPE="XREF-TEXTCOPY">Appendix B, Configuring a License Server</RBW-XREF
><RBW-PARABODY>To view DocExpress’s Read Me First Notes, click the Product Notes button. </RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>The Read Me First Notes contain last&truehy;minute product information that may affect the installation. You <CX5FX5FFILE.NAME>must</CX5FX5FFILE.NAME
> read these notes before starting installation!</LT.LIST.TEXT
><RBW-PARABODY>Click Install to proceed with the installation.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The Product Requirements dialog box shows you the complete list of hardware and software requirements for your selected components. </LR.LIST.RESULT
><RBW-PARABODY>The install program asks you if you want it to set some environment variables. Click Next to let the setup set the variables.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>You are returned to the Cayenne Install Wizard.</LR.LIST.RESULT
><RBW-PARABODY>While still logged in as Administrator (or as a user who belongs to the Administrator group), select Start|Settings|Control Panel.</RBW-PARABODY
><B.BODY>You can access the ObjectTeam product documentation directly from the CD, as described in the CD insert. Alternatively you can install the product documentation on your hard drive.</B.BODY
><RBW-PARABODY>Install the DocIt software.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Licensing</L.LABEL
><B.BODY>DocIt is licensed by the same license server that licenses ObjectTeam. Your ObjectTeam license file should contain a feature line for DocIt. For more details on FLEXlm licensing, and how to add features to your license file, see <RBW-XREF REFID="19159" TYPE="XREF-TEXTCOPY">Appendix B, Configuring a License Server</RBW-XREF
><RBW-PARABODY>To view ObjectTeam’s Read Me First Notes, click the Product Notes button. </RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>The Read Me First Notes contain last&truehy;minute product information that may affect the installation. You <CX5FX5FFILE.NAME>must</CX5FX5FFILE.NAME
> read these notes before starting installation!</LT.LIST.TEXT
><RBW-PARABODY>Click Install to proceed with the installation.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The Product Requirements dialog box shows you the complete list of hardware and software requirements for your selected components. </LR.LIST.RESULT
><RBW-PARABODY>The install program asks you if you want it to set some environment variables. Click Next to let the setup set the variables.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>You are returned to the Cayenne Install Wizard.</LR.LIST.RESULT
><RBW-PARABODY>While still logged in as Administrator (or as a user who belongs to the Administrator group), select Start|Settings|Control Panel.</RBW-PARABODY
><RBW-PARABODY>How to obtain a permanent license</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Master server</SL.SUBLABEL
><B.BODY>You must follow the instructions in this chapter before you install or upgrade an ObjectTeam Master server. If you are installing a Slave server or Client, you must already have installed a Master server, so you can skip this chapter.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Demo installation</SL.SUBLABEL
><B.BODY>If you only want to install a demonstration copy of ObjectTeam for trial purposes, you can skip this chapter. A demo installation does not need a license server.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>UNIX license server</SL.SUBLABEL
><B.BODY>If you want to use a UNIX workstation as your license server, refer to the <CX5FX5FTITLE>ObjectTeam Installation Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
><CX5FX5FTERM> for UNIX&truehy;based Systems</CX5FX5FTERM
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Related documentation</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Required reading</SL.SUBLABEL
><B.BODY>You should read the <CX5FX5FTITLE>FLEXlm End User Manual</CX5FX5FTITLE
> before installing the FLEXlm license software. The FLEXlm manual provides valuable information on network license management and site customization; for example, it provides details about the license file and various license administration tools. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Recommended reading:</SL.SUBLABEL
><B.BODY>For more information on network license management and UNIX system administration, read the <CX5FX5FTITLE>FLEXlm Programmer’s Guide</CX5FX5FTITLE
> (available from Globetrotter Software, Inc.) and <CX5FX5FTITLE>Essential System Administration</CX5FX5FTITLE
> by Aeleen Frisch (published by O’Reilly & Associates, ISBN 0&truehy;937175&truehy;80&truehy;3).</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="14820" TYPE="XREF-TEXTCOPY">Licensing in ObjectTeam&rbwtab;B–3</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="39823" TYPE="XREF-TEXTCOPY">Installing the License Server Software&rbwtab;B–7</RBW-XREF
>If you are not interested in how licensing works and just want to get on with installation, skip to Installing the License Server Software on page B–7.</T.TIP
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>License components</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>License server</SL.SUBLABEL
><B.BODY>In an ObjectTeam installation, a single machine in the network acts as <CX5FX5FTERM>license server</CX5FX5FTERM
>. By default, this is the same machine as the ObjectTeam Master server. The license server consists of the following components:</B.BODY
>, that is started automatically when the machine is booted and runs as a service. This daemon receives requests for features from other workstations on the network and assigns them to the Cayenne daemon.</RBW-PARABODY
>, that points to the address of the license server</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Temporary licenses</L.LABEL
><B.BODY>To use ObjectTeam, you must obtain a license from Cayenne. Licenses are keyed to the ID of the machine on which you are running the license software. So before we can supply a license, you must inform us of this ID using the license request form.</B.BODY
><B.BODY>Issuing the license can take a day or so, so to get you started in the meantime, Cayenne supplies a <CX5FX5FTERM>temporary license</CX5FX5FTERM
> that is not linked to a machine ID. This temporary license is valid for a limited period and usually comes on a floppy in your ObjectTeam package, though you may also receive it via email or fax.</B.BODY
><B.BODY>The temporary license file is made up of <CX5FX5FTERM>feature lines</CX5FX5FTERM
>, each controlling the use of a single ObjectTeam feature. This is an example of a feature line:</B.BODY
><B.BODY>Until you receive the permanent license, you must install a copy of the temporary license on every workstation on which you install ObjectTeam software. The temporary license then controls access to all features on that machine itself; you cannot run a license server with a temporary license. </B.BODY
><B.BODY>During installation of ObjectTeam, you are prompted to set the LM_LICENSE_FILE variable to point to the location of your local temporary license file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Permanent licenses</L.LABEL
><B.BODY>A permanent license is what Globetrotter refers to in the <CX5FX5FTERM>FLEXlm End User Manual</CX5FX5FTERM
> as a <CX5FX5FTERM>floating license</CX5FX5FTERM
>. This means it is installed on a particular machine in the network that acts as a license server. The license server controls the usage of ObjectTeam features by any workstation connected to the license server.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Contents of a permanent license file</L.LABEL
><B.BODY>A license file is made up of a <CX5FX5FTERM>server line</CX5FX5FTERM
>, a <CX5FX5FTERM>daemon line</CX5FX5FTERM
> and a number of <CX5FX5FTERM>feature lines</CX5FX5FTERM
><RBW-PARABODY>The server line identifies the name and (encrypted) hostid or volume serial number of the license server, and the port on which it receives license requests.</RBW-PARABODY
><RBW-PARABODY>A feature line identifies a particular ObjectTeam licensed feature, the version of ObjectTeam for which it is valid, the expiry date and the number of workstations that can use it simultaneously. If this is a nodelocked feature, the hostid is also specified.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Replacing a temporary license with a permanent license</L.LABEL
><B.BODY>Once you receive your permanent license, you:</B.BODY
><RBW-PARABODY>Reset LM_LICENSE_FILE on each machine running ObjectTeam to point to the license server. On a machine other than the license server, LM_LICENSE_FILE has the format <CX5FX5FTERM>port</CX5FX5FTERM
>@<CX5FX5FTERM>server</CX5FX5FTERM
>, where <CX5FX5FTERM>port</CX5FX5FTERM
> is the TCP/IP port being used by the license server, and <CX5FX5FVARIABLE>server</CX5FX5FVARIABLE
> is the host name of the server running the license service. These are identified in the server line of the license file. </RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Licensing process</L.LABEL
><B.BODY>Once the license server is running, it controls the use of ObjectTeam features. When a user tries to start an ObjectTeam feature, such as a Browser, ObjectTeam:</B.BODY
><RBW-PARABODY>Examines LM_LICENSE_FILE to find the address of the license server. On a client for example, this has the format <CX5FX5FTERM>port</CX5FX5FTERM
><RBW-PARABODY>Makes a request for a feature with the appropriate name (such as OT_BROWSER_WIN). The request is passed to the license server at the specified address. </RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>The license manager daemon on the license server:</B.BODY
><RBW-PARABODY>Searches the license file for the feature with the specified name. On the feature line is also listed the name of the daemon which is reponsible for controlling this feature, namely <CX5FX5FTERM>cayenne</CX5FX5FTERM
><RBW-PARABODY>Passes the request to the cayenne daemon, which then grants or denies a license based on the number of licenses available.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing license files</L.LABEL
><B.BODY>Normally, your license file contains all the features that you need to use ObjectTeam. If you subsequently decide that you would like to use additional features of ObjectTeam, you can order additional licenses for each feature. To make a new license available, you simply add a new feature line to your existing license file.</B.BODY
><RBW-PARABODY>To add a new feature, type (or copy and paste) the new feature line into the file. If you are typing the license information, be careful to avoid typing mistakes.</RBW-PARABODY
>Installing the License Server Software</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Before you install or upgrade an ObjectTeam Master server, you must configure a machine in your network as a license server. This can be the same machine as the Master server (for example, in the case of a standalone installation), or some other machine.</B.BODY
><B.BODY>This section describes how to install the FLEXlm license software on a Master server or standalone machine, as well as the changes you need to make to certain server files.</B.BODY
>You cannot use a machine running Windows 95 as a license server in a client/server installation. If you want to run ObjectTeam in a client/server installation, you must use a machine running Windows NT as the license server. </N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="32637"></RBW-ANCHOR
>How to install the license management software</L.LABEL
><RBW-PARABODY>Double&truehy;click on setup.exe.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>You are prompted for the installation location of the FLEXlm files. The default is C:\Cayenne\Flexlm. You should install FLEXlm on the same drive on which you will install ObjectTeam. If there is not enough space on C drive, use another drive. If the Cayenne directory does not already exist, it is created.</LR.LIST.RESULT
><RBW-PARABODY>Permanent license, install the permanent license and start the license server, as described in Installing a Permanent License on page B–10.</RBW-PARABODY
><B.BODY>To carry out this procedure, your system must be configured with Microsoft TCP/IP network software. Note that your PC must have a static IP address and host name.</B.BODY
><B.BODY>Refer to your operating system documentation (from Microsoft) for information on how to enable the TCP/IP protocol.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Obtaining a permanent license</L.LABEL
><B.BODY>To obtain a permanent license, you must find out the host ID of your machine and submit it to Cayenne using the License Request Form. </B.BODY
><RBW-PARABODY>Go to the license request form provided on Cayenne Software’s World Wide Web page at: <CX5FX5FFILE.NAME>http://www.cayennesoft.com/license</CX5FX5FFILE.NAME
><B.BODY>Once you receive a permanent license, you can start the license server. Carry out the steps in this section while logged into the license server as Administrator (or as a user who belongs to the Administrator group).</B.BODY
><RBW-PARABODY>Via email, copy and paste the new feature information into an empty text file and save it as <CX5FX5FFILE.NAME>C:\Cayenne\Flexlm\license\cayenne.dat</CX5FX5FFILE.NAME
><RBW-PARABODY>Via fax, enter the new feature information by hand into an empty text file, and save it as <CX5FX5FFILE.NAME>C:\Cayenne\Flexlm\license\cayenne.dat</CX5FX5FFILE.NAME
><RBW-PARABODY>Open the license file in a text editor and check that the DAEMON line points to the correct location of the cayenne daemon, for example:</RBW-PARABODY
>How to set LM_LICENSE_FILE on the license server under Windows NT</L.LABEL
><B.BODY>On a license server running under Windows NT, you must now set the license file environment variable, LM_LICENSE_FILE, to point to the permanent license:</B.BODY
>If there is already an LM_LICENSE_FILE setting, then add the above path at the end of the line, separated from the previous path by a semi&truehy;colon (;).</N2.NOTE.2
><RBW-PARABODY>Fill in the Service name, location of the license daemon executable, location of the license file and where you wish log files to be stored. The following figure shows the recommended settings.</RBW-PARABODY
><RBW-PARABODY>Select the Start button to start the license server.</RBW-PARABODY
></LN.LIST.NUM
><B.BODY>For more information on using the control panel, such as how to stop or remove the service, see the <CX5FX5FTERM>FLEXlm End User Manual</CX5FX5FTERM
><B.BODY>If something fails during the installation, the best solution is to run the Uninstall script, as described in Uninstalling ObjectTeam Software on page 2–27, and run the setup program again. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Error messages</L.LABEL
><B.BODY>Many errors start with the message “Cannot initialize client context”. The important lines to look at are the last two or three lines. These usually contain some clear indication of the cause of the problem.</B.BODY
><B.BODY>When troubleshooting, be aware that some error messages only pop up after a timeout limit has been reached. These are usually set to one minute. If nothing happens, wait at least this time before taking action.</B.BODY
></LABEL
><SECTION><S.SECTION.HEAD>Changes Made During Installation</S.SECTION.HEAD
> Select Start | Settings | Control Panel, and double click on the Services control panel. Check that the ObjectTeam Broker service is running.</RBW-PARABODY
></P.PROCEDURE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes made in a Master server or standalone installation</L.LABEL
><B.BODY>The following changes are made for a Master server or standalone installation:</B.BODY
><RBW-PARABODY>The variable M4_home is set as an environment variable. All ObjectTeam tools use this variable. The default value is C:\Cayenne\tools.</RBW-PARABODY
>\etc\objservers.objservers is modified when you create a repository. For more details, see the <CX5FX5FTITLE>ObjectTeam System Administrator’s Guide</CX5FX5FTITLE
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>This is set if this machine is a Mster server in a client/server (i.e. not standalone) installation.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes made in a Slave server installation</L.LABEL
><RBW-PARABODY>The variable M4_home is set as an environment variable. All ObjectTeam tools use this variable. The default value is C:\Cayenne\tools.</RBW-PARABODY
><RBW-PARABODY>The variable M4_home is set as an environment variable. All ObjectTeam tools use this variable. The default value is C:\Cayenne\tools.</RBW-PARABODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The time to wait for contact with lockserver</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Error messages</L.LABEL
><B.BODY>When troubleshooting, be aware that some error messages only pop up after a timeout limit has been reached. These are usually set to five minutes. If nothing happens, wait at least this time before taking action.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>General troubleshooting</L.LABEL
><B.BODY>In the event of problems, check the <CX5FX5FTERM>M4_home</CX5FX5FTERM
>\logs\ot_brok.log file as well as the status of the ObjectTeam broker service.</B.BODY
></LABEL
></SECTION
><SECTION><S.SECTION.HEAD>Problems Starting the Browser or Other Tool</S.SECTION.HEAD
><EWM.EXAMPLEW.MONO>ERROR [120072]: Remote implementation ‘wronglevelpath’ not found.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [120014]: Request for ‘ot_broker’ at host ‘HOSTNAME’ timed out after 60000 milliseconds</EWM.EXAMPLEW.MONO
><B.BODY>The SQLANY variable is not set correctly and/or the Path variable is not set to %SQLANY%\win32 in the System Environment.</B.BODY
><B.BODY>Set the Sybase SQL Anywhere system environment variable SQLANY to point to the installation directory of SQL Anywhere. On Windows NT this is done in the System Control Panel. On Windows’95 this is done in the autoexec.bat file.</B.BODY
><B.BODY>The default value is C:\Cayenne\Tools\sqlany55.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Starting the browser</L.LABEL
><EWM.EXAMPLEW.MONO>ERROR [210040]: (Message not available)</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [001004]: Module 210 not initialized.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [001001]: Error while reading message file ‘etc/message/message.210’.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>SYSERR [000002]: No such file or directory</EWM.EXAMPLEW.MONO
><B.BODY>The M4_home variable is not set correctly</B.BODY
><B.BODY>Set the ObjectTeam system environment variable to point to the installation directory of ObjectTeam. On Windows NT this is done in the System Control Panel. On Windows 95 this is done in the autoexec.bat file.</B.BODY
><B.BODY>The default value is C:\Cayenne\Tools.</B.BODY
><EWM.EXAMPLEW.MONO>ERROR [120042]: Could not set address for broker at host ‘HOSTNAME’,port #number</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [011001] Host was not found</EWM.EXAMPLEW.MONO
><B.BODY>The M4_imphost variable is not set correctly</B.BODY
><B.BODY>Set the ObjectTeam client variable M4_imphost to the host where an ObjectTeam broker runs, e.g., M4_imphost=capella;RW. This variable is defined in the %M4_home%/etc/m4env.m4env file or in the .Meta4UserEnv file in your login directory.</B.BODY
><EWM.EXAMPLEW.MONO>ERROR [120072]: Remote implementation ‘levelpath’ not found.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [120014]: Request for ‘ot_broker’ at host ‘HOSTNAME’ timed out after 60000 milliseconds</EWM.EXAMPLEW.MONO
><B.BODY>The M4_brokerport variable is not set correctly.</B.BODY
><B.BODY>Set the ObjectTeam environment variable M4_brokerport to a number via which the broker can be reached. This variable is defined in %M4_home%/etc/m4env.m4env or in the .Meta4UserEnv file in your login directory. </B.BODY
><B.BODY>Default value: 1825</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Starting the browser</L.LABEL
><EWM.EXAMPLEW.MONO>ERROR [123002]: Could not checkout license for OT_BROWSER_WIN</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [123001]: FLEXlm: Cannot find license file (&truehy;1,73:2) No such file or directory</EWM.EXAMPLEW.MONO
><B.BODY>The LM_LICENSE_FILE variable is not set correctly.</B.BODY
><B.BODY>Set the FLEXlm system environment variable LM_LICENSE_FILE to point to:</B.BODY
>, if you are running a license server on another machine. To identify the port, log on to your machine running the license server and open the license file cayenne.dat The port appears as the last field on the server line, e.g., 7126@capella.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>On Windows NT this variable is set using in the Control Panel, System. On Windows 95 this variable is set in the autoexec.bat file.</B.BODY
><B.BODY>Note: If LM_LICENSE_FILE is set in your environment for some other vendor’s software, enter the displayed path with the location of your ObjectTeam license file appended on the end, separated from the previous path by a semicolon (;).</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Starting the browser</L.LABEL
><EWM.EXAMPLEW.MONO>ERROR [115024]: Cannot obtain corporate id for ‘corporate’.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [120051]: Name request for Corporate service ‘corporate’ not invoked.</EWM.EXAMPLEW.MONO
>, if you are running a license server on another machine. To identify the port, log on to your machine running the license server and open the license file cayenne.dat The port appears as the last field on the server line, e.g., 7126@capella.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>On Windows NT this variable is set using in the Control Panel, System. On Windows 95 this variable is set in the autoexec.bat file.</B.BODY
><B.BODY>Once you have set LM_LICENSE_FILE, reboot your machine.</B.BODY
><B.BODY>Note: If LM_LICENSE_FILE is set in your environment for some other vendor’s software, enter the displayed path with the location of your ObjectTeam license file appended on the end, separated from the previous path by a semicolon (;).</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Starting the Corporate Management Tool</L.LABEL
><EWM.EXAMPLEW.MONO>ERROR [115024]: Cannot obtain corporate id for ‘levelpath’.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [120051]: Name request for Corporate service ‘levelpath’ not invoked.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [120072]: Remote implementation ‘levelpath’ not found.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [120014]: Request for ‘ot_broker’ at host ‘HOSTNAME’ timed out after 60000 milliseconds</EWM.EXAMPLEW.MONO
><B.BODY>The M4_brokerport variable is not set correctly</B.BODY
><B.BODY>Set the ObjectTeam environment variable M4_brokerport to a number via which the broker can be reached. This variable is defined in %M4_home%/etc/m4env.m4env or in the .Meta4UserEnv file in your login directory. </B.BODY
><B.BODY>Default value: 1825</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Starting the User Environment Tool</L.LABEL
><EWM.EXAMPLEW.MONO>210048 TclError ‘ERROR [120048]: Operation ‘Nameserver::serverDefinition(int temporaryAlso)’ not invoked</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [120071]: Remote implementation 2.1 not found</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [120014]: Request for ‘ot_broker’ at host ‘HOSTNAME’ timed out after 60000 milliseconds</EWM.EXAMPLEW.MONO
><B.BODY>The M4_brokerport variable is not set correctly</B.BODY
><B.BODY>Set the ObjectTeam environment variable M4_brokerport to a number via which the broker can be reached. This variable is defined in %M4_home%/etc/m4env.m4env or in the .Meta4UserEnv file in your login directory. </B.BODY
><B.BODY>Default value: 1825</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Starting the Lock Management Tool</L.LABEL
><EWM.EXAMPLEW.MONO>ERROR [120048]: Operation ‘LockManager::sfindLocks(LockDescription const & desc)’ not invoked</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [120071]: Remote implementation 100.1 not found</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [120014]: Request for ‘ot_broker’ at host ‘HOSTNAME’ timed out after 60000 milliseconds</EWM.EXAMPLEW.MONO
><B.BODY>The M4_brokerport variable is not set correctly</B.BODY
><B.BODY>Set the ObjectTeam environment variable M4_brokerport to a number via which the broker can be reached. This variable is defined in %M4_home%/etc/m4env.m4env or in the .Meta4UserEnv file in your login directory. </B.BODY
><EWM.EXAMPLEW.MONO>121013 Server ‘dbserver’ reports failure</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>112152 Error occurred while opening a repository</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>110005 Connect to database ‘levelpath’ using connect string ‘UID=”DBA”;PWD=”janw”;ENG=hostname;START=DBCLIENT &truehy;x</EWM.EXAMPLEW.MONO
><B.BODY>You are trying to create a repository with a name that already exists. Start the Client/Server Configuration tool to see which repositories already exist.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Creating a repository</L.LABEL
><E.EXAMPLE></E.EXAMPLE
><EWM.EXAMPLEW.MONO>Dbserver V7.1.1 Fri Oct 18 20:58:36 1997</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>Oct 28 17:37:06 1996@<localhost>@185@4@dbserver.exe|object is ready: contact at udp port 1054</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>Info from ‘ot_broker’: Starting new server, please wait...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>Info from ‘ot_broker’: Server ‘lockserver’ is ready.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>The name specified is not recognized as an internal or external command, operable program or batch file.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>Repository not created.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [112105]: Creation of repository database ‘newrep’ failed.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>ERROR [110013]: Creation of database ‘C:\CayenneObjectteam\repos\newrep.db’ failed.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>Oct 28 17:37:07 1997@<localhost>@185@4@dbserver.exe|udp connection: closing port 1054</EWM.EXAMPLEW.MONO
><RBW-PARABODY>When trying to create a repository, you receive the following message:</RBW-PARABODY
></P.PROCEDURE
><E.EXAMPLE>Dbserver V7.1.1 Fri Oct 18 20:58:36 1997</E.EXAMPLE
><E.EXAMPLE></E.EXAMPLE
><E.EXAMPLE>Oct 28 17:53:14 1997@<localhost>@222@4@dbserver.exe|object is ready: contact at udp port 1069</E.EXAMPLE
><E.EXAMPLE>Repository not created.</E.EXAMPLE
><E.EXAMPLE>ERROR [112105]: Creation of repository database ‘newrep’ failed.</E.EXAMPLE
><E.EXAMPLE>ERROR [110012]: Create database can only be executed on server</E.EXAMPLE
><E.EXAMPLE>Oct 28 17:53:15 1997@<localhost>@222@4@dbserver.exe|udp connection: closing port 1069</E.EXAMPLE
><E.EXAMPLE>Dbserver V7.1.1 finished</E.EXAMPLE
><B.BODY>Creation fails because the new repository was created with the wrong database server specified. Open the Create Repository dialog box again and check the server name.</B.BODY
><B.BODY>It can also mean that the server name given is the Computer Name, rather than the DNS Host Name, which is used by ObjectTeam as host name.</B.BODY
><B.BODY>To check this, start up the Network configure utility from the Control Panel. In this window you will see the Computer Name. The DNS Host Name can been shown by selecting the “TCP/IP Protocol” in the window with “Installed Network Software” and clicking on “Configure...”.</B.BODY
><B.BODY>The TCP/IP configuration window will appear. In this window click on “DNS...”. The window that now will appear will give you the DNS Host Name. It is recommended to make the Computer Name and DNS Host Name the same.</B.BODY
><B.BODY>After this has been changed, reboot your system.</B.BODY
><B.BODY>This manual provides an introduction to ObjectTeam, an object&truehy;oriented software development environment that supports models&truehy;to&truehy;code application development.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisites</L.LABEL
><B.BODY>This manual assumes that you are familiar with the following products and concepts:</B.BODY
><RBW-PARABODY>The Unified Modeling Language (UML) for Object&truehy;Oriented Development, as developed by Grady Booch, Ivar Jacobson, and James Rumbaugh.</RBW-PARABODY
><B.BODY>ObjectTeam provides a complete environment for developing object&truehy;oriented applications. It automates the UML and OMT methodologies and provides utilities for checking your diagrams, reporting on diagram contents, creating formal project documentation, managing development projects, and generating code. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Cayenne repository</L.LABEL
><B.BODY>ObjectTeam supports team&truehy;oriented development by providing a common repository for all project data. The repository is implemented using a relational database. The relational database management system (RDBMS) that you use depends on your ObjectTeam package.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><B.BODY>ObjectTeam defines a set of diagram editors for modeling an application. It also provides a project hierarchy that includes the four software development phases: Analysis, System Design, Object Design, and Implementation. You use the editors and the project hierarchy to build your diagrams and move them through the software development phases.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Development utilities</L.LABEL
><B.BODY>ObjectTeam provides development utilities, such as Check, Reports, and Compare, that are useful in all phases of software development.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Code generation</L.LABEL
><B.BODY>After fully defining your UML or OMT diagrams, you can use the ObjectTeam code generators to generate code for both persistent and non&truehy;persistent objects.</B.BODY
><RBW-PARABODY>The data of a <CX5FX5FBULLET.EMPHASIS>persistent</CX5FX5FBULLET.EMPHASIS
> object persists beyond the lifetime of a single program execution. It is stored in a permanent data store, such as an RDBMS. To support persistent objects, the code generators generate SQL scripts that create the database and its tables, as well as the SQL code for accessing the data in the database. </RBW-PARABODY
><RBW-PARABODY>The data of a <CX5FX5FBULLET.EMPHASIS>non&truehy;persistent</CX5FX5FBULLET.EMPHASIS
> object exists only during the execution of its related program. To support non&truehy;persistent objects, the code generators generate OOPL code (for example, C++ or 4GL).</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Document generation</L.LABEL
><B.BODY>At the end of each phase, project teams often need to produce formal project documentation for presentation to management. You can use a desktop publishing system to refine the files generated by the Document Generator.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Project management utilities</L.LABEL
><B.BODY>Project management utilities, such as Configuration Management, Version Control, and Access Control, allow you to coordinate software development projects throughout your organization.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customize as needed</L.LABEL
><B.BODY>Special files allow you to customize most ObjectTeam components.</B.BODY
><B.BODY>You communicate with the repository through the ObjectTeam user interface. For example, the ObjectTeam Browser, which appears when you start ObjectTeam, displays the repository data. You create, modify, and delete repository data using the utilities provided by the ObjectTeam Browser and other ObjectTeam windows.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Project hierarchy</L.LABEL
><B.BODY>In the ObjectTeam Browser, project data is organized hierarchically:</B.BODY
> level contains object versions from a particular project that are in a particular phase of software development: Analysis, System Design, Object Design, or Implementation.</RBW-PARABODY
> level contains object versions that are in a particular subsystem of the application.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Project data</L.LABEL
><B.BODY>You create project data at the System level. In the repository, ObjectTeam stores project data as file versions, components, and items.</B.BODY
><RBW-PARABODY>When you create a diagram, ObjectTeam stores the diagram in the repository as a <CX5FX5FBULLET.EMPHASIS>file version</CX5FX5FBULLET.EMPHASIS
>File versions are repository objects; they do not appear in the directory structure of the operating system. In the ObjectTeam documentation, files that appear in the directory structure of the operating system are called <CX5FX5FTERM>external files</CX5FX5FTERM
><RBW-PARABODY>When you name the object in the diagram, you create a syntactic element that has meaning within your project. ObjectTeam stores the <CX5FX5FEMPHASIS>syntactic element</CX5FX5FEMPHASIS
> in the repository as an <CX5FX5FBULLET.EMPHASIS>item</CX5FX5FBULLET.EMPHASIS
><B.BODY>ObjectTeam provides a powerful environment for modeling, project management, and code generation. This chapter introduces you to the main features of ObjectTeam.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><B.BODY>ObjectTeam provides a set of diagrams that you can use to describe various aspects of your application. The ability to examine your application from different points of view promotes thorough analysis. </B.BODY
><B.BODY>This section describes the default diagrams supported by ObjectTeam. The diagram notation is based on the Unified Modeling Language (UML) for Object&truehy;Oriented Development, developed by Grady Booch, Ivar Jacobson, and James Rumbaugh.</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="30643" TYPE="XREF-TEXTCOPY">Use Case Diagrams&rbwtab;2–4</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="30620"></RBW-ANCHOR
>Class Diagrams</L.LABEL
><B.BODY>You use Class Diagrams, such as the one shown below, to describe classes and their relationships, attributes, and operations. These diagrams serve as the source for code generation.</B.BODY
><B.BODY>You use Sequence Diagrams, such as the one shown below, to model a dialog between an end user and objects in the application. Each Sequence Diagram describes a single real&truehy;world scenario. A complete set of Sequence Diagrams would fully describe the application; however, typically you use Sequence Diagrams to describe only the more complex aspects of the application.</B.BODY
><BI.BODY.INTRO>You use State Transition Diagrams, such as the one shown below, to describe the life cycle of a class (or an instance of that class). This diagram displays the messages received by a class and the state changes resulting from those messages. Typically, you use State Transition Diagrams to describe only classes that have complex life cycles.</BI.BODY.INTRO
><B.BODY>You use Use Case Diagrams, such as the one shown below, to model how an external user of the system (such as an end user or another system) interacts with the system. Each Use Case Diagram contains one or more Use Case objects, which can be further refined in additional Use Case Diagrams. A complete set of Use Case Diagrams describes all the different ways in which the system can be used.</B.BODY
>, provides instructions for creating a Sequence Diagram and a Class Diagram. For more information about each diagram, see the <CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
><B.BODY>This section describes each phase.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>One set of diagrams</L.LABEL
><B.BODY>ObjectTeam supports models&truehy;to&truehy;code application development. In ObjectTeam, you model your application using the diagrams described in <RBW-XREF REFID="28250" TYPE="XREF-TEXTCOPY">Diagrams</RBW-XREF
>. You build the application by moving the diagrams through the four development phases in an iterative cycle, adding more detail at each phase.</B.BODY
><B.BODY>Using the same set of diagrams in each development phase has two benefits:</B.BODY
><RBW-PARABODY>You do not have to transform the diagrams at the end of each phase; instead, you simply copy them to the next phase. (Copying the diagrams allows you to refine and enhance them for the current phase without losing valuable information from the previous phase.)</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Analysis</L.LABEL
><B.BODY>The goal of the Analysis phase is to define the application requirements. During this phase, your objective is to ensure that end users and developers have a clear understanding of the application’s functions.</B.BODY
><B.BODY>The following diagrams are the most important during the Analysis phase:</B.BODY
><RBW-PARABODY>Use Case Diagrams, Sequence Diagrams, and Collaboration Diagrams describe real&truehy;world scenarios that the application must address.</RBW-PARABODY
><RBW-PARABODY>Class Diagrams describe the classes required to implement an application that addresses the scenarios described by the Sequence Diagrams.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>System Design</L.LABEL
><B.BODY>The goal of the System Design phase is to define the application architecture, dividing the application into systems to facilitate development. The ideal application architecture maximizes the interaction among classes in each system (<CX5FX5FTERM>cohesion</CX5FX5FTERM
>) and minimizes the interaction among systems (<CX5FX5FTERM>coupling</CX5FX5FTERM
><RBW-PARABODY>The Class Diagrams from the Analysis phase describe the communication among classes, which can help you define system boundaries.</RBW-PARABODY
><RBW-PARABODY>For each system, a new Class Diagram describes the classes in that system.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Object Design</L.LABEL
><B.BODY>The goal of the Object Design phase is to refine and enhance the Class Diagrams for each system until it is detailed enough for implementation. Most of the activities in this phase depend on your implementation environment (for example, the programming language and database that you plan to use).</B.BODY
><B.BODY>If you are using ObjectTeam to generate code, you use this phase to specify the detailed information needed by the code generator. You might also make the contents of existing class libraries available to the code generator by reverse engineer the existing class libraries.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Implementation</L.LABEL
><B.BODY>The goal of the Implementation phase is to generate and refine the application code.</B.BODY
><B.BODY>The Class Diagrams are the source for code generation. Using this information, <DEFAULT-CLFTYPE></DEFAULT-CLFTYPE
>ObjectTeam generates code to implement classes and their relationships, attributes, and operations.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing the phases</L.LABEL
><B.BODY>By default, ObjectTeam uses the four phases described in this section. However, you can add or delete phases to meet the needs of your project or development organization.</B.BODY
>, provides instructions for moving diagrams from one phase to the next. For more information about phases, see the <CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
><RBW-PARABODY>You use the <CX5FX5FBULLET.EMPHASIS>Class Browser</CX5FX5FBULLET.EMPHASIS
> to find and examine classes.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>This section describes the Browser; the next section describes the Class Browser. The diagrams are described in <RBW-XREF REFID="28250" TYPE="XREF-TEXTCOPY">Diagrams</RBW-XREF
>, and <RBW-XREF REFID="21870" TYPE="XREF-TEXTCOPY">Chapter 3, Tutorial: Basic Operations</RBW-XREF
>, provides instructions for working with diagram editors.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose of the Browser</L.LABEL
><B.BODY>The Browser is the main user interface for ObjectTeam. You use the Browser to do the following:</B.BODY
><B.BODY>The Context area identifies the project, configuration, phase, and system of the active object and view; it is a read&truehy;only area.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Navigation area</L.LABEL
><B.BODY>The Navigation area displays the hierarchy of corporate data. In the Navigation area, you can do the following:</B.BODY
><RBW-PARABODY>Click on the navigation buttons to fold and unfold the hierarchy. (The buttons appear as plus signs in Windows, as shown in the previous illustration, and triangles in UNIX.)</RBW-PARABODY
><B.BODY>Classes are the primary objects in your model. The Class Browser allows you to quickly access classes and their relationships, attributes, and operations.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class Browser window</L.LABEL
><B.BODY>The Class Browser window consists of six areas:</B.BODY
> list box displays all classes in the current phase or system.</RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>Double&truehy;click on a class in the Classes list box to populate the other areas of the Class Browser with information about that class. </LT.LIST.TEXT
> list box displays the relationships of the selected class. (Generalizations are not displayed in the Associations list box. Instead, you view inheritance by selecting View | Flat.) You can use this view to navigate between classes.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Search utility</L.LABEL
><B.BODY>The Class Browser provides a search utility that allows you to search for a class, attribute, or operation. For example, you can use the search utility to find each class that includes an UpdateCustomer operation. Wildcard searches are supported.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Filters</L.LABEL
><B.BODY>The Class Browser provides filters that allow you to restrict the information displayed in the Features list box. For example, you can set the filter to display only operations in the Features list box.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Accessing the Class Diagram</L.LABEL
><B.BODY>From the Class Browser, select Utilities | Edit CD to open any Class Diagram in which the selected class appears.</B.BODY
><RBW-PARABODY>Syntax checking for code generation</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Automatic checking for diagram editing</L.LABEL
><B.BODY>Each ObjectTeam diagram has its own set of semantics. The diagram editors provide automatic syntax checking to ensure that the diagrams are syntactically correct for the methodology you are using (e.g., UML). If you attempt to create an invalid object or connection, ObjectTeam displays an error message and terminates the operation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Check options</L.LABEL
><B.BODY>After you have completed your diagrams, you can invoke the Check options to ensure that each diagram is complete and correct, and that each diagram accurately reflects the information presented in the other diagrams. ObjectTeam provides the following Check options:</B.BODY
> checks the semantic definition of a particular diagram. Each diagram has its own Check Contents option. For example, the Check Contents option for the Class Diagram includes a rule to check that attributes and roles on the same class all have unique names.</RBW-PARABODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Check Local Model</CX5FX5FBULLET.EMPHASIS
> examines one or more selected classes in a system. It ensures that the class as defined in the Class Diagram accurately reflects information about that class as defined in the other diagrams. For example, the Check Local Model option ensures that if a class receives a message in the Sequence Diagram it has an operation defined in the Class Association Diagram to handle that message.</RBW-PARABODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Check Use Case Model</CX5FX5FBULLET.EMPHASIS
> checks all Use Case Diagrams.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Syntax checking for code generation</L.LABEL
><B.BODY>When you generate code, ObjectTeam automatically invokes the Check Global Model option to check all classes in the system. This helps to prevent errors that might interrupt code generation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing checking</L.LABEL
><B.BODY>Like many features of ObjectTeam, you can customize checking by implementing your own rules or by modifying the ObjectTeam rules.</B.BODY
>Version and Configuration Management</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>ObjectTeam provides version and configuration management facilities. These tools are essential for incremental and team&truehy;oriented development.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Object versions</L.LABEL
><B.BODY>ObjectTeam allows you to create multiple versions of an object. Each version is in one of three states: working, frozen, or background.</B.BODY
> version is the only version of an object that you can modify. To prevent conflicting changes to an object, ObjectTeam ensures that there is only one working version of each object.</RBW-PARABODY
> versions of an object are stored in the repository, but cannot be modified. When you create a new version of an object, the previous version is automatically frozen. </RBW-PARABODY
> versions of an object, which are always frozen, are removed from the repository. They can be returned to the repository as needed.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Configurations</L.LABEL
><B.BODY>Configurations allow several developers to work on the same application without interfering with one another. Each configuration identifies the object versions that a particular developer is using. To prevent conflicting changes to an object, ObjectTeam ensures that the working version of an object appears in one configuration only.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The following example illustrates how versions and configurations are used in the development environment.</B.BODY
><B.BODY>Jill and Jon are developers working on the same application. Jill creates version 1.0 of the Core system. When the system is stable, she freezes it and creates version 2.0.</B.BODY
><B.BODY>Jon adds links in his configuration to version 1.0 of the Core system so that he can develop other systems that interact with it. Because Jon is using frozen version 1.0 of the Core system, Jill can continue her work on version 2.0 of the Core system.</B.BODY
>, provides instructions for creating versions and configurations. For more information, see the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><B.BODY>Reports provide current information about your project. They are intended for internal use by team members throughout the development cycle.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Document generation</SL.SUBLABEL
><B.BODY>The Document Generator helps you produce documentation for formal presentations. For more information, see <RBW-XREF REFID="12703" TYPE="XREF-TEXTCOPY">Document Generation</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Standard reports</L.LABEL
><B.BODY>ObjectTeam provides a variety of reports, including reports on projects, phases, systems, documents, and classes. For a complete list of reports, see the <CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>User&truehy;defined reports</L.LABEL
><B.BODY>ObjectTeam allows you to define your own reports and add them to the product. For more information, see the <CX5FX5FTITLE><CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generating a report</L.LABEL
><B.BODY>You can generate a report from the Browser, a diagram editor, or the operating&truehy;system command line. ObjectTeam displays the report in a window similar to the one shown below. From this window, you can save the report to a file or print it.</B.BODY
><B.BODY>ObjectTeam consists of a base product and a number of optional features. Each optional feature is implemented in a directory of files called a <CX5FX5FTERM>module</CX5FX5FTERM
>. To use a feature, you must <CX5FX5FTERM>activate</CX5FX5FTERM
> the module for tha feature. You must have a license for each active module.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Activating modules</L.LABEL
><B.BODY>Modules are usually activated on Corporate level for an entire corporate repository. You must have root access to do this. Modules activated on Corporate level are available by default for all users of this repository on every level.</B.BODY
><B.BODY>You do not have to activate all modules on Corporate level. You can activate them on any other level in the repository, as long as they are licensed.</B.BODY
><B.BODY>For details on how to activate modules, refer to the <CX5FX5FTITLE>ObjectTeam Installation Guide</CX5FX5FTITLE
><B.BODY>ObjectTeam provides a variety of document generation facilities. The built&truehy;in Document Generator helps you produce high&truehy;quality documentation for formal presentations. Alternatively, the optional integrated packages DocExpress and DocIt allow you to produce documentation complying with various commercial, government and military standards.</B.BODY
><B.BODY>This section summarizes the features of ObjectTeam’s built&truehy;in Document Generator. For details on DocExpress and DocIt, refer to their respective documentation.</B.BODY
><B.BODY>Document generation is a ObjectTeam module.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Document contents</L.LABEL
><B.BODY>Each document consists of the following elements:</B.BODY
>If you wish to use another desktop publishing systems, you must customize the Document Generator.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Defining the document structure</L.LABEL
><B.BODY>You define the structure of a document by specifying a <CX5FX5FTERM>Document Structure File</CX5FX5FTERM
> — a specially formatted text file that provides input to the Document Generator. ObjectTeam provides two Document Structure Files for each desktop publishing system: one file for the Analysis, System Design, and Object Design phases, and one file for the Implementation phase. You can use one of ObjectTeam’s Document Structure Files, or create your own.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generating the document</L.LABEL
><B.BODY>You select the Document Structure File to generate the complete document. Alternatively, you can select one or more file, property, or local sections to generate only those sections. In either case, ObjectTeam generates documentation files for your desktop publishing system. You can then modify or reformat the document from the publishing system.</B.BODY
><B.BODY>In ObjectTeam, you manage security by defining users, roles, and access rules.</B.BODY
><B.BODY>Access control is an ObjectTeam module.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Users</L.LABEL
><B.BODY><CX5FX5FTERM>Users</CX5FX5FTERM
> are the user names defined in the repository; for example, schmidt or oleary. Generally, each person who uses ObjectTeam is defined as a user.</B.BODY
><B.BODY>Users are defined at the Corporate level of the repository.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Roles</L.LABEL
><B.BODY><CX5FX5FTERM>Roles</CX5FX5FTERM
> are the job functions defined in the repository. Generally, one role is defined for each user — this role has the same name as the user name. Additional roles then define common job functions, such as analyst or programmer.</B.BODY
><B.BODY>Roles are defined at the Corporate level of the repository.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Access rules</L.LABEL
><B.BODY><CX5FX5FTERM>Access rules</CX5FX5FTERM
> are defined for each role. For each action on an object (for example, the action destroyAction on a System object), access rules define one of three permissions:</B.BODY
> grants or denies permission based on the permissions for other roles. If another role has Allowed permission, Undefined is the same as Prohibited. If no other role has Allowed permission, Undefined is the same as Allowed.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role links</L.LABEL
><B.BODY>A <CX5FX5FTERM>role link</CX5FX5FTERM
> between a user and a role indicates that the user has access to that role. The user can activate or deactivate the role during a session. The user’s default role, usually the role that has the same name as the user name, cannot be deactivated.</B.BODY
><B.BODY>Role links can be defined at the Corporate or Project level.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Granting and denying access</L.LABEL
><BI.BODY.INTRO>When a user attempts to manipulate an object, ObjectTeam allows the action unless one of the following is true:</BI.BODY.INTRO
><RBW-PARABODY>The user has access to one or more roles that explicitly prohibit the action and has activated at least one of those roles.</RBW-PARABODY
><RBW-PARABODY>There is a role that explicitly allows the action, but the user does not have access to that role.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>If a user has activated two roles, one that explicitly allows the action and one that explicitly prohibits the action, ObjectTeam prohibits the action.</B.BODY
>, provides instructions for modifying access to particular objects. For more information, see the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><B.BODY>Using ObjectTeam, you create a model that describes an application and then generate code from that model. The model does not fully define your application; you must edit the generated code to complete the application. However, to ensure that the model remains viable throughout the development cycle, the code generator preserves your edits when you later regenerate the code.</B.BODY
><B.BODY>Each code generator is a ObjectTeam module.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Phases and code generation</L.LABEL
><B.BODY>In the first two software development phases, Analysis and System Design, you define the requirements and architecture of your application. During these phases, you do not consider the implementation environment. </B.BODY
><B.BODY>You address the implementation environment in the final two phases, Object Design and Implementation.</B.BODY
> implements classes that exist beyond a single program execution. Such classes are typically defined in an RDBMS. For example, persistent code might be generated as SQL and ESQLC++ files.</RBW-PARABODY
> implements classes that exist for a single program execution only. For example, nonpersistent code might be generated as H++ and C++ files.</RBW-PARABODY
> are the files that build the application.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing code generation</L.LABEL
><B.BODY>You can also customize the code generators. For example, you might define new class attributes and then modify your code generator to generate code based on the values of those attributes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</L.LABEL
><B.BODY>Each code generator is specific to a programming language. For more information, refer to the <CX5FX5FTITLE>ObjectTeam Code Generation Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for your programming language. It assumes familiarity with ObjectTeam and proficiency in programming.</B.BODY
>, introduced you to the main features of ObjectTeam. In this chapter, you will use some of these features.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Scenario</L.LABEL
><B.BODY>In this tutorial, you will be an analyst for a company that rents CDs and videos. You will create a project and start to define the classes in the business applications.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Takes about one hour</L.LABEL
><B.BODY>This tutorial should take you about one hour to complete, but there is no time limit. Feel free to take your time and explore. However, if you want to compare your results with those in this chapter, note the features that you want to investigate and return to them after completing the tutorial.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="17156" TYPE="XREF-TEXTCOPY">Creating the Project Hierarchy&rbwtab;3–2</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="20468" TYPE="XREF-TEXTCOPY">Creating a Class Diagram&rbwtab;3–14</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="18468" TYPE="XREF-TEXTCOPY">Creating a Sequence Diagram&rbwtab;3–25</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="37001" TYPE="XREF-TEXTCOPY">Using the Class Browser&rbwtab;3–27</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="12341" TYPE="XREF-TEXTCOPY">Checking the Diagrams&rbwtab;3–30</RBW-XREF
>If you cannot start ObjectTeam, refer to the <CX5FX5FTITLE>ObjectTeam Installation Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> or contact your system administrator.</N2.NOTE.2
><LR.LIST.RESULT>The Browser appears. By default, you are at the Corporate level — the highest level of the repository. The Information area displays a list of all of the projects in the repository.</LR.LIST.RESULT
><B.BODY>You create projects at the Corporate level. If you are not at the Corporate level, click on the Corporate object in the Navigation area of the Browser. </B.BODY
>The Corporate object has the same name as the Cayenne repository; it is always the first object in the Navigation area. In this tutorial, the Corporate object is <CX5FX5FFILE.NAME>repos960415</CX5FX5FFILE.NAME
><B.BODY>If you do not have permission to create a project in the repository, in the next procedure, use an existing project that you are allowed to modify. In step one, move to the Project level by clicking on the name of the existing project in the Navigation area of the Browser.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Create a configuration</L.LABEL
><BI.BODY.INTRO>You create configurations at the Project level. </BI.BODY.INTRO
><RBW-PARABODY>Move to the Project level by double&truehy;clicking on the name of your project in the Information area of the Browser.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam updates the Context area and displays the contents of your project in the Information area. In this case, the project is empty.</LR.LIST.RESULT
><LR.LIST.RESULT>ObjectTeam adds the configuration to your project and updates the Information area.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Configuration versions</L.LABEL
><B.BODY>ObjectTeam supports versions of configurations. When you create a configuration, you actually create a version (v1) of the configuration. Therefore, the ObjectTeam documentation generally refers to configurations as <CX5FX5FTERM>Configuration versions</CX5FX5FTERM
>. </B.BODY
><B.BODY>ObjectTeam also supports versions of phases and systems, which you will create next, and versions of diagrams, which you will create later in this chapter.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Create a phase</L.LABEL
><BI.BODY.INTRO>You create phases at the Configuration level.</BI.BODY.INTRO
><RBW-PARABODY>Move to the Configuration level by double&truehy;clicking on the name of your Configuration version in the Information area of the Browser.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam updates the Context area and displays the contents of your Configuration version in the Information area. In this case, the configuration is empty.</LR.LIST.RESULT
><RBW-PARABODY>Move to the Phase level by double&truehy;clicking on the Analysis phase in the Information area of the Browser.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam updates the Context area and displays the contents of your Analysis phase in the Information area. In this case, the phase is empty.</LR.LIST.RESULT
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="16794" TYPE="XREF-TEXTCOPY">Exploring the Repository Hierarchy&rbwtab;3–8</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="13196" TYPE="XREF-TEXTCOPY">Changing the Appearance of the Browser&rbwtab;3–10</RBW-XREF
>Exploring the Repository Hierarchy</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>In this section, you use the Browser to explore the repository hierarchy.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Fold and unfold the hierarchy</L.LABEL
><B.BODY>The Navigation area of the Browser displays the repository hierarchy. You use the fold and unfold symbols to hide and show portions of the hierarchy.</B.BODY
><RBW-PARABODY>Hide the contents of the Corporate hierarchy by clicking on the fold symbol to the left of the Corporate object. (In Windows, the fold symbol is a minus sign; in UNIX, it is a down&truehy;pointing triangle.)</RBW-PARABODY
><RBW-PARABODY>Display the contents of the Corporate hierarchy by clicking on the unfold symbol to the left of the Corporate object. (In Windows, the unfold symbol is a plus sign; in UNIX, it is a right&truehy;pointing triangle.)</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam displays the Corporate hierarchy, changing the unfold symbol to a fold symbol.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Open an object</L.LABEL
><B.BODY>When you open one of the objects that you have just created, ObjectTeam displays its contents in the Information area, changes the active level of the repository, and identifies the active level in the Context area of the Browser. </B.BODY
>The Corporate object never appears in the Information area.</N2.NOTE.2
><LR.LIST.RESULT>Corporate is now the active level of the repository. The Information area displays all of the projects in the Corporate hierarchy.</LR.LIST.RESULT
><RBW-PARABODY>Open your project, noticing the changes to the Context and Information areas.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The project is now the active level of the repository. The project name appears in the Context area and the Information area displays the configurations in the project. </LR.LIST.RESULT
><RBW-PARABODY>Clicking on the object in the Information area with the right mouse button and selecting Open from the pop&truehy;up context menu.</RBW-PARABODY
><RBW-PARABODY>To close the System version, select File | Close.</RBW-PARABODY
></P.PROCEDURE
><LRS.LIST.RESULT.SINGLE>The phase is now the active level of the repository. The Information area displays the System versions in this phase.</LRS.LIST.RESULT.SINGLE
> in the Browser determines the types of objects that appear in the Information area. Each level of the repository has a Default view. Many levels also have alternative views, such as Pseudo, Data, and Process.</B.BODY
> contain project management information; they are used with features such as access control and customization. In the repository hierarchy, their names are enclosed in angle brackets (<>).</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Change the size of the Navigation and Information areas</L.LABEL
><B.BODY>The Navigation and Information areas fill the Browser; however, you can change the size of the areas.</B.BODY
><RBW-PARABODY>If you are using Windows, move the pointer to the border separating the two areas. The pointer changes to a double&truehy;ended arrow.</RBW-PARABODY
><RBW-PARABODY>If you are using UNIX, move the pointer to the small box near the bottom of the border separating the two areas. The pointer changes to a plus sign (+).</RBW-PARABODY
><B.BODY>This section describes some of the user interface shortcuts you can use in ObjectTeam.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Toolbar</L.LABEL
><B.BODY>Each ObjectTeam window provides a toolbar for fast access to common menu choices. <RBW-IDXTERM TERM1="toolbar" TERM2="in Browser"></RBW-IDXTERM
>To see the menu choice associated with an active toolbar icon, move the cursor over the icon. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Context menus</L.LABEL
><B.BODY>The ObjectTeam Browser and diagram editors provide context menus for fast access to common menu choices. </B.BODY
><RBW-PARABODY>To display a context menu in a diagram editor, Right&truehy;click on any object in, or on the background of, the Drawing area. </RBW-PARABODY
>The right mouse button has an additional function in the diagram editors. If you right&truehy;click while drawing a connector, the last connector vertex you drew is removed. By repeatedly right&truehy;clicking, you can remove a series of vertices. For more information on editing diagrams, see the <CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Keyboard shortcuts</L.LABEL
><B.BODY>So far, you have used the mouse to select menu items. To select menu items using the keyboard, use the mnemonics or keyboard accelerators.</B.BODY
> Next to certain menu item, you will see a key combination that you can use to invoke the item. For example, to select File | Close, press Ctrl + C.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Tear&truehy;off menus</L.LABEL
><B.BODY>In UNIX, you can <CX5FX5FTERM>tear off</CX5FX5FTERM
> a menu and move it to a more convenient location.</B.BODY
><RBW-PARABODY>To remove the Edit menu window, select Close from its window menu.</RBW-PARABODY
></P.PROCEDURE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Alternative</SL.SUBLABEL
><B.BODY>Click on the title bar of the Edit menu window to make it active, then press Escape.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What to do next</L.LABEL
><B.BODY>You have had an opportunity to explore the project hierarchy, the Browser, and some of the user interface shortcuts. If you would like to spend more time working with these features, feel free to do so. In the next section, you will create a Class Diagram.</B.BODY
> as the name of your CD and select the Edit button.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam creates the CD and opens the CD editor.</LR.LIST.RESULT
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Open the CD</SL.SUBLABEL
><B.BODY>If you select OK instead of Edit, ObjectTeam creates the CD, but does not open the editor. To open the CD editor, double&truehy;click on the name of the CD in the Information area.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="26398"></RBW-ANCHOR
>Explore the Control Panel</L.LABEL
><B.BODY>The symbols in the Control Panel of each diagram are described in the online Help.</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="22213" TYPE="XREF-TEXTCOPY">Creating an Association&rbwtab;3–19</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="34026" TYPE="XREF-TEXTCOPY">Completing the Class Diagram&rbwtab;3–21</RBW-XREF
>If you make a mistake while entering text, you can use the Backspace key to delete the character before the cursor, or use the Delete key to delete the character after the cursor.</T2.TIP.2
><RBW-PARABODY>Repeat steps 2 through 5 to create the four classes shown in the CD in the beginning of this section (see <RBW-XREF REFID="16235" TYPE="XREF-TEXTCOPY">Creating Classes</RBW-XREF
><B.BODY>Each class has a CDM, which has the same name as the class. The CDM stores information about the contents of a class and links to each diagram in which the class appears. The CDM is created automatically when you enter the first attribute or operation for a class. You cannot open and edit a CDM; ObjectTeam updates the CDM for you when you edit a class in a CD editor or the Properties dialog box (as described later in this chapter).</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Move the classes</L.LABEL
><B.BODY>Move the classes so that they are arranged as shown in the beginning of this section (see <RBW-XREF REFID="16235" TYPE="XREF-TEXTCOPY">Creating Classes</RBW-XREF
>To select multiple objects, press and hold the Ctrl key while you select each one. (Alternatively, press and hold the left mouse button, then use the mouse to draw a box around the objects that you want to select.)</T2.TIP.2
><RBW-PARABODY>A line with no circle represents a <CX5FX5FBULLET.EMPHASIS>mandatory</CX5FX5FBULLET.EMPHASIS
> association.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>In the CD that you are creating, the association between Member and Product is a many&truehy;to&truehy;many association. It indicates that each member can rent multiple products, and each product can be rented by multiple members.</B.BODY
><RBW-PARABODY>From the multiplicity selectors at the bottom of the Control Panel, select a multiple association for the left end of the association and a multiple association for the right end. </RBW-PARABODY
>If you click on Member, then click on the background, ObjectTeam creates a vertex. You can create as many vertices as you want before clicking on Product to complete the association. (Vertices are described following this procedure.)</T2.TIP.2
><LT.LIST.TEXT>Optionally, you can add a role name and constraints to each end of the association. Click just below the end of the association to enter a role name. Click just above the end of the association to enter a constraint.</LT.LIST.TEXT
><RBW-PARABODY>Select the Select symbol to exit Insert mode.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Save the CD</L.LABEL
><B.BODY>Save the CD, which should look like the CD shown in the section <RBW-XREF REFID="20468" TYPE="XREF-TEXTCOPY">Creating a Class Diagram</RBW-XREF
><B.BODY>Diagrams provide a great deal of information about a model; however, they do not provide all of the details you need for successful code generation. ObjectTeam provides <CX5FX5FTERM>item properties</CX5FX5FTERM
> to store additional information about many of the diagram objects.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Definitions</L.LABEL
><B.BODY>A <CX5FX5FTERM>component</CX5FX5FTERM
> is a graphical element in a diagram. For example, when you create a class in the CD, you create a component.</B.BODY
><B.BODY>An <CX5FX5FTERM>item</CX5FX5FTERM
> is a semantic element in the repository. For example, when you enter the name for a class, you create an item. When you add attributes to the class, you create additional items.</B.BODY
><B.BODY>ObjectTeam defines a number of item properties for each type of item. You use the Edit Properties window to specify values for item properties.</B.BODY
><RBW-PARABODY>Select No from the Nullable drop&truehy;down list to indicate that the Name attribute must have a value.</RBW-PARABODY
></LN.LIST.NUM
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Miscellaneous tab might not appear</SL.SUBLABEL
><B.BODY>Some code generators, such as the CORBA IDL code generator, do not use the fields on the Miscellaneous tab. If one of these code generators is active, the Miscellaneous tab does not appear in the Edit Properties window. </B.BODY
><B.BODY>In this section, you create a Sequence Diagram (SD).</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>All diagram editors are similar</L.LABEL
><B.BODY>Each type of diagram has its own editor; however, once you have learned how to use one diagram editor, you should find it easy to use other editors.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Create a SD</L.LABEL
><B.BODY>You can create an SD from the Browser in the same way you created a CD earlier in this chapter. You can also create a SD by navigating to it from the CD.</B.BODY
>If nothing happens, save the CD and try again. If you have changed the current diagram, you must save it before navigating to a new diagram.</N2.NOTE.2
>Control Panel described in the online Help</L.LABEL
><B.BODY>The symbols in the Control Panel are described in the online Help. For instructions on how to access the online Help, see <RBW-XREF REFID="26398" TYPE="XREF-TEXTCOPY">Explore the Control Panel</RBW-XREF
> Select Member, then select File | Open.</LT.LIST.TEXT
><LR.LIST.RESULT>The Features list box displays the class attributes and the Associations list box displays the class associations. If you had defined operations for the class, they would be displayed in the Features list box.</LR.LIST.RESULT
><RBW-PARABODY>Double&truehy;click on Video in the Classes list box.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The Features list box displays the class attributes and the Super Classes list box displays the parent class. </LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Display inherited information</L.LABEL
><B.BODY>By default, the Class Browser displays only the attributes, operations, and associations of the selected class. However, subclasses inherit information from their parent classes.</B.BODY
><LRS.LIST.RESULT.SINGLE>The Features and Associations list boxes display all attributes, operations, and features inherited by and defined for the selected class.</LRS.LIST.RESULT.SINGLE
><RBW-PARABODY>To return to the default view, select View | Flat again.</RBW-PARABODY
></P.PROCEDURE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Find a class</L.LABEL
><B.BODY>If you have several classes, it can be time consuming to locate one of them. The Class Browser provides a search utility that enables you to quickly locate a particular class.</B.BODY
><B.BODY>When you create or edit a diagram, the diagram editor automatically ensures that the diagram is syntactically correct. Other rules, however, cannot be checked until all diagrams are complete. For example, you need to ensure that all classes referenced in the SDs are defined in the CDs. The Check utility checks these additional rules.</B.BODY
><B.BODY>The ObjectTeam Monitoring window displays output from many utilities, such as Check, Reports, code generators, and the Document Generator. You can use the File menu of the Monitoring window to save the output to a file or print it.</B.BODY
><B.BODY>By default, ObjectTeam reuses the Monitoring window; that is, if you run a second report, it replaces the first report. You can choose instead to append new information to existing information in the Monitoring window. For example, if you have several reports that you want to print, you can generate all of the reports to the Monitoring window, then print the complete set of reports.</B.BODY
><RBW-PARABODY>A check mark next to the <CX5FX5FBULLET.EMPHASIS>Reuse option</CX5FX5FBULLET.EMPHASIS
> indicates that ObjectTeam will reuse the Monitoring window rather than opening a second window. You want ObjectTeam to reuse the window.</RBW-PARABODY
><B.BODY>You can customize ObjectTeam in many different ways. In this section, you add a new menu containing a single menu option that runs one of the standard reports. </B.BODY
><RBW-PARABODY>In the Storage page, make sure that all check boxes in the Visible field are selected, as shown in the following illustration. This ensures that the menu item is visible on all levels.</RBW-PARABODY
><RBW-PARABODY>Select the Write Message to Message Area check box and, in the Message field, enter <CX5FX5FINPUT>Running one of the standard reports</CX5FX5FINPUT
>.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>The Command page should now look as follows:</LR.LIST.RESULT
><RBW-PARABODY>Select File | Exit to exit from the Menu Customization Editor.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Start a new Browser</L.LABEL
><BI.BODY.INTRO>You have now created a customization file that adds a new menu item to the Browser. However, ObjectTeam only reads the customization files when you start the Browser. Therefore, to use your new menu item, you must start a new Browser.</BI.BODY.INTRO
><RBW-PARABODY>To start up a new Browser, select Utilities | Clone.</RBW-PARABODY
></P.PROCEDURE
><LRS.LIST.RESULT.SINGLE>ObjectTeam starts a new Browser, reading your User Customization file and adding the new menu item to the menu bar.</LRS.LIST.RESULT.SINGLE
><LR.LIST.RESULT>A Monitor window appears, displaying the output from the report on Classes.</LR.LIST.RESULT
><B.BODY>You can run any of the standard reports in this way, assuming you are on the appropriate level for that particular report. To find out the name of the report file you want to run, refer to the chapter on Reporting in the <CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>More on customization</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>An important customization file</SL.SUBLABEL
><B.BODY>In your home directory is a customization file called the Meta4UserEnv file. This contains your personal ObjectTeam settings. If you change any settings while working in ObjectTeam, when you quit the Browser or other tool, the settings are saved in this file, The next time you start ObjectTeam this file is read and your settings restored.</B.BODY
><B.BODY>To view the contents of this file, in the Browser, click on the <user customization files> object in the navigation area, then double&truehy;click on the Meta4UserEnv file in the information area. </B.BODY
><B.BODY>For more details on customization files, refer to the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
>, you can experiment with the project management features, such as creating versions and specifying access rights. The chapter will take you about 30 minutes to complete.</B.BODY
><B.BODY>If you plan to proceed to <RBW-XREF REFID="31837" TYPE="XREF-TEXTCOPY">Chapter 4</RBW-XREF
>, leave the Browser open; if not, exit ObjectTeam by closing the Browser.</B.BODY
>, introduced you to the features that you use to build diagrams in a single phase of the development cycle. This chapter introduces you to the features that you use to manage your project through all phases of the development cycle.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What you will do</L.LABEL
><B.BODY>In this chapter, you will continue working on the project that you created in <RBW-XREF REFID="21870" TYPE="XREF-TEXTCOPY">Chapter 3</RBW-XREF
><RBW-PARABODY>Experiment with roles and access rights.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Takes about 30 minutes</L.LABEL
><B.BODY>This chapter should take you about 30 minutes to complete, but there is no time limit. Feel free to take your time and explore. However, if you want to compare your results with those in this chapter, note the features that you want to investigate and return to them after completing the tutorial.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="16367" TYPE="XREF-TEXTCOPY">Moving to the Next Phase&rbwtab;4–2</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="34629" TYPE="XREF-TEXTCOPY">Creating a New Version&rbwtab;4–6</RBW-XREF
><B.BODY>In your project hierarchy, Phase objects help you to keep track of your systems as they move through the development cycle. When a system is in the Analysis phase, you store it in the Analysis phase of your project hierarchy. When the system moves into the System Design phase, you copy it to the System Design phase of your project hierarchy.</B.BODY
>, you created an Analysis phase for your project and built a system within that phase. Now, assume that you have completed your analysis of that system and are ready to begin system design.</B.BODY
><B.BODY>You must perform the following steps:</B.BODY
><RBW-PARABODY>Move to the System Design Phase level. (In the Information area, double&truehy;click on the System Design phase that you just created.)</RBW-PARABODY
><RBW-PARABODY>Select Version | Merge</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The System from the previous phase is now merged with the current Phase. The merged system in the previous phase is frozen.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Begin system design work</L.LABEL
><B.BODY>Now that your system is in the System Design phase, you are ready to begin design work on the system. In this tutorial, you will add a rentProduct operation to the Member class and a returnRental operation to the Product class.</B.BODY
><RBW-PARABODY>Save and close the CD.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Compare the two phases</L.LABEL
><B.BODY>As you move a system through each phase of the development cycle, it is useful to know which changes were made during a particular phase. <DEFAULT-CLFTYPE></DEFAULT-CLFTYPE
> <DEFAULT-CLFTYPE></DEFAULT-CLFTYPE
>ObjectTeam provides a Compare utility that finds the changes for you.</B.BODY
> You can make a set of changes, ensure that everything works properly, freeze the system, then proceed to the next set of changes. If you have problems implementing your changes, you can return to the frozen version of the system and try again.</RBW-PARABODY
> Once you have a working system, you can freeze it and make it available to your project team. The team can use the frozen version of the system while you continue to work on a new version of that system.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Version and configuration rules</L.LABEL
><B.BODY>Before you perform the procedures in this section, you should understand the following rules for versions and configurations:</B.BODY
><RBW-PARABODY>As described in <RBW-XREF REFID="41706" TYPE="XREF-TEXTCOPY">Version and Configuration Management</RBW-XREF
>, each version of an object can be in one of three states: working, frozen, or background. Working versions can be modified; therefore, only one version of an object can be in the working state at a time.</RBW-PARABODY
><RBW-PARABODY>A project can contain many versions of a configuration. However, a configuration can contain only one version of a particular phase, system, or file.</RBW-PARABODY
>If you are at the System level, you can move to the System Design Phase level by selecting File | Close.</T2.TIP.2
><LR.LIST.RESULT>ObjectTeam updates the Information area of the Browser. You have one system at the System Design Phase level, version <CX5FX5FTERM>XYZ</CX5FX5FTERM
>In the Information area, column 1 is Name, column 2 is Version, and column 3 is Status. If the Information area does not display this information, select View | Details to change the display.</T2.TIP.2
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Add the older version to your configuration</L.LABEL
><B.BODY>You can choose which version of the system you want to use in your configuration.</B.BODY
>Select Version | Select | Selected to choose a different version of the system. Select Version | Select | New to choose a system that is not currently in your configuration. You will use the New option in the next section.</T2.TIP.2
><B.BODY>As mentioned in the previous section, versions are important for project teams. In this section, you examine how versions are used to share code during development.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Scenario</L.LABEL
><B.BODY>In the previous section, you created version <CX5FX5FTERM>XYZ</CX5FX5FTERM
>Config.1 and <CX5FX5FTERM>XYZ</CX5FX5FTERM
>Config.2 of <CX5FX5FTERM>XYZ</CX5FX5FTERM
>System. In this section, you are a new developer who wants to use <CX5FX5FTERM>XYZ</CX5FX5FTERM
>System; you will use the frozen version, <CX5FX5FTERM>XYZ</CX5FX5FTERM
>Config.1.</B.BODY
><B.BODY>You must perform the following steps:</B.BODY
><RBW-PARABODY>Add version <CX5FX5FTERM>XYZ</CX5FX5FTERM
>Config.1 of <CX5FX5FTERM>XYZ</CX5FX5FTERM
>System to the new configuration.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Create a configuration and phase</L.LABEL
><B.BODY>The system you want to use is in the System Design phase of the project. Therefore, you must create a Configuration version with a System Design phase.</B.BODY
><RBW-PARABODY>Move to the Project level. (In the Navigation area, click on the name of your project. You might need to scroll the Navigation area to locate your project.)</RBW-PARABODY
><LT.LIST.TEXT>Notice the difference between the version numbers of the two systems. The version number includes the name of the configuration in which the system is created. This helps you to identify the version that you want to use.</LT.LIST.TEXT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Cannot unfreeze <CX5FX5FTERM>XYZ</CX5FX5FTERM
>System </L.LABEL
><B.BODY>You cannot unfreeze version <CX5FX5FTERM>XYZ</CX5FX5FTERM
>Config.1 of <CX5FX5FTERM>XYZ</CX5FX5FTERM
>System because a newer version (<CX5FX5FTERM>XYZ</CX5FX5FTERM
>Config.2) of that system already exists. This prevents you from making changes to a system that another developer is working on.</B.BODY
><B.BODY>If you try to unfreeze <CX5FX5FTERM>XYZ</CX5FX5FTERM
><B.BODY>Roles and access rights control access to objects. In this section, you experiment with roles and access rights by performing the following tasks:</B.BODY
><RBW-PARABODY>Change your access rights to NewSystem.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>About roles and access rules</L.LABEL
><B.BODY>As described in <RBW-XREF REFID="29719" TYPE="XREF-TEXTCOPY">Access Control</RBW-XREF
>, ObjectTeam manages security through roles and access rules. The administrator of the Corporate level creates several roles and associates each role with a set of access rules that allows or prohibits specific actions on specific types of objects.</B.BODY
><B.BODY>As an ObjectTeam user, you have access to one or more roles. (Access to roles is assigned at the Corporate or Project level.) During a session, you can activate or deactivate the roles to which you have access. Your active roles determine your current level of access.</B.BODY
><RBW-PARABODY>To display your effective roles, select File | Effective Roles.</RBW-PARABODY
></P.PROCEDURE
><LRS.LIST.RESULT.SINGLE>The Effective Context window appears, displaying your user name and active roles. Typically, you have one active role whose name matches your user name.</LRS.LIST.RESULT.SINGLE
><LT.LIST.TEXT>Typically, for your role, the action controlAction is set to Allowed and all other actions are set to Undefined. (The action controlAction determines whether you can modify the object’s role rights.)</LT.LIST.TEXT
><RBW-PARABODY>Select OK to close the Show Role Rights window.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>About this scenario</L.LABEL
><B.BODY>The action destroyAction determines whether you can delete the object. If you change the role rights for NewSystem so that, for your role, the action destroyAction is set to Prohibited, you will not be able to delete NewSystem.</B.BODY
>This is not a typical scenario. It is provided only to show you how to work with role rights.</N.NOTE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Deactivate the SuperUser role</SL.SUBLABEL
><B.BODY>No action is prohibited for users who have the SuperUser role active. Therefore, if your effective roles include SuperUser, deactivate that role before you continue.</B.BODY
><B.BODY>Effective roles determine a user’s access rights; therefore, it is important to control the roles that a user can activate. In ObjectTeam, a user can activate a role only if there is a UserRoleLink between the user and the role.</B.BODY
><B.BODY>UserRoleLinks are defined at the Corporate or Project level. Typically, the Corporate administrator creates a basic set of UserRoleLinks at the Corporate level, and the project leader modifies this set by adding UserRoleLinks at the Project level.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Examine users and roles</L.LABEL
><B.BODY>The <users> and <roles> pseudo objects at the Corporate level define users and roles, respectively. Typically, only the Corporate administrator can create and modify <users> and <roles>.</B.BODY
><RBW-PARABODY>Double&truehy;click on your user name.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>Each role to which you have access is displayed in the Information area. This indicates that a UserRoleLink exists between your user name and the role.</LR.LIST.RESULT
><RBW-PARABODY>Double&truehy;click on your role.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>Each user who has access to that role is displayed in the Information area. This indicates that a UserRoleLink exists between the role and the user.</LR.LIST.RESULT
><RBW-PARABODY>Select a user, then select OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>An error message appears, indicating that you do not have permission to perform this action. Typically, only the Corporate administrator can add UserRoleLinks at the Corporate level.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>UserRoleLinks at the Project level</L.LABEL
><B.BODY>Each project includes a <roles> pseudo object that is similar to the Corporate&truehy;level <roles> pseudo object. The Project&truehy;level <roles> object defines the UserRoleLinks for that project. You can examine and add UserRoleLinks to the Project&truehy;level <roles> object in the same way you examine and add UserRoleLinks to the Corporate&truehy;level <roles> object.</B.BODY
><RBW-PARABODY>Double&truehy;click on your role.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>No users are displayed in the Information area. At the Corporate level, you are defined as a user of this role. At the Project level, no additional users have access to this role.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What to do next</L.LABEL
><B.BODY>This manual has introduced you to many ObjectTeam features. The remainder of the ObjectTeam documentation set describes these and other features in greater detail. Before you begin work in ObjectTeam, you might want to familiarize yourself with the contents of each ObjectTeam manual.</B.BODY
><B.BODY>This manual describes the ObjectTeam Browser, diagram editors, Check utility, Reports and Class Browser. It is useful for all ObjectTeam users because it describes the core features of the product.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisites</L.LABEL
><B.BODY>This manual assumes that you are familiar with the following products and concepts:</B.BODY
><RBW-PARABODY>The Unified Modeling Language (UML) for Object&truehy;Oriented Development, as developed by Grady Booch, Ivar Jacobson, and James Rumbaugh, or the Object Modeling Technique (OMT), as developed by James Rumbaugh <CX5FX5FTERM>et al</CX5FX5FTERM
><B.BODY>This chapter explains the basic concepts of the Cayenne Browser and ObjectTeam projects. It also describes the pseudo objects used for project management and suggests a workflow for ObjectTeam projects.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisite</L.LABEL
><B.BODY>You need to be familiar with the information in the <CX5FX5FTITLE>ObjectTeam Getting Started</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><B.BODY>The root node of the Browser hierarchy represents the Cayenne repository and has the same name as the repository. This node is created and deleted when the repository administrator creates and deletes the repository. It cannot be created, deleted, or renamed from within the Browser.</B.BODY
> refers to the items immediately below the root node. The following figure shows the corporate level in the Browser. In this figure, the name of the repository is <CX5FX5FOBJECT.NAME>corporate</CX5FX5FOBJECT.NAME
><B.BODY>Corporate level lists each ObjectTeam project in the repository. ObjectTeam projects are indicated by the following icon. In the figure shown above, the repository named <CX5FX5FOBJECT.NAME>corporate</CX5FX5FOBJECT.NAME
> contains two projects, ProjectOne and ProjectTwo.</B.BODY
><B.BODY>If the Cayenne repository also contains GroundWorks Enterprise models, they also appear beneath the root node. This guide describes ObjectTeam only. For information about GroundWorks models, see the GroundWorks documentation.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Pseudo objects</SL.SUBLABEL
><B.BODY>Following the list of projects and models are the corporate&truehy;level pseudo objects. Pseudo objects, whose names are enclosed in angle brackets (<>), contain information that is used with project management features such as access control and customization. For more information, see <RBW-XREF REFID="38536" TYPE="XREF-TEXTCOPY">Pseudo Objects</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>User customization files</L.LABEL
><B.BODY>User customization files are in the home directory of the current user, not in the repository. For that reason, the <user customization files> node is not under the root node of the Browser hierarchy.</B.BODY
> refers to the user customization files, which are listed immediately below the <user customization files> node. The following figure shows the user customization level in the Browser.</B.BODY
><B.BODY>The Cayenne Browser provides access to the Cayenne repository and user&truehy;level customization files. It also provides access to ObjectTeam projects and serves as the main interface to ObjectTeam.</B.BODY
><B.BODY>In the Browser, the corporate level lists each ObjectTeam project in the repository. The information is arranged hierarchically beneath each project node. A clear understanding of the project hierarchy is helpful when working in the Browser.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Project data and pseudo objects</L.LABEL
><B.BODY>Each level of the project hierarchy contains project data and pseudo objects. This section describes the project data.</B.BODY
><B.BODY>Pseudo objects, whose names are enclosed in angle brackets (<>), contain information that is used with project management features such as access control and customization. For more information, see <RBW-XREF REFID="38536" TYPE="XREF-TEXTCOPY">Pseudo Objects</RBW-XREF
><B.BODY>The project level lists each configuration version in the project. The project shown above has one configuration version, ConfigurationOne. Following the configuration versions are the project&truehy;level pseudo objects. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Configuration versions</SL.SUBLABEL
><B.BODY>Configuration versions are used for version management. A project can have one or more Configuration versions. Each configuration version can be used by one or more project team members. The <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> describes configuration and version management.</B.BODY
><B.BODY>The configuration level lists each phase version in the project. The configuration shown above has four phase versions: Analysis, System Design, Object Design, and Implementation. Following the phase versions are the configuration&truehy;level pseudo objects. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Phase versions</SL.SUBLABEL
><B.BODY>Phase versions are used to manage the project life cycle, as described in <RBW-XREF REFID="25029" TYPE="XREF-TEXTCOPY">Workflow</RBW-XREF
><B.BODY>The phase level lists each system and document version in the project. The Analysis phase version shown above has one document version and two system versions. Following the document and system versions are the phase&truehy;level pseudo objects.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>System versions</SL.SUBLABEL
><B.BODY>System versions contain the model information, such as the diagrams and the objects defined in the diagrams. This guide describes how to create and maintain diagrams and other model information.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Document versions</SL.SUBLABEL
><B.BODY>Each document version contains complete, formatted documentation for one system version. For more information about how to create this documentation, see the <CX5FX5FTITLE>ObjectTeam Document Generation Guide</CX5FX5FTITLE
><B.BODY>The system level lists the file versions in the system (the diagrams and class definition matrices (CDMs)). The system shown above contains two file versions. Following the file versions are the system&truehy;level pseudo objects. </B.BODY
> refers to the items immediately below a document version node. The document level in the Browser contains the file versions in the document. See the <CX5FX5FTITLE>ObjectTeam Document Generation Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for more information.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Who uses which level</L.LABEL
><B.BODY>Project team members generally work on the system and document levels, creating and maintaining the model information. They rarely need to work with the system&truehy; or document&truehy;level pseudo objects, but they can if necessary. Project team members may also create and maintain customization files on the user customization level.</B.BODY
><B.BODY>Project leaders create and maintain projects and are responsible for all project&truehy;level data. If a project contains only one configuration version, the project leader generally maintains the configuration&truehy; and phase&truehy;level data also. If a project contains multiple configuration versions, the project leader may delegate maintenance of each configuration version to a senior project team member, who then maintains the configuration&truehy; and phase&truehy;level data for it.</B.BODY
><B.BODY>Each level of the Browser hierarchy includes pseudo objects. The names of these objects are enclosed in angle brackets (<>). The following table lists the pseudo objects and what they are used for:</B.BODY
>The Security and Corporate Modeling features are available as licensed modules. You will only see the associated pseudo&truehy;objects if these features are licensed at your site and switched on.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Access control (Security)</L.LABEL
><B.BODY>The repository is a shared resource. To protect it, ObjectTeam provides a rich access control mechanism.</B.BODY
><B.BODY>At the corporate level, the repository administrator can use the access control mechanism to grant users access to appropriate areas of the repository, while restricting their access to other areas. At lower levels, project leaders and project team members can use the same access control mechanism to further restrict access to their own areas of the repository.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customization</L.LABEL
><B.BODY>Most of the ObjectTeam product can be customized.</B.BODY
><RBW-PARABODY>At the corporate level, customization files are stored in the Cayenne installation directory. The repository administrator can modify these files (with great care).</RBW-PARABODY
><RBW-PARABODY>At the project, configuration, phase, system, and document levels, the customization files are <CX5FX5FEMPHASIS>internal</CX5FX5FEMPHASIS
> files stored in the repository, not in the file system of the computer.</RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>These customization files override or supplement the corporate&truehy;level customization files (for example, if you are working at the system level, the customization files defined at the system level take precedence over those defined at all higher levels). They are created and modified by the project leader or a senior project team member.</LT.LIST.TEXT
><RBW-PARABODY>At the user customization level, the customization files are stored in the home directory of the current user. They are created and maintained by the user and override all other customization files.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
> is a set of file versions and items; for example, a group might contain part of a diagram and the items defined in that part of the diagram. You can use groups to allow reuse of model data. </B.BODY
><B.BODY>At the system level, you create a group. You then promote that saved group to corporate level where it can be reused by ObjectTeam users on other projects. This process is called <CX5FX5FTERM>corporate modeling</CX5FX5FTERM
>.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Listing items</L.LABEL
><B.BODY>At the system and document level you create diagrams, documents, and other model information. ObjectTeam stores this information as <CX5FX5FEMPHASIS>items</CX5FX5FEMPHASIS
> in the repository. The pseudo object <defined items> provides a complete list of all repository items defined in a system or document version.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See <RBW-XREF REFID="29698" TYPE="XREF-TEXTCOPY">Working With Items</RBW-XREF
><B.BODY>ObjectTeam supports models&truehy;to&truehy;code application development. In ObjectTeam, you progress from models to code by moving a project through the following phases of software development.</B.BODY
><B.BODY>ObjectTeam provides the above four phases by default. Depending on the needs of your project or organization, you may wish to insert additional phases, or delete them. If you want to do this, you must define the number of phases and their order before you start creating phases. See the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for more information.<RBW-IDXTERM TERM1="phase" TERM2="customizing"></RBW-IDXTERM
><B.BODY>In ObjectTeam, phases are not just conceptual, they are also objects in the repository. When you move from one phase to the next, you copy your system versions from one phase version to the next. For example, when you move from analysis to system design, you copy your system versions from the Analysis phase version to the System Design phase version.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Models are preserved</L.LABEL
><B.BODY>As you move from analysis toward implementation, the nature of your model changes. However, because you copy (rather than move) your system versions from one phase version to the next, the models created during each phase are preserved. </B.BODY
><B.BODY>Changes made to a system in one phase do not affect that system in any other phase. For example, after you move a system from the Analysis phase to the System Design phase, you can work on it without affecting the copy in the Analysis phase. You can still go back and change the system in the Analysis phase. If you do so, however, you should evaluate whether you need to update the System Design phase as a result.</B.BODY
><RBW-PARABODY>Create and populate diagrams in each system version, developing the system version to meet the objectives of the current phase.</RBW-PARABODY
><RBW-PARABODY>Move the system versions to the next phase: create the new phase version in your configuration version and import the system versions to the new phase version.</RBW-PARABODY
><B.BODY>In the Analysis phase, you model the business situation without considering technical aspects, such as what operating systems, databases, or programming languages to use. End users must be able to understand the analysis models because they must validate them.</B.BODY
><B.BODY>Analysis should not include implementation decisions. The analysis model states what must be done without placing restrictions on how it will be done. Worrying about implementation during this phase impedes your efforts to fully understand your customer requirements.</B.BODY
><B.BODY>In the System Design phase, you design the application architecture, identify subsystems, and allocate the subsystems to specific hardware. Your objective is to create a high&truehy;level structure of the system, figuring out the classes required to build the functionality and organizing them so that related groups are defined and stored in systems. </B.BODY
><B.BODY>During the System Design phase, you focus on the items you need to solve the problem. The decisions you make concern the graphical user interface (GUI), the database management system, and the hardware and software configuration.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Object Design and Implementation phases</L.LABEL
><B.BODY>The Object Design and Implementation phases address the issues specific to the target language, and are designed to be used with the ObjectTeam code generators. If you are not planning to generate code using ObjectTeam, you generally do not use these two phases.</B.BODY
><RBW-PARABODY>Choosing an ObjectTeam code generator. This choice determines which object properties and Browser menu items are available to you. </RBW-PARABODY
><B.BODY>When you copy a system from the Object Design phase, ObjectTeam translates your model data into source code files. In the Implementation phase, you edit the generated source code files to refine and complete the application.</B.BODY
> for your target language provides more information about the Object Design and Implementation phases, and complete instructions for generating code.</B.BODY
>you start ObjectTeam, the ObjectTeam Browser appears. From the Browser, you can access and manipulate all project data. </B.BODY
><B.BODY>This chapter describes basic features of the Browser. It does not repeat information available in <CX5FX5FTITLE>ObjectTeam Getting Started</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> or the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Browser objects</L.LABEL
><B.BODY>From the Browser, you typically work with the following objects:</B.BODY
>Creating, Deleting, and Viewing Objects</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This section describes how to create, open, view details of, and delete Browser objects. You work with different objects at each level of the Browser. </B.BODY
><RBW-PARABODY>Select the type of object that you want to create. For example, to create a new project, select File | New | Project.</RBW-PARABODY
></LN.LIST.NUM
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Naming conventions</SL.SUBLABEL
><B.BODY>Object names have a maximum length of 80 characters and can consist of any alphanumeric characters. Because object names are often used as file names, it is recommended when naming objects to choose names that conform to the operating system’s rules for file names.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Opens the object, changing levels in the Browser and updating the Context and Information areas</CELLBODY
>If you use Edit | Cut, the object remains visible in the Browser (but with its icon dimmed) until you place it in the new location using Edit | Paste.</N2.NOTE.2
>How to copy objects by dragging them<RBW-IDXTERM TERM1="drag-and-drop" TERM2="copying files"></RBW-IDXTERM
></L.LABEL
><B.BODY>You can drag objects from the navigation area to the information area or vice versa. You can also drag an object from one location in the navigation area to another. On Windows, use the left mouse button. On UNIX systems, use the middle mouse button.</B.BODY
><RBW-PARABODY>In either the navigation area or information area, display the object that you want to copy and the phase or system into which you want to copy it.</RBW-PARABODY
>If an object with the same name as the one you are copying exists in the target phase or system, you may receive a message that an item is already defined. For more information on items and their scope, see <RBW-XREF REFID="29698" TYPE="XREF-TEXTCOPY">Working With Items</RBW-XREF
>.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Restrictions on copying systems</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Restriction</SL.SUBLABEL
><B.BODY>Although the procedures in this section can be used to copy systems, it is recommended that you only use these for copying systems between projects. If you want to copy systems from one phase to the next within a single project, it is recommended that you use the import procedures described in <RBW-XREF REFID="20556" TYPE="XREF-TEXTCOPY">Merging Systems into Another Phase</RBW-XREF
> in the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Reason</SL.SUBLABEL
><B.BODY>If you copy a system using the procedures described in this section, a new system version will be made. If a system with this name already exists, it will be frozen and deselected. The import procedures, as described in <RBW-XREF REFID="20556" TYPE="XREF-TEXTCOPY">Merging Systems into Another Phase</RBW-XREF
> in the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>, offer you more control over what must be imported.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for more information about version and configuration management.</B.BODY
><B.BODY>You can rename projects, configurations, systems, documents, diagrams (and diagram components), and external files within the Browser. You cannot rename phases, groups, customization files, and so on. </B.BODY
><B.BODY>You can also rename a repository, using the Corporate Management tool. For details on how to rename repositories, see the <CX5FX5FTITLE>ObjectTeam System Administrator’s Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to rename an object<RBW-IDXTERM TERM1="renaming" TERM2="Browser objects"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Change Name (File menu)" TERM2="of Browser object"></RBW-IDXTERM
><RBW-PARABODY>Type the new name, and then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam renames the object or displays an error message if an object of that name already exists.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Renaming configurations</L.LABEL
><B.BODY>When you create a version, ObjectTeam assigns it a version identifier. The configuration name is used as part of that version identifier. Renaming a configuration does not change the version identifiers of existing objects.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for more information about version and configuration management.</B.BODY
> determine the information displayed in the information area of the Browser. As shown in the following table, every level in the corporate hierarchy has a default view, and many levels have additional views.</B.BODY
>A filter allows you to further control what appears in the information area. When you turn a filter on, it applies to the current level and view only. It remains in effect until you turn it off or you exit from the Browser.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>You open the Core system, select the Default view, and turn on a filter. The filter is in effect. You move to the configuration level, the filter is no longer in effect. You open the Interface system, the filter is again in effect.</B.BODY
><LR.LIST.RESULT>The Edit Filter window for the current level appears. The fields in the window correspond to the columns displayed in the information area in Detail view.</LR.LIST.RESULT
><RBW-PARABODY>Specify the information that you want to appear in the Information area. For example, in the In Corporate field in the previous figure, you can enter <CX5FX5FINPUT>Yes</CX5FX5FINPUT
>, <CX5FX5FINPUT>No</CX5FX5FINPUT
>, or a wildcard string that includes either one or both of these.</RBW-PARABODY
><LR.LIST.RESULT>ObjectTeam updates the Information area to display the requested information and the Context area to indicate that the filter is on.</LR.LIST.RESULT
><B.BODY>Use the Options menu to set personal preferences.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>Use Options |Copy User Environment to make your options available to other ObjectTeam users. See the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.<RBW-IDXTERM TERM1="Copy User Environment (Options menu)"></RBW-IDXTERM
></B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to set the Compare command<RBW-IDXTERM TERM1="comparing" TERM2="default compare command"></RBW-IDXTERM
><LT.LIST.TEXT>The Context list specifies different types of text files that you can edit. Select a default editor for each type of file.</LT.LIST.TEXT
>From the Browser, you can print a diagram or the current contents of the Information area. You can also specify the print commands that ObjectTeam should use.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Printing a diagram to a file</SL.SUBLABEL
><B.BODY>You can also print a diagram to a file in Interleaf, FrameMaker, Encapsulated Postscript, or Windows Metafile format. For more information, see the otexport command in the <CX5FX5FTITLE>ObjectTeam System Administrator’s Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to specify the print commands<RBW-IDXTERM TERM1="Printer Setup (Options menu)"></RBW-IDXTERM
></L.LABEL
><BI.BODY.INTRO>You specify a print command for diagrams (Options | Printer Setup | Graphical) and a print command for reports and other printed text (Options | Printer Setup | Text).</BI.BODY.INTRO
><LR.LIST.RESULT>The Printer Setup window appears. The illustration below show both the Windows dialog box (first) and the UNIX dialog box (second).</LR.LIST.RESULT
><RBW-PARABODY>Specify the desired settings, and then click OK.</RBW-PARABODY
></LN.LIST.NUM
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Sharing Printer Setup options</SL.SUBLABEL
><B.BODY>Use Options |Copy User Environment to make your Printer Setup options available to other ObjectTeam users. See the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for more information.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to print the current view<RBW-IDXTERM TERM1="Print View (File menu)"></RBW-IDXTERM
><LR.LIST.RESULT>ObjectTeam prints the diagram using the Print Options specified in the diagram editor, as described later in this section. At the bottom of the diagram is a print box containing the diagram’s full file name, the date it was last changed, and its status.</LR.LIST.RESULT
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Alternative</SL.SUBLABEL
><B.BODY>To print a diagram from a diagram editor, select File | Print.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to specify print options<RBW-IDXTERM TERM1="Print Options (Options menu)"></RBW-IDXTERM
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Whether to scale automatically, and if not, the scale and size of the printed diagram.</CELLBODY
><CELLBODY>There are two scale strategies: Auto Scale and Manual Scale. Auto Scale scales the diagram to fit on the specified number of pages. Manual Scale (enabled by switching Auto Scale off) requires a Scale Factor to be specified. A Factor Scale of 2.000000 means all sizes are multiplied by 2.</CELLBODY
>Summary of Mouse Button Operations</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>ObjectTeam supports a two&truehy;button mouse on Windows and a three&truehy;button mouse on UNIX systems. (If you are using a three&truehy;button mouse on Windows, the middle button is ignored.) </B.BODY
><B.BODY>The following table summarizes ObjectTeam’s mouse button operations. For more information about each operation, see the earlier sections of this chapter. </B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Control+click left button</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Browser, Class Browser, and editors</CELLBODY
></ENTRY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Select or deselect a single object</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Double&truehy;click left button</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Information area in Browser, display area in Class Browser, editing area in diagram editors</CELLBODY
><B.BODY>This chapter describes how to work with diagrams. It does not repeat all of the information provided in <CX5FX5FTITLE>ObjectTeam Getting Started</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</L.LABEL
><B.BODY>The following chapters provide additional diagram information:</B.BODY
><B.BODY>You create a diagram at the system level. Before you can create a diagram, you must already have created a project hierarchy: a project, configuration version, phase version, and system version.</B.BODY
>Object names, including diagram names, have a maximum length of 80 characters and can include any alphanumeric character. When naming objects, it is recommended to choose names that conform to the operating system’s rules for file names, since object names are often used as file names.</B.BODY
><RBW-PARABODY>To create a diagram of the same type as the diagram editor:<RBW-IDXTERM TERM1="Open By Name (File menu)" TERM2="create diagram"></RBW-IDXTERM
><RBW-PARABODY>From the Class Browser (Class Diagrams only), as described in <RBW-XREF REFID="42628" TYPE="XREF-TEXTCOPY">How to open from the Class Browser</RBW-XREF
><RBW-PARABODY>In the information area, select a diagram, and then select File | Open or File | Edit, or right&truehy;click and select Open from the shortcut menu. <RBW-IDXTERM TERM1="Open (File menu)" TERM2="diagram"></RBW-IDXTERM
><RBW-PARABODY>In the information area, select a diagram, and then select File | Show. ObjectTeam opens the diagram for read&truehy;only access.</RBW-PARABODY
><RBW-PARABODY>In the information area, select a CDM, and then select File | Open or File | Edit. ObjectTeam opens the Class Diagram (CD) that contains the class.</RBW-PARABODY
>Selecting the name of the current diagram reloads the diagram. Any changes made since you last saved the diagram are lost.</N2.NOTE.2
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Alternative</SL.SUBLABEL
><B.BODY>Drag the icon of the diagram from the information area of the Browser into the drawing area of the current diagram editor. This only works if the diagram you are dragging is the same type as the current diagram editor.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="28215"></RBW-ANCHOR
>How to open from the Windows desktop</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Windows</SL.SUBLABEL
><B.BODY>This feature is only available on Windows.</B.BODY
><B.BODY>You can create a desktop shortcut for a diagram. To create a shortcut, select a diagram in the information area of the Browser and select File | Create Shortcut.</B.BODY
><LRS.LIST.RESULT.SINGLE>A shortcut with the name of the diagram is placed on the Windows desktop</LRS.LIST.RESULT.SINGLE
><B.BODY>To open the diagram, double&truehy;click on the shortcut on the desktop.</B.BODY
><RBW-PARABODY>Select Utilities | Edit Class Diagram.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>If the open class appears in more than one CD, the system displays a list of all CDs in which the class appears. Select the CD that you want to open, then click OK. </LT.LIST.TEXT
><B.BODY>Components in one diagram can often be defined further in another diagram of the same or different type. For example, a class in a Class Diagram can be further defined in a State Transition Diagram. To help you build related diagrams, ObjectTeam allows you to <CX5FX5FTERM>navigate</CX5FX5FTERM
> between diagrams — that is, you create or open a new diagram from a component in the current diagram.</B.BODY
><RBW-PARABODY>Double&truehy;click a component in the current diagram or select a component in the current diagram, and then select File | Open.</RBW-PARABODY
><RBW-PARABODY>Click the item that you want to navigate from, and then click OK.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>The Select Operations window appears, as shown below. The options listed depend on what item you selected and what diagrams exist, as described in <RBW-XREF REFID="39004" TYPE="XREF-TEXTCOPY">Navigation options</RBW-XREF
><RBW-PARABODY>Select the desired option, and then click OK.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="39004"></RBW-ANCHOR
>Navigation options</L.LABEL
><B.BODY>The following table shows the navigation options that appear by default. You can customize these options, as described in the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
><B.BODY>Each navigation option creates and opens a new diagram or opens an existing diagram.</B.BODY
>The CD, COD, SD, STD, and UCD are described in Chapter 4, Exploring Each Diagram. The CCD, DFD, MGD and the navigation options to and from these diagrams are described in Appendix A, OMT Support.</N.NOTE
>: (not mentioned in the table but displayed in the Select Operation dialog box). See <RBW-XREF REFID="15252" TYPE="XREF-TEXTCOPY">Systems you can navigate to</RBW-XREF
> below.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="34996"></RBW-ANCHOR
>Diagram Name </L.LABEL
><B.BODY>The diagram names are generated from the component name from which the navigation was started. </B.BODY
><RBW-PARABODY>When you create a COD, or SD, the name of the component is assigned to the qualifier, and a dialog box appears in which you can assign the diagram name.</RBW-PARABODY
><RBW-PARABODY>When you create an STD, the name of the component is assigned to the qualifier. If the navigation process was started from a CD or SD, the STD diagram name is given the name top.</RBW-PARABODY
></LB2.LIST.BULLET.2
><B.BODY>The names of the new diagrams are generated from the component name. These names remain linked to the original component. If you change the name of the component in the original diagram, ObjectTeam changes the name of the generated diagram (or system).</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="15252"></RBW-ANCHOR
>Systems you can navigate to</L.LABEL
><B.BODY>The System column in the Select Operation dialog box displays the name of the system in which the create or open action will take place. </B.BODY
><B.BODY>If the item you are navigating from is already defined in that system, an asterisk is placed in front of the system name.</B.BODY
><B.BODY>When selecting an open or create operation, you can determine in which system the operation will be carried out by checking the value of the system field:</B.BODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>The item is defined in the current system. The operation will be carried out in this system.</CELLBODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>The item is defined in another system. The operation will be carried out in the other system.</CELLBODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>The item is defined in the current system but is referenced in another system. The operation will be carried out in the other system.</CELLBODY
><RBW-PARABODY>Click OK to delete the diagram. </RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Deleting diagram items</L.LABEL
><B.BODY>When you delete a diagram, you delete only the diagram file. Items referenced in the diagram must be deleted separately, as described in <RBW-XREF REFID="21274" TYPE="XREF-TEXTCOPY">Removing and Moving Items</RBW-XREF
><B.BODY>Use File | Read to merge one diagram into another diagram of the same type. Typically, you use this feature to copy diagram information into a new diagram.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What is merged</L.LABEL
><B.BODY>When you merge two diagrams, you merge their graphical components. The semantic items underlying the diagrams are not affected.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Diagrams overlie one another</L.LABEL
><B.BODY>When you select File | Read, ObjectTeam opens a second diagram in the diagram editor without first closing the current diagram. The second diagram overlies the first. </B.BODY
><B.BODY>If the first diagram is new, the merged diagram contains the contents of the second diagram. If the first diagram contains objects, the merged diagram contains the contents of both diagrams. Use the diagram layout features to make the merged diagram legible.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to merge diagrams<RBW-IDXTERM TERM1="diagram" TERM2="merging"></RBW-IDXTERM
><RBW-PARABODY>If necessary, use the diagram layout features, as described in <RBW-XREF REFID="17519" TYPE="XREF-TEXTCOPY">Modifying Diagram Layout</RBW-XREF
>, to make the merged diagram legible.</RBW-PARABODY
> are symbols that can stand by themselves, such as classes, subjects, states, and events.<RBW-IDXTERM TERM1="node" TERM2="definition of"></RBW-IDXTERM
> are angles in connector lines.<RBW-IDXTERM TERM1="vertex" TERM2="definition of"></RBW-IDXTERM
></RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Modes</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="select symbol, diagram control panel"></RBW-IDXTERM
>Many diagram editing operations begin by selecting a symbol from the diagram control panel. When you click a symbol button, you enter editing <CX5FX5FTERM>mode</CX5FX5FTERM
>. To exit from the mode, click the Select button.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section contains the following topics:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="16653" TYPE="XREF-TEXTCOPY">Working With the Diagram Window&rbwtab;3–15</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="20264" TYPE="XREF-TEXTCOPY">Creating and Deleting Components&rbwtab;3–16</RBW-XREF
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="27377" TYPE="XREF-TEXTCOPY">Adding Notes to a Diagram&rbwtab;3–30</RBW-XREF
><B.BODY>Occasionally, you may see unwanted elements in the editing area, such as stray pixels left by other drawing tools. To remove them, refresh the diagram.</B.BODY
><RBW-PARABODY>In Windows, you generally move the editing focus to a text field by clicking the field. ObjectTeam works this way when Options | Pointer Focus is not selected. This is the default behavior.</RBW-PARABODY
><RBW-PARABODY>On UNIX systems, you generally move the editing focus to a text field by moving the pointer to the field; clicking the field is not necessary, but the pointer must remain on the field. ObjectTeam works this way when the Options | Pointer Focus menu item is selected.</RBW-PARABODY
>In a diagram, the label of every component is a text field. To edit the diagrams easily, it is important to specify the behavior that you are most comfortable with.</N.NOTE
>If you click the first node, and then click in the background, ObjectTeam creates a vertex. You can create as many vertices as you want before clicking the second node to complete the connector. (If you create a vertex by mistake, right&truehy;click to remove it. This action is the same as selecting Edit | Undo.)</N2.NOTE.2
><RBW-PARABODY>To exit Insert mode, click the Select button.</RBW-PARABODY
></LN.LIST.NUM
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Complex connectors</SL.SUBLABEL
><B.BODY>Generalizations and n&truehy;ary associations connect more than two nodes. The description of these connectors in Chapter 4, Exploring Each Diagram, explains how to create them.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to create a vertex<RBW-IDXTERM TERM1="vertex" TERM2="creating"></RBW-IDXTERM
></L.LABEL
><B.BODY>Adding vertices to connector lines allows you to change the routing of the line and improve the appearance of the diagram.</B.BODY
><B.BODY>To carry out certain actions on nodes, connectors, or vertices, you must select them first.<RBW-IDXTERM TERM1="diagram component" TERM2="selecting"></RBW-IDXTERM
>The alternative method of selecting multiple objects toggles the selection status of objects; selected symbols are deselected, and deselected symbols are selected.</N.NOTE
><B.BODY>This section describes how to copy nodes and how to replace one component with another.<RBW-IDXTERM TERM1="diagram component" TERM2="copying"></RBW-IDXTERM
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>To create new diagram components and items.</CX5FX5FBULLET.EMPHASIS
> In an ObjectTeam diagram, copying a node creates a second copy of the diagram component. When you edit the label of the second diagram component, as described in <RBW-XREF REFID="36919" TYPE="XREF-TEXTCOPY">Editing Labels</RBW-XREF
>, you create a new item in the repository. This is a convenient way to create new items that are similar to existing items.</RBW-PARABODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>To copy diagram components to another tool.</CX5FX5FBULLET.EMPHASIS
> If you are using Microsoft Windows, you can copy diagram components to OLE&truehy;enabled tools, such as Microsoft Word. This is a convenient way to include diagrams in documents.</RBW-PARABODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>To replace one diagram component with another.</CX5FX5FBULLET.EMPHASIS
> Replacing components is a convenient alternative to deleting and reentering them. It is particularly useful when you need to change the multiplicity of an association or the type of a generalization.</RBW-PARABODY
>You cannot move nodes between diagrams, but you can merge diagrams, as described in <RBW-XREF REFID="40261" TYPE="XREF-TEXTCOPY">Merging Diagrams</RBW-XREF
>.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to copy diagram components to another tool</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Windows</SL.SUBLABEL
><B.BODY>This feature is only available on Windows.</B.BODY
><RBW-PARABODY>From the control panel, select the symbol that you want to use in place of that component. For example, in the control panel, select the Association symbol and the mandatory and optional multiplicity selectors.</RBW-PARABODY
><LR.LIST.RESULT>ObjectTeam replaces the selected component with the new symbol. If the attempted replacement conflicts with the diagram syntax, ObjectTeam displays an error message and prevents the replacement.</LR.LIST.RESULT
> are the names that you give to diagram components. Some labels appear inside the component they name, others appear near the component they name.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing a label creates a new item</SL.SUBLABEL
><B.BODY>Diagram components are usually associated with items in the repository. Editing the label of a diagram component creates a new item. To change the name of an item and its associated diagram component, use Edit | Change Name, as described in <RBW-XREF REFID="42724" TYPE="XREF-TEXTCOPY">Viewing and Renaming Items</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to edit a label<RBW-IDXTERM TERM1="label" TERM2="editing"></RBW-IDXTERM
><RBW-PARABODY>Click the text of the label.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The Pointer changes to an I bar, indicating that you can begin editing. If you are entering text in a node, such as a class or note, and the label grows wider than the node, then the node expands to accommodate the text.</LR.LIST.RESULT
><B.BODY>Alternatively, you can select the text that you want to copy, and then click the middle mouse button where you want to place the text.</B.BODY
> are the names that you give to diagram components. You can specify a formal syntax for labels. Text is checked for this syntax as soon as it is entered and is refused if it does not meet the rules. If no syntax has been specified, any text is accepted.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Types of syntax</L.LABEL
><B.BODY>Each diagram has different symbols, so the syntax you can specify for each diagram is different. Label syntax is not available in the Sequence Diagram editor. </B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The 0 indicates that there is no maximum length for the name; there are no restrictions on first or subsequent characters. This is the default syntax.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The maximum length of the name is 12 characters; the first character must be a capital letter; subsequent characters can be any alphanumeric character.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The maximum length of the name is 4 characters; the first character must be lowercase a, b, or c; subsequent characters can be lowercase a to e.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The maximum length of the object name is 4 characters; the first character can be any symbol between ASCII value 052 and 176; subsequent characters can be uppercase letters A to Z, the dollar symbol, or the colon.</CELLBODY
>The ObjectTeam diagram editors have a hidden grid that aligns objects. Symbols that you insert, copy or move, snap to this grid, ensuring horizontal and vertical alignment of symbols and producing a neat diagram. The size of the grid squares determines the distance between snap positions. The smaller the squares, the more precisely the objects can be positioned.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to specify grid size<RBW-IDXTERM TERM1="Grid (Options menu)"></RBW-IDXTERM
><RBW-PARABODY>Bold changes the font used for class names in CDs, initiators in SDs, state activities and classes in STDs, and actors and use cases in UCDs.<RBW-IDXTERM TERM1="class" TERM2="font for"></RBW-IDXTERM
><B.BODY>You can undo the most recent graphical diagram edit or revert to the last saved version of the diagram. When you revert to the last saved version, you lose all edits made to the diagram since the last time you saved, except for changes that are made to <CX5FX5FTERM>defined items</CX5FX5FTERM
> (see <RBW-XREF REFID="29698" TYPE="XREF-TEXTCOPY">Working With Items</RBW-XREF
>).</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to undo the most recent change<RBW-IDXTERM TERM1="diagram" TERM2="undoing edits"></RBW-IDXTERM
><RBW-PARABODY>To revert to the last saved version of the diagram, select File | Reload.</RBW-PARABODY
></P.PROCEDURE
><LRS.LIST.RESULT.SINGLE>The system closes the current diagram and opens the last saved version of the diagram. Any work done since the last time you saved the diagram is lost except for changes made to defined items.</LRS.LIST.RESULT.SINGLE
><B.BODY>The Note symbol lets you attach a comment to any component in a diagram. A Note can be of unlimited length.</B.BODY
><B.BODY>Unlike other nodes, Notes do not have properties. They are therefore ignored during diagram checking and do not appear in reports.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="42581"></RBW-ANCHOR
>Working with Notes</L.LABEL
><B.BODY>Notes behave like any other node. For details on how to insert, delete, move, and resize nodes, see <RBW-XREF REFID="21332" TYPE="XREF-TEXTCOPY">Editing Diagrams</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changing the Notes font</L.LABEL
><B.BODY>Notes are displayed in their own font. For details on how to set the font used in Notes, see <RBW-XREF REFID="12688" TYPE="XREF-TEXTCOPY">How to change diagram fonts</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Connecting Notes to other components</L.LABEL
><B.BODY>A Note is connected to other components in a diagram by the Note connector. </B.BODY
><B.BODY>A Note can be connected to any component other than another Note or Note connector. A single Note can be connected to more than one component.</B.BODY
><B.BODY>For details on how to insert connectors in diagrams, see <RBW-XREF REFID="18141" TYPE="XREF-TEXTCOPY">How to create a connector</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Free text</L.LABEL
><B.BODY>Use Notes to clarify or highlight elements within a diagram. If you want to attach more extensive textual descriptions to a component, use the Free Text property. For more details on free text, see <RBW-XREF REFID="22035" TYPE="XREF-TEXTCOPY">Specifying Properties</RBW-XREF
>When you draw a symbol in a diagram editor, you create a <CX5FX5FTERM>component</CX5FX5FTERM
>, which is a graphical element in the repository. When you specify property values for the component, you create an <CX5FX5FTERM>item</CX5FX5FTERM
>, which is a semantic element in the repository. </B.BODY
><B.BODY>Every element in a project is either an item or an organizational unit (a configuration, phase, system, file, or group). Items are always part of a system or a file.</B.BODY
> An item name can be up to 80 characters in length. All printable ISO&truehy;Latin&truehy;1 characters, except space, tab, newline, slash, colon, and comma are allowed in item names.</RBW-PARABODY
> The type of an item is determined by the symbol used to create it. The relationship between symbol and type is fixed internally in ObjectTeam and cannot be changed. The types used in ObjectTeam are as follows:</RBW-PARABODY
><LT.LIST.TEXT>Appendix B, Type and Scope of Diagram Components, lists the type of each diagram component.</LT.LIST.TEXT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose of items</L.LABEL
><B.BODY>Items allow different graphical elements to refer to the same semantic element.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>When you create the Rental class in a CD, you create an item with the name Rental and type cl. By default, ObjectTeam associates this item with any other Rental class that you create in any other diagram in the same Phase.</B.BODY
> belong to another item. Operations and classes, for example, are both items. Because an operation always belongs to a class, an operation is a qualified item. </B.BODY
><B.BODY>The name of a qualified item consists of the owner item name and the qualified item name. For example, the getName operation on the Member class is named Member.getName. The operation getName may appear in several classes; however, because getName is a qualified item, each operation is unique to the class in which getName appears. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
>If the item exists, the Define Item button is dimmed.</N2.NOTE.2
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Alternative for classes</L.LABEL
><B.BODY>When you create a class in a CD, you often specify its attributes and operations before specifying its properties. When you add an attribute or operation to a class symbol, ObjectTeam defines the class item. Therefore, you rarely use the previous procedure to define class items.</B.BODY
><RBW-PARABODY>In the Browser at the system level, the pseudo object <defined items> lists all items that have scope phaseDef, phaseRef, or System. This section describes how to view items in the Browser.</RBW-PARABODY
><RBW-PARABODY>The report On Items and Properties can be run at any level in the Browser or from a diagram editor. The report displays all items (including those with scope File) visible at the selected level. See <RBW-XREF REFID="27975" TYPE="XREF-TEXTCOPY">Reporting in ObjectTeam</RBW-XREF
> for more information. </RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to view defined items<RBW-IDXTERM TERM1="item" TERM2="displaying"></RBW-IDXTERM
>Editing the label of a component creates a new item. It does not change the name of the item. To change the name of an item, you must use one of the following procedures.</W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to rename an item from the Browser<RBW-IDXTERM TERM1="Change Name (File menu)" TERM2="of item"></RBW-IDXTERM
>When you rename an item, ObjectTeam updates the repository immediately. The new item name remains even when you close the diagram without saving changes.</N.NOTE
><RBW-PARABODY>Specify implicit properties through the diagrams. ObjectTeam creates these properties when you add components to a diagram and stores them in the diagram file. For example, in the CD, you use the multiplicity specifications at either end of an association to specify the multiplicity of the association. </RBW-PARABODY
><RBW-PARABODY>Specify explicit properties through the Edit Properties dialog box, as described in <RBW-XREF REFID="26965" TYPE="XREF-TEXTCOPY">How to specify explicit properties</RBW-XREF
>. Explicit properties are either item properties or component properties, as described in <RBW-XREF REFID="14241" TYPE="XREF-TEXTCOPY">Item properties</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="14241"></RBW-ANCHOR
>Item properties</L.LABEL
><B.BODY>Item properties are stored with the item. When you change item properties, ObjectTeam updates the repository immediately. The new values remain even when you close the diagram without saving changes. The following table briefly describes the item properties available.</B.BODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Contains unrestricted text about the object, like comments, motivations, and revision data. </CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies system as the Actor Type if the corresponding use case actor is a system actor. The default Actor Type of a use case actor is user. </CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Contains unrestricted text that describes the corresponding use case. Use this property to describe variants on the basic use case scenario, for example, the sequence of transactions that occurs in the case of an error. </CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Contains unrestricted text that describes the corresponding use case. Use this property to describe the most common or important sequence of transactions for the use case. </CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the value secondary if the corresponding use case describes the system’s behavior under exceptional conditions.</CELLBODY
><CELLBODY>The default value primary indicates main line functions of the system. </CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Contains unrestricted text that describes the corresponding use case. Use this property to describe the state of the system after the use case is performed. </CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Contains unrestricted text that describes the corresponding use case. Use this property to describe the conditions that must be met before the use case can be performed. </CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
><RBW-ICONIZE></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Component properties</L.LABEL
><B.BODY>Component properties are stored in the diagram file. Changes to component properties are saved when you save your diagram changes. The following table briefly describes the component properties available.</B.BODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the type of object: entity (a persistent object that survives the program execution), interface (an object with external I/O, that is an object that is activated from outside the system), or control (any other type of object).</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Use Case Diagram</CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>When turned on, this defines the corresponding use case actor as initiator for a use case.</CELLBODY
><CELLBODY>By default, this property is turned off. </CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
><RBW-ICONIZE></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Additional properties</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Code and document generation</SL.SUBLABEL
><B.BODY>Several additional explicit properties are used for code and document generation. For information about these properties, see the <CX5FX5FTITLE>ObjectTeam Code Generation Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for your code generator and the <CX5FX5FTITLE>ObjectTeam Document Generation Guide</CX5FX5FTITLE
><B.BODY>All explicit properties are defined in two customization files: <CX5FX5FFILE.NAME>proplocs.proplocs</CX5FX5FFILE.NAME
> and <CX5FX5FFILE.NAME>propdefs.propdefs</CX5FX5FFILE.NAME
>. These files can be edited and saved on any level in the repository. For more information about defining your own properties, see the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="26965"></RBW-ANCHOR
>How to specify explicit properties <RBW-IDXTERM TERM1="item" TERM2="specifying properties"></RBW-IDXTERM
><B.BODY>An item’s scope defines its name space and where it is defined. You specify an item’s scope as Phase, System, or File.</B.BODY
><B.BODY>Appendix B, Type and Scope of Diagram Components, lists the item type and initial scope of each diagram component. An item keeps its initial scope unless you change it.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Scope and item name space</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="scope of item"></RBW-IDXTERM
> The item’s name must be unique within the phase. For example, if class Member appears in two systems that are in the same phase, and both classes have scope Phase, then both systems are referring to the same item.</RBW-PARABODY
> The item’s name must be unique within the system. For example, if class Member appears in two systems that are in the same phase, and both classes have scope System, then the systems are referring to two different items.</RBW-PARABODY
> The item’s name must be unique within the file. For example, if association Rents appears in two CDs in the same system, and both associations have scope File, then the CDs are referring to two different items.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Scope and item definitions</L.LABEL
><B.BODY>Scope also defines where an item’s definition is stored. (Qualified items always have the same scope as the owner item.)</B.BODY
><RBW-PARABODY>The system in which you defined the item contains the item definition. In this system, ObjectTeam creates the item with scope <RBW-IDXTERM TERM1="phaseDef, item scope"></RBW-IDXTERM
><RBW-PARABODY>Any system that references the item contains a reference to the item. In these systems, ObjectTeam creates the item with scope <RBW-IDXTERM TERM1="phaseRef, item scope"></RBW-IDXTERM
> The system in which you defined the item contains the item definition. ObjectTeam creates the item with scope <RBW-IDXTERM TERM1="system" TERM2="item scope"></RBW-IDXTERM
> The file in which you defined the item contains the item definition. ObjectTeam creates the item with scope <RBW-IDXTERM TERM1="file, item scope"></RBW-IDXTERM
><B.BODY>Generally, if you can see an item in a diagram editor, and the diagram editor is not loaded read&truehy;only, you can edit the item. The following items are useful to keep in mind when editing:</B.BODY
><RBW-PARABODY>If an item has scope Phase or System, editing it can affect systems or diagrams other than the current diagram. To see the scope of an item, select the item and then select Edit | Scope. The Edit Scope dialog box indicates the current scope of the item.</RBW-PARABODY
><RBW-PARABODY>If a class has scope Phase, you can edit its name (Item | Change Name) and properties (Item | Edit Properties) from any system in which it appears. However, the class’s attributes and operations are only visible in, and can only be edited in, the system that contains the class definition.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Locating items</L.LABEL
><B.BODY>On each level, at most one item with a given name and type can exist. The levels form a nested structure — file, system, phase — in which items can be found. Items are searched for (by name and type) starting at a given level. If the item is not present at that level, ObjectTeam searches the next highest level until a matching item is found, or the highest level is reached.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to change an item’s scope<RBW-IDXTERM TERM1="item" TERM2="changing scope"></RBW-IDXTERM
>When you change an item’s scope, ObjectTeam updates the repository immediately. The item’s new scope remains even if you close the diagram without saving changes.</N.NOTE
>If more than one item is associated with the selected object, the Items dialog box appears, as shown in the following figure. Select the item and click OK.</N2.NOTE.2
><RBW-PARABODY>Select an option, and then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>An item’s scope determines where its definition is stored. Changing its scope can change its definition. Use the options to determine the item definition for the new scope.</LT.LIST.TEXT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changing the scope downwards</L.LABEL
><B.BODY>Changing the scope <CX5FX5FEMPHASIS>downward</CX5FX5FEMPHASIS
> means changing it from a higher level to a lower level, for example, from Phase to System. Typically, when you change the scope downward, you <CX5FX5FTITLE>copy</CX5FX5FTITLE
> the item definition. The item definition also remains on the higher level. The Edit Scope dialog box, presents the following options:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY><CX5FX5FFILE.NAME>Create empty definition on File/System level</CX5FX5FFILE.NAME
> </CELLBODY
><CELLBODY>Create a new item definition, with default property values, in the current file or system.</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>System to File</CELLBODY
><CELLBODY>Phase to File </CELLBODY
><CELLBODY>Phase to System</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY><CX5FX5FFILE.NAME>Copy definition to File/System level</CX5FX5FFILE.NAME
> </CELLBODY
><CELLBODY>Copy the existing item definition, including its property values, to the current file or system.</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>System to File</CELLBODY
><CELLBODY>Phase to File</CELLBODY
><CELLBODY>Phase(Ref) to System</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY><CX5FX5FFILE.NAME>Restrict definition to System level</CX5FX5FFILE.NAME
> </CELLBODY
><CELLBODY>Item is defined in the current system. Do not modify item definition; instead change scope.</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Phase(Def) to System</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
><RBW-ICONIZE></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changing the scope upward</L.LABEL
><B.BODY>Changing the scope <CX5FX5FEMPHASIS>upward</CX5FX5FEMPHASIS
> means changing it from a lower level to a higher level; for example, from System to Phase. Typically, when you change the scope upward, you <CX5FX5FTITLE>move</CX5FX5FTITLE
> the item definition. The Edit Scope dialog box presents the following options:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY><CX5FX5FFILE.NAME>Export definition to System/Phase level</CX5FX5FFILE.NAME
> </CELLBODY
><CELLBODY>Move the existing item definition, including its property values, to the current system. The item definition in the file is deleted.</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>File to System</CELLBODY
><CELLBODY>File to Phase(Def)</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY><CX5FX5FFILE.NAME>Make definition available on Phase level</CX5FX5FFILE.NAME
> </CELLBODY
><CELLBODY>Item is defined in the current system. Do not modify item definition; instead change scope.</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>System to Phase(Def)</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY><CX5FX5FFILE.NAME>Refer to (not yet existing definition) on System level</CX5FX5FFILE.NAME
> </CELLBODY
><CELLBODY>Create a new item definition, with default property values, in the current system. The item definition in the file is deleted.</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>File to System</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY><CX5FX5FFILE.NAME>Refer to (not yet existing definition) on Phase level</CX5FX5FFILE.NAME
> </CELLBODY
><CELLBODY>The item definition in the file is deleted. The item is undefined.</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>File to Phase(Ref)</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY><CX5FX5FFILE.NAME>Refer to definition on Phase level</CX5FX5FFILE.NAME
> </CELLBODY
><CELLBODY>The item definition in the file is deleted. The item definition exists in another system.</CELLBODY
>If you attempt to create an item definition in a system that already contains a definition for that item, an error message appears. You must delete the existing definition before you can create a new one. </N.NOTE
><B.BODY>When you name a diagram component, you create an item. If you delete the diagram symbol, the item remains in the repository and can be used in other diagrams. If you do not use the item, removing it from the repository improves performance and avoids unexpected name conflicts.</B.BODY
><B.BODY>This chapter describes each diagram, its purpose, and the symbols that it uses. The diagram notation is based on the Unified Modeling Language (UML) for Object&truehy;Oriented Development, developed by Grady Booch, Ivar Jacobson, and James Rumbaugh.<RBW-IDXTERM TERM1="UML"></RBW-IDXTERM
><B.BODY>By default, ObjectTeam diagrams use UML notation. However, ObjectTeam also provides support for OMT notation, as described in <RBW-XREF REFID="39383" TYPE="XREF-TEXTCOPY">Appendix A, OMT Support</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</L.LABEL
><B.BODY>The following chapters provide additional diagram information:</B.BODY
> describes how to customize the diagram editors.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="25359"></RBW-ANCHOR
>Relationships among diagrams</L.LABEL
><B.BODY>In ObjectTeam, the components in one diagram are often related to the components in another; for example, an actor in a UCD is a class in a CD. This relationship has two consequences for your work in ObjectTeam:</B.BODY
> ObjectTeam provides special navigation paths that allow you to move from a component in one diagram to a related diagram. See <RBW-XREF REFID="33913" TYPE="XREF-TEXTCOPY">Navigating Between Diagrams on page 3–7</RBW-XREF
> The following table shows diagram objects that are semantically related. The Check utility ensures that your ObjectTeam model adheres to these semantics. For a complete list of what is checked on each diagram, see the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><B.BODY>The Class Diagram (CD) defines the objects in a system and describes their structural components. The following points are important for the objects, or classes, in class diagrams:</B.BODY
><B.BODY>This section describes the symbols used in the class diagram. The following table shows the symbols as they appear in the control panel.</B.BODY
>The Vertex, Select, Note, and Note connector symbols are common to all diagrams. They are described in <RBW-XREF REFID="35957" TYPE="XREF-TEXTCOPY">Chapter 3, Working With Diagrams</RBW-XREF
>.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="39851"></RBW-ANCHOR
>Class<RBW-IDXTERM TERM1="class" TERM2="symbol in CAD"></RBW-IDXTERM
></L.LABEL
><B.BODY>A class is a group of objects with similar properties (attributes), common behavior (operations), common relationships to other objects, and common semantics. <RBW-IDXTERM TERM1="abstract class"></RBW-IDXTERM
>Objects in a class have the same attributes and behavior patterns. Most objects distinguish themselves through differences in their attribute values and relationships to other objects.</B.BODY
><B.BODY>You enter the class name in the top text area of the class symbol:</B.BODY
>Attributes describe an object’s characteristics. You specify attributes in the middle text area of the class symbol. Use the following syntax to specify a data attribute:</B.BODY
><RBW-PARABODY>$ indicates a class (static) attribute — a value that applies to the entire class of objects, rather than to each instance.</RBW-PARABODY
><RBW-PARABODY>* indicates an attribute that should be part of the primary key. This is only meaningful if your target language supports persistency. For more information, see the <CX5FX5FTITLE>ObjectTeam Code Generation Guide</CX5FX5FTITLE
><RBW-PARABODY>$ indicates a class (static) operation — an operation that applies to the entire class of objects, rather than to one instance</RBW-PARABODY
><RBW-PARABODY>{abstract} indicates an abstract operation, which is an operation defined, but not implemented by, an abstract class. The operation must be implemented by all concrete descendant classes.</RBW-PARABODY
><RBW-IDXTERM TERM1="Class Definition Matrix" TERM2="and Class Association Diagram"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Class Association Diagram" TERM2="and Class Definition Matrix"></RBW-IDXTERM
>Class Definition Matrices (CDMs)</SL.SUBLABEL
><B.BODY>When you specify the first attribute or operation for a class, ObjectTeam creates a Class Definition Matrix (CDM) for the class. The CDM appears in the Navigation and Information areas, but cannot be edited directly. When you open a CDM, ObjectTeam starts a Class Diagram editor, opening the Class Diagram that contains the class defined by the CDM. If the class appears in more than one Class Diagram, ObjectTeam prompts you to select the one that you want to open.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="19961"></RBW-ANCHOR
>Association<RBW-IDXTERM TERM1="association" TERM2="symbol in CAD"></RBW-IDXTERM
><B.BODY>Associations describe the relationships among objects. An association is a group of links in which each a link is a physical or conceptual connection between instances of an object. An association in a Class Diagram describes a set of potential links in the same way that a class describes a set of potential objects.</B.BODY
><BI.BODY.INTRO>An association is inherently bidirectional; thus, you can specify a role name for each end of the association. As the following figure shows, the role name at the far end of an association describes the association from the class at the near end to the class at the far end. In addition to the role names, you can also specify a name for the association.</BI.BODY.INTRO
><BI.BODY.INTRO>Multiplicity is specified at both ends of the association. The multiplicity at the far end of an association specifies how many instances of the class at the far end of the association can relate to a single instance of the class at the near end of the association. In the previous figure, each instance of class&truehy;A can be related to many instances of class&truehy;B; each instance of class&truehy;B must be related to exactly one instance of class&truehy;A.</BI.BODY.INTRO
><B.BODY>The symbols in the control panel provide three multiplicity values: mandatory (1), optional (0..1), and many (*). After adding an association to the diagram, you can edit the multiplicities as needed. For example, you might edit a multiplicity value to indicate a multiplicity of 2 or more (2..*).</B.BODY
><RBW-PARABODY>In the control panel, select the multiplicity for the beginning of the association, the multiplicity for the end of the association, and the association symbol. For example, to create a one&truehy;to&truehy;many association, select the Begin Mandatory Association symbol, the End Many Association, and the Association symbol.</RBW-PARABODY
><RBW-PARABODY>If necessary, edit the multiplicities of the association.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="40661"></RBW-ANCHOR
>N&truehy;ary associations</L.LABEL
><B.BODY>Most associations between three or more classes are not true n&truehy;ary associations. You can usually decompose these apparent n&truehy;ary associations into more meaningful and correct binary associations or phrase them as qualified associations.</B.BODY
><B.BODY>True n&truehy;ary associations represent associations between three or more classes. The n&truehy;ary association is an atomic unit and cannot be subdivided into binary associations without losing information. </B.BODY
><RBW-PARABODY>Repeat step 5 for each class in the n&truehy;ary association.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>More classes<RBW-IDXTERM TERM1="more classes" TERM2="symbol in CAD"></RBW-IDXTERM
></L.LABEL
><BI.BODY.INTRO>A more&truehy;classes symbol indicates that additional classes exist, but are not shown. This symbol cannot have a name.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Aggregation<RBW-IDXTERM TERM1="aggregation" TERM2="symbol in CAD"></RBW-IDXTERM
><BI.BODY.INTRO>An aggregation is a relationship in which objects that represent the components of something are associated with an object that represents the entire assembly. For example, a car could be modeled as an aggregate of its parts.</BI.BODY.INTRO
><B.BODY>Aggregation is a special, strong form of association. (If two objects are bound tightly by a part&truehy;whole relationship, you show the relationship as an aggregation. If two objects are usually considered as independent, even though they may often be linked, you show the relationship as an association.) Aggregation adds semantic connotations in certain cases. In an aggregation, an aggregate object is made of components. Components are part of the aggregate. Significant properties of aggregation are transitivity, antisymmetry and propagation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Qualified association</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="qualified association" TERM2="symbol in CAD"></RBW-IDXTERM
>A qualified association is a one&truehy;to&truehy;many or many&truehy;to&truehy;many association in which the effective multiplicity is reduced by a qualifier. </B.BODY
>A qualified aggregation is a one&truehy;to&truehy;many or many&truehy;to&truehy;many aggregation in which the effective multiplicity is reduced by a qualifier.</B.BODY
><BI.BODY.INTRO>Constraints restrict the relationship between any two objects in the Class Diagram: classes, attributes, or associations. </BI.BODY.INTRO
>Association class connector<RBW-IDXTERM TERM1="association class connector" TERM2="symbol in CAD"></RBW-IDXTERM
></L.LABEL
><B.BODY>Graphically, an association class connector links a class to an association (including n&truehy;ary associations). Semantically, the association, the association class, and the association class connector are a single model element. The association has class&truehy;like properties, such as attributes, operations, and associations, which are defined by the association class.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to insert an association class</SL.SUBLABEL
><B.BODY>To insert an association class connector:</B.BODY
>A generalization is the relationship between a class and one or more refined versions of it. The class being refined is the superclass; each refined version is a subclass. Each subclass inherits all the features of its superclass, but adds its own attributes and operations.</B.BODY
><B.BODY>Generalization is sometimes called the is&truehy;a relationship, because each instance of a subclass is also an instance of the superclass. A generalization describes an association between one independent class and several dependent classes; the independent class, which is the superclass, is a sort of largest common denominator of the various subclasses that are associated with it. Generalization (and inheritance) is a powerful abstraction for sharing similarities among classes while preserving their differences.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Two types of generalization</SL.SUBLABEL
><B.BODY>ObjectTeam supports two types of generalization:</B.BODY
><B.BODY>A class can inherit from more than one class hierarchy or from more than one subclass in an overlapping generalization, but can never inherit from two subclasses in the same disjoint generalization.</B.BODY
>Propagation applies one or more operations to an associated object when the operation is applied to the starting object. (If you specify more than one operation, use commas to separate the operation names.) In the following figure, applying operation on Class&truehy;A causes the same operation to be carried out on Class&truehy;B.</BI.BODY.INTRO
><B.BODY>The propagation symbol can be placed on or near an connector, and will move with the connector it belongs to. Before inserting a propagation symbol, firstt connect two objects with an connector and then insert the propagation symbol by clicking near the connector. You can move the propagation symbol during insertion, to prevent it from overlapping its connector.</B.BODY
><B.BODY>A propagation symbol can be attached to the following connectors:</B.BODY
><B.BODY>The Collaboration Diagram shows a set of objects related in a particular context, and the set of messages exchanged between the objects to achieve a desired operation or result.</B.BODY
><B.BODY>The COD is a graph of references to objects and the links between those objects, with message flows attached to its links. The diagram shows the objects relevant to the performance of an operation.</B.BODY
><B.BODY>Use the Collaboration Diagram to show complex associations between classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Relation to other diagrams and objects</L.LABEL
><B.BODY>A Collaboration Diagram can stand alone or be the instantiation of (parts of ) other diagrams. </B.BODY
><B.BODY>In the Collaboration Diagram, message flows can be drawn along the links between objects to specify the interactions between the objects.</B.BODY
><B.BODY>Its name is usually classified by a Class or Use Case name.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Relation to Class Diagram</SL.SUBLABEL
><B.BODY>The Collaboration diagram can be a decomposition of a Class, Class Diagram, or part of a Class Diagram.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Relation to Use Case Diagram</SL.SUBLABEL
><B.BODY>The Collaboration diagram can be a decomposition of a Use Case, Use Case Diagram, or part of a Use Case Diagram.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example COD</L.LABEL
><FA.FIGURE.ANCHOR>The following show an example of a Collaboration Diagram</FA.FIGURE.ANCHOR
><B.BODY>This section describes the symbols used in the Collaboration diagram. The following table shows the symbols as they appear in the control panel.</B.BODY
>The Vertex, Select, Note, and Note connector symbols are common to all diagrams. They are described in <RBW-XREF REFID="35957" TYPE="XREF-TEXTCOPY">Chapter 3, Working With Diagrams</RBW-XREF
>.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Actor</L.LABEL
><FA.FIGURE.ANCHOR>An actor in a Collaboration Diagram represents the person, software, hardware, or other agent external to the system that is interacting with the system. </FA.FIGURE.ANCHOR
><B.BODY>The “stick man” figure represents the actor:</B.BODY
><B.BODY>The instance name has scope Phase and is considered a classname.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Instance name</SL.SUBLABEL
><B.BODY>the name of the instance</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Instance type</SL.SUBLABEL
><B.BODY>The instanceType can be an item to correspond to a class or a use case.</B.BODY
><B.BODY>The initial scope of an instance is Phase</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>N&truehy;ary Link</L.LABEL
><B.BODY>An N&truehy;ary Link symbol is the node part of an n&truehy;ary link.It is an instance of an n&truehy;ary association (see <RBW-XREF REFID="40661" TYPE="XREF-TEXTCOPY">N&truehy;ary associations</RBW-XREF
>)</B.BODY
><B.BODY>The n&truehy;ary link is represented by a diamond. </B.BODY
><B.BODY>the n&truehy;ary link is connected to the appropriate instances and actors by an n&truehy;ary link connector. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Link</L.LABEL
><B.BODY>The link represents an instance of an association between two classes (see also <RBW-XREF REFID="19294" TYPE="XREF-TEXTCOPY">Class Diagram</RBW-XREF
><B.BODY>An association name can be attached to a link to indicate an instance. The name has class syntax</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role names</SL.SUBLABEL
><BI.BODY.INTRO>You can specify a link stereotype and a role name for each end of the link. See <RBW-XREF REFID="21173" TYPE="XREF-TEXTCOPY">Link role names</RBW-XREF
>. </BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Aggregation link</L.LABEL
><B.BODY>The aggregation link is an instance of an aggregation in a Class Diagram. </B.BODY
><B.BODY>An aggregation name can be attached to an aggregation link to indicate an instance. The name has class syntax</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role names</SL.SUBLABEL
><BI.BODY.INTRO>You can specify a link stereotype and a role name for each end of the aggregation link. See <RBW-XREF REFID="21173" TYPE="XREF-TEXTCOPY">Link role names</RBW-XREF
>. </BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Qualified link</L.LABEL
><B.BODY>The Qualified Link consists of a link and a qualifier that represent the value of the qualifier in the association from which this link is an instantiation. </B.BODY
><B.BODY>An qualified association name can be attached to a qualified link to indicate an instance. The name has class syntax</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role names</SL.SUBLABEL
><BI.BODY.INTRO>You can specify a link stereotype and a role name for each end of the qualified link. See <RBW-XREF REFID="21173" TYPE="XREF-TEXTCOPY">Link role names</RBW-XREF
>. </BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Qualified aggregation link</L.LABEL
><B.BODY>The Qualified AggregationLink consists of a aggregation link and a qualifier that represent the value of the qualifier in the aggregation from which this link is an instantiation. </B.BODY
><B.BODY>An qualified aggregation name can be attached to a qualified aggregation link to indicate an instance. The name has class syntax</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role names</SL.SUBLABEL
><BI.BODY.INTRO>You can specify a link stereotype and a role name for each end of the qualified aggregation link. See <RBW-XREF REFID="21173" TYPE="XREF-TEXTCOPY">Link role names</RBW-XREF
>. </BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="21173"></RBW-ANCHOR
>Link role names</L.LABEL
><B.BODY>The connector representing a link (and also aggregation link, qualified link, qualified aggregation link and n&truehy;ary link connector)has the following labels</B.BODY
><E.EXAMPLE>«Link End Stereotype»role name</E.EXAMPLE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Link Stereotypes</SL.SUBLABEL
><B.BODY>You can specify the stereotypes of a link through the link stereotypes in the control panel. For more information on the Link Start Stereotype and Link End Stereotype, see Link stereotypes on page 4–66.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role Names</SL.SUBLABEL
><B.BODY>ObjectTeam adds the following qualifiers to the role names:</B.BODY
><RBW-PARABODY>For n&truehy;ary links the role name is qualified by the type of Instance it </RBW-PARABODY
></LB.LIST.BULLET
><LB.LIST.BULLET>is linked to.k Role Names</LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Messages</L.LABEL
><B.BODY>A message flow carries a message from one object to another along a link (link, qualified link, aggregation link, qualified aggregation link, and n&truehy;ary link connector). </B.BODY
><B.BODY>The message symbols can be placed on or near a connector, and will move with the connector they belong to. Before inserting a message, first connect two objects with a connector and then insert the message by clicking near that connector. You can move the message during insertion, to prevent it from overlapping its connector.</B.BODY
><B.BODY>A message can be attached to the following connectors:</B.BODY
><B.BODY>A comma separated list of sequence numbers followed by a slash. The clause is omitted when the list is empty </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
><sequence&truehy;expression> </SL.SUBLABEL
><B.BODY>A dot separated list of number or names optionally followed by a condition or an iteration (both enclosed in square brackets, the iteration preceded by an asterisk) and separated from the rest of the label by a colon.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
><return&truehy;value> [ = | := ]</SL.SUBLABEL
><B.BODY>A data elemnet with scope file. If the message does not return a value, thenthe return value and the assignment operator are omitted.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
><message&truehy;name> </SL.SUBLABEL
><B.BODY>A process element with scope system.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
><argument&truehy;list></SL.SUBLABEL
><B.BODY>A comma separated list of data elements with scope file. This list is enclosed in brackets and can be empty.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="40495"></RBW-ANCHOR
>Nested message</L.LABEL
><B.BODY>The nested message represents a procedure call or other nested flow of control. The nested sequence is completed before the outer level sequence resumes. </B.BODY
><B.BODY>The asynchronous message symbol is represented by a half stick arrowhead. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>N&truehy;ary link connector</L.LABEL
><B.BODY>An n&truehy;ary link connector is the connector part of an n&truehy;ary link. One side of this connector must be connected to aninstance, the other side to an n&truehy;ary link symbol.</B.BODY
><B.BODY>An n&truehy;ary association role name can be attached to the n&truehy;ary link connector to indicate an instance. The name has class syntax</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role names</SL.SUBLABEL
><BI.BODY.INTRO>You can specify a link start stereotype and a role name for the n&truehy;ary link connector on de side connected to the instance. See <RBW-XREF REFID="21173" TYPE="XREF-TEXTCOPY">Link role names</RBW-XREF
>. </BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="11708"></RBW-ANCHOR
>Link stereotypes</L.LABEL
><B.BODY>You can attach a Stereotype to a Link Role Name to show the type of implementation of the role.</B.BODY
><B.BODY>The direction in which the link was drawn determines where the Link Start Stereotype and the Link End Stereotype are placed.</B.BODY
><B.BODY>You can assign one the following stereotypes:</B.BODY
>e the SD to analyze compl<RBW-IDXTERM TERM1="business event" TERM2="in ETD"></RBW-IDXTERM
>ex business events. Events are actions between the objects in your project. They can also transmit data.</B.BODY
><B.BODY><RBW-IDXTERM TERM1="scenario, in ETD"></RBW-IDXTERM
>A scenario is the sequence of events during one execution of a program. A scenario can include all the events or only the events sent to or received by certain objects in the system.</B.BODY
><B.BODY>Typically, you use SDs to describe only the more complex events. A diagram describing a particular scenario is called a sequence. An SD can contain more than one sequence.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example SD</L.LABEL
><B.BODY>The following SD shows a simple scenario for the use of an automatic teller machine. In this scenario, the system rejects the card. For the customer this transaction is simple: he inserts the card and the card is rejected. For the system, several actions are necessary. A constraint specifying the maximum length of the interval between these actions can be added.</B.BODY
><B.BODY>The following illustration shows the SD for this scenario:</B.BODY
><B.BODY>This sequence is fairly general; you can work out the Insert Card event more completely by including details such as entering the personal identification number and requesting the type of transaction. The analyst must decide what level of detail to use in the SDs.</B.BODY
>The Vertex, Select, Note and Note connector symbols are common to all diagrams. They are described in <RBW-XREF REFID="35957" TYPE="XREF-TEXTCOPY">Chapter 3, Working With Diagrams</RBW-XREF
>.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Initiator<RBW-IDXTERM TERM1="initiator" TERM2="symbol in ETD"></RBW-IDXTERM
></L.LABEL
><B.BODY>The initiator starts the sequence. It represents an external agent, such as a user, that interacts with the system. The initiator can be a class, but does not have to be.</B.BODY
><B.BODY>The following illustration shows an initiator:</B.BODY
><FA.FIGURE.ANCHOR>Because a sequence describes a particular scenario occurring after one particular external event, each sequence can only have one initiator. However, you can draw more than one sequence in a diagram.</FA.FIGURE.ANCHOR
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Object<RBW-IDXTERM TERM1="object" TERM2="symbol in ETD"></RBW-IDXTERM
></L.LABEL
><B.BODY>The object line represents a portion of the lifetime of an object in the system. Time flows from top to bottom on the symbol. The spacing between event symbols is not important. It does not indicate the length of time between events.</B.BODY
><B.BODY>The following illustration shows an object:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The input and output for this object is external, that is, the object is activated by someone outside the system</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>When an object is neither an entity object nor an interface object, it can be defined as a control object.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="17198"></RBW-ANCHOR
>Timing Constraint</L.LABEL
><FA.FIGURE.ANCHOR>The timing constraint is a text tool used to set a constraint on the time interval between two messages. You can mark the messages with timing marks (see <RBW-XREF REFID="24347" TYPE="XREF-TEXTCOPY">Timing mark</RBW-XREF
><B.BODY>How to use the timing constraint is explained below in <RBW-XREF REFID="31465" TYPE="XREF-TEXTCOPY">How to insert a timing constraint</RBW-XREF
>, and <RBW-XREF REFID="36061" TYPE="XREF-TEXTCOPY">How to move a timing constraint</RBW-XREF
><RBW-PARABODY>Enter text in the text block (c).</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The small square disappears.</LR.LIST.RESULT
><LT.LIST.TEXT>Text in text blocks is edited in the same way as text in notes (see <RBW-XREF REFID="42581" TYPE="XREF-TEXTCOPY">Working with Notes on page 3–30</RBW-XREF
><RBW-PARABODY>Drag the text block to its new position. </RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="24347"></RBW-ANCHOR
>Timing mark</L.LABEL
><B.BODY>An event can be labeled on the initiator by a timing mark. The timing mark can be used in combination with the timing constraint (see <RBW-XREF REFID="17198" TYPE="XREF-TEXTCOPY">Timing Constraint</RBW-XREF
>) to set a time interval between two or more events.</B.BODY
><B.BODY>The following illustration shows two timing marks.</B.BODY
><B.BODY>The timing mark is not required for every message, but it can be set for every begin and end of a message. </B.BODY
><B.BODY>When the message is repositioned, the timing mark moves with it.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Messages</L.LABEL
><BI.BODY.INTRO>An message represents an individual stimulus from one object to another. An message may be a signal that something has happened or can transmit data. </BI.BODY.INTRO
><B.BODY>An message occurs at a point in time. More than one message can be sent simultaneously from the same point on the initiator or object line, that is, at the same point in time. </B.BODY
><B.BODY>An object can also send a message to itself. Such a message must arrive at the object at a another point in time.</B.BODY
><B.BODY>The following illustration shows a nested message:</B.BODY
><B.BODY>There are several kinds of messages in a sequence diagram: </B.BODY
><B.BODY>The Nested Message symbol is represented by a filled solid arrowhead. </B.BODY
><B.BODY>It represents a procedure call or other nested flow of control. The nested sequence is completed before the outer level sequence resumes.</B.BODY
><RBW-IDXTERM TERM1="event" TERM2="symbol in ETD"></RBW-IDXTERM
><RBW-ANCHOR ID="41532"></RBW-ANCHOR
>In Scope region</L.LABEL
><FA.FIGURE.ANCHOR>The In Scope region is a white rectangle that can be placed on top of an initiator or an object to show that the object is in scope. </FA.FIGURE.ANCHOR
><B.BODY>The following illustration shows the In Scope region:</B.BODY
><B.BODY>When an message is nearby the symbol will be linked to that event. The InScope region can be moved up and down the axis of the object, but not away from it. When it is moved up or down, the event(s) attached to it will be moved with it. </B.BODY
>When the event is moved, the InScope region is not moved. (This means that the event can be moved away from a region and connected to another).</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Object Terminator</L.LABEL
><FA.FIGURE.ANCHOR>The object termination symbol represents the destruction of the object. The object termination symbol has no labels.</FA.FIGURE.ANCHOR
><RBW-PARABODY>The changes of the object values: the transitions</RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>More than one transition may leave a state. The first event to occur causes the corresponding transition to fire. Transitions are guarded by conditions, i.e. an event can only fire a transition if the condition of the event is true. A condition is valid over an interval of time.</LT.LIST.TEXT
><B.BODY>When drawing a state diagram, concentrate on the following:</B.BODY
>A state diagram describes the behavior of a single class of objects. All instances of a class have the same behavior, because they share the same class features, so they all share the same state diagram. But as each object has its own attribute values, so each object also has its own state. Each object is independent of other objects and proceeds at its own pace.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Types of STDs</L.LABEL
><B.BODY>There are two kinds of STDs:<RBW-IDXTERM TERM1="one-shot life cycle, in STD"></RBW-IDXTERM
><RBW-IDXTERM TERM1="continuous loop, in STD"></RBW-IDXTERM
><B.BODY>You can define an activity further through graphical decomposition. Opening an activity leads to another STD in which the activity is contained, or that is the definition itself.</B.BODY
><B.BODY>An activity has a starting event, an ending event, and possibly some intermediate events. A continuous activity persists until an event terminates it by causing a transition from the state. A sequential activity terminates by itself after an interval of time.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Decomposition</L.LABEL
><B.BODY>Do not use super states to specify events or concurrency. Specify these through decomposition diagrams. Use decomposition to define activities as well. Each state in the decomposition diagram represents one step of the activity. The decomposition diagram is a one&truehy;shot diagram with input and output transitions.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example STD</L.LABEL
><B.BODY>The following illustration shows a sample STD:</B.BODY
><B.BODY>This section describes the symbols used in the STD. The following illustration shows the symbols as they appear in the diagram control panel:</B.BODY
>The Vertex, Select, Note and Note connector icons are common to all diagrams. They are described in <RBW-XREF REFID="35957" TYPE="XREF-TEXTCOPY">Chapter 3, Working With Diagrams</RBW-XREF
>.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>State<RBW-IDXTERM TERM1="state" TERM2="symbol in STD"></RBW-IDXTERM
></L.LABEL
><B.BODY>A state represents an externally observable mode of behavior, i.e. an interval of time over which some behavior persists. During its life, an object passes through various states of behavior. As a state occupies an interval of time, it has duration. A state is passive, which means that no transformations occur within a state. However, a state can have activities running internally. Use the <RBW-XREF REFID="32452" TYPE="XREF-TEXTCOPY">State with internal actions</RBW-XREF
><B.BODY>The name of the state is the name of the behavior exhibited by the object. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="32452"></RBW-ANCHOR
>State with internal actions</L.LABEL
><FA.FIGURE.ANCHOR>A special kind of state is the state with internal actions. It is interchangeable with the state described above. In the bottom section you can type actions that are initiated by this state.</FA.FIGURE.ANCHOR
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>do/Warning: XtRemoveGrab asked to remove a widget not on the list</CELLBODY
></ENTRY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>an activity that may arise during the existence of the state</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Super State<RBW-IDXTERM TERM1="super state" TERM2="symbol in STD"></RBW-IDXTERM
></L.LABEL
><B.BODY>A super state is a way of generalizing parts of a diagram. The generalized part, the super state, can be treated from the outside as a single state.</B.BODY
><B.BODY>In the diagram, the super state is a rectangle with rounded corners. States and transitions inside the super state are connected to the outside via the super state only. Transition arrows can be attached to the super state from the inside and the outside. By nesting a relatively autonomous part of a diagram in a super state, the number of transitions can be reduced, thereby clearing up the diagram.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Initial state<RBW-IDXTERM TERM1="initial state" TERM2="symbol in STD"></RBW-IDXTERM
></L.LABEL
><BI.BODY.INTRO>The initial state is the first state of behavior of an object after its creation.</BI.BODY.INTRO
><BI.BODY.INTRO>A history state is shown as a small circle with capital H and can only be inserted in a super state. Only one history state can exist in a one superstate.</BI.BODY.INTRO
><B.BODY>The history state symbolizes the status quo of the super state and its sub states at the moment that an event is activated from the super state to a state external to the super state. </B.BODY
><B.BODY>When the process resumes at the superstate, you can return a transition to the history state in the superstate to resume at the level that the superstate had before it was left.</B.BODY
><B.BODY>Use the horizontal Complex Transition Node to converge/diverge more or less vertical transitions, and the vertical Complex Transition Node to converge/diverge more or less horizontal transitions.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class<RBW-IDXTERM TERM1="class" TERM2="symbol in STD"></RBW-IDXTERM
></L.LABEL
><B.BODY>A class is a group of objects with similar properties (attributes), common behavior (operations), common relationships to other objects and common semantics.</B.BODY
><B.BODY>STD classes can be further defined through graphical decomposition. Opening an STD class leads to a CD in which the STD class is contained, or that is the definition itself.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Transition<RBW-IDXTERM TERM1="event" TERM2="symbol in STD"></RBW-IDXTERM
></L.LABEL
><B.BODY>An event is something that happens at a point in time. It has no significant duration. An event causes, or “fires” a change of state: the transition. The arrow of the transition indicates the order in which the states appear. A complete STD specifies a state sequence that is caused by an event sequence.</B.BODY
><RBW-PARABODY>history states (only as target)</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>Events to classes are drawn with event messages.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Label</SL.SUBLABEL
><B.BODY>In STDs, the events are the label names of the transitions between the states. You list conditions in square brackets after an event name. An action is indicated on a transition after the event name; it is preceded by a slash.:</B.BODY
><B.BODY>Event messages can be further defined through graphical decomposition. Opening an event message leads to a new STD. The new diagram’s name is the name of the class preceding the name of the opened event message. Event messages always originate from events and end in a class.</B.BODY
><B.BODY>UCDs allow you to capture business events by analyzing how objects external to the system interact with the system. A UCD represents a particular sequence of transactions between the system and an actor (an end user or system external to the system being analyzed). You can use UCDs to analyze system requirements and to help you define system boundaries.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example UCD</L.LABEL
><B.BODY>The following UCD models a banking system. Customer, Auditor, Clerk and Loan Officer are actors. Counter Transaction, Loan Application, and Audit are use cases — ways in which the actors use the system.</B.BODY
><B.BODY>Additional UCDs might be used to further refine this UCD. For example, you might have a UCD that describes the Loan Application use case in greater detail. You may also have a few Sequence Diagrams that describe the Counter Transaction use case in the form of a number of scenarios: one for a successful transaction and one or more for transactions that are not successful.</B.BODY
><B.BODY>The analyst must choose the appropriate level of detail. You need enough detail to fully capture the business events and system requirements; however, you want to avoid using UCDs for functional decomposition.</B.BODY
>The Vertex, Select, Note and Note connection icons are common to all diagrams. They are described in <RBW-XREF REFID="35957" TYPE="XREF-TEXTCOPY">Chapter 3, Working With Diagrams</RBW-XREF
>.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Use case<RBW-IDXTERM TERM1="use case" TERM2="symbol in UCD"></RBW-IDXTERM
></L.LABEL
><B.BODY>The oval symbol represents a use case: the system or part of the system with which an actor communicates. If necessary, a use case can be further refined in another UCD.</B.BODY
><FA.FIGURE.ANCHOR><DTAG-ERR rbeid="2946"><DTAG-MSG>Document has an empty ('') pathname
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS><RBW-IDXTERM TERM1="Alternative Course of Action, use case property"></RBW-IDXTERM
>Alternative Course of Action.</CX5FX5FBULLET.EMPHASIS
> A free text field in which you can describe the variants on the basic course; for example, the sequence of transactions that occurs in the case of an error.</RBW-PARABODY
> indicates that this use case represents the alternative course of action.</RBW-PARABODY
></LB2.LIST.BULLET.2
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Actor<RBW-IDXTERM TERM1="actor" TERM2="symbol in UCD"></RBW-IDXTERM
></L.LABEL
><FA.FIGURE.ANCHOR>The “stick man” figure represents an entity external to the system — an end user or system — that is interacting with the system.</FA.FIGURE.ANCHOR
> (default) indicates that this actor participates in the use case, but does not initiate it.</RBW-PARABODY
></LB2.LIST.BULLET.2
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Communication association<RBW-IDXTERM TERM1="communication association" TERM2="symbol in UCD"></RBW-IDXTERM
></L.LABEL
><B.BODY>The line and the arrow represent the communication between the actor and the use case. To represent undirected (two&truehy;way) communication, use the line that has no arrowhead:</B.BODY
><B.BODY>This is the blank use case generalization stereotype button. The use case generalization is not further specified.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Uses</SL.SUBLABEL
><B.BODY>Marking a use case generalization with «uses» indicates that the source use case in the generalization includes the behaviour of the target use case.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Extends</SL.SUBLABEL
><B.BODY>Marking a use case generalization with «extends» indicates that an instance of the source use case in the generalization may include behaviour of an instance of the target use case.</B.BODY
><B.BODY>One advantage of doing design work online is that you can check your models using ObjectTeam’s checking utilities. These utilities can help you find errors and inconsistencies in your design, minimizing the risk of expensive design flaws. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Three types of checking</L.LABEL
><B.BODY>ObjectTeam provides three types of checking:</B.BODY
> is done whenever you use the diagram editors. Implicit checking ensures that your diagrams are always syntactically correct by preventing you from creating invalid objects or connections.</RBW-PARABODY
> occurs when you click a Check menu. You can check individual diagrams or ensure that a set of diagrams are complete. Explicit checking is particularly useful for code generation, ensuring that the Class Diagrams (CDs) are complete and correct.</RBW-PARABODY
> is done as part of code generation to minimize errors.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>This chapter describes each type of checking and how to use explicit checking.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customized checking</L.LABEL
><B.BODY>Tcl scripts define all checking ObjectTeam performs. You can implement your own checks by modifying these scripts or by creating your own. For details on customizing checking, see the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><B.BODY>The ObjectTeam environment supports the OMT development method, which prescribes certain low&truehy;level details, such as the following:</B.BODY
><RBW-PARABODY>How these symbols are connected</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>Implicit checking enforces these rules. ObjectTeam monitors your actions while you create or modify a diagram. If you attempt to carry out an action that is inconsistent with the OMT notation, a warning appears in the message area of the editor.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>For example, if you try to make an illegal connection, such as attaching a loop symbol from a class to an association, the editor displays the following message and prevents you from carrying out the action:</B.BODY
><EWM.EXAMPLEW.MONO>No such connector type allowed between these component types.</EWM.EXAMPLEW.MONO
><RBW-PARABODY>When to use each type of diagram</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>These high&truehy;level points are taken care of by the organization of your project into phases and the types of diagrams that are available.</B.BODY
><RBW-PARABODY>Check that Check Local model does check COD.</RBW-PARABODY
></Q.QUERY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Phase affects rules that are checked<RBW-IDXTERM TERM1="phase" TERM2="affect on checking"></RBW-IDXTERM
></L.LABEL
><B.BODY>ObjectTeam provides a set of rules for each command on the Check menu. Which rules are checked when you use a particular Check menu command depends on the current phase. For example, the set of rules for the Local Model command includes the following:</B.BODY
><RBW-PARABODY>A class must have an operation defined for each event that it receives.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>If you are in the Analysis phase, only the first of these rules is checked. If you are in the Object Design phase, both rules are checked.</B.BODY
><B.BODY>This remainder of this section describes each Check menu command briefly. For a complete list of the rules provided for each Check menu command, see the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>. That guide also describes how to customize Check menu commands by:</B.BODY
><RBW-PARABODY>Adding rules to those provided by ObjectTeam</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Check Contents</L.LABEL
><B.BODY>Check Contents checks the semantics of a diagram. Each diagram has a unique set of rules.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Running Check Contents</SL.SUBLABEL
><B.BODY>To select Check Contents from the Browser, you must first select a diagram in the Information area. Selecting Check Contents from the diagram editor checks the entire diagram regardless of whether you have selected objects in it.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Sample rules</SL.SUBLABEL
><B.BODY>For example, Check Contents for the CD includes a rule to verify that all link attribute symbols are connected to associations. Check Contents for the SD includes a rule to verify that each event trace has exactly one initiator.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="17684"></RBW-ANCHOR
>Check Global Model<RBW-IDXTERM TERM1="checking" TERM2="Global Model"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Global Model (Check menu)"></RBW-IDXTERM
></L.LABEL
><B.BODY>Check Global Model checks all classes (and all associated events) in the current system.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Running Check Global Model</SL.SUBLABEL
><B.BODY>To use Check Global Model, you must be at System level in the Browser. It does not matter whether you have selected items in the Information area.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Sample rules</SL.SUBLABEL
><B.BODY>The rules for Check Global Model are the same as the rules for Check Local Model. See the sample rules for Check Local Model.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="21018"></RBW-ANCHOR
>Check Local Model<RBW-IDXTERM TERM1="checking" TERM2="Local Model"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Local Model (Check menu)"></RBW-IDXTERM
></L.LABEL
><B.BODY>Check Local Model checks selected classes or all classes in a selected diagram.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Running Check Local Model</SL.SUBLABEL
><B.BODY>To run Check Local Model from the Browser, you must first select a diagram or CDM. </B.BODY
><RBW-PARABODY>If you have selected a diagram, ObjectTeam checks all classes in that diagram. The events checked depend on which diagram is selected, as shown in the table below.</RBW-PARABODY
>When you run Check Local Model from a diagram, ObjectTeam checks all selected classes; if no classes are selected, it checks all classes. The events checked depend on which diagram is active, as shown in the table below. </B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>STD Events and Event Messages</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Sample rules</SL.SUBLABEL
><B.BODY>For example, Check Local Model includes a rule to check that no class has an attribute with the same name as a received event. It also includes a rule to ensure that special classes (such as enum and typedef) do not receive events.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="13383"></RBW-ANCHOR
><RBW-ANCHOR ID="checking"></RBW-ANCHOR
>Check Use Case Model</L.LABEL
><B.BODY>Check Use Case Model checks all UCDs.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Running Check Use Case Model</SL.SUBLABEL
><B.BODY>To select Check Use Case Model from the Browser, you must first select a UCD in the Information area.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Sample rules</SL.SUBLABEL
><B.BODY>For example, the Check Use Case Model option includes a rule to check that each UCD has exactly one initiating actor and at least one associated SD.</B.BODY
><B.BODY>From your design, you generate source code for an executable in a particular programming language. During code generation, ObjectTeam checks the syntax and semantics of all CDs that it is using. The results are reported in the Monitor window in which the code generator runs. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Check Local Model</L.LABEL
><B.BODY>The checking process is particularly important for code generation, because errors stop the generation process. Warnings do not stop the generation process, but do indicate potential problems in your diagram. To ensure that your diagrams conform to all rules and restrictions, use Check | Local Model to check your diagrams before moving them to the Implementation phase.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</L.LABEL
><B.BODY>For more details on the code generation process, see the <CX5FX5FTITLE>ObjectTeam Code Generation Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for the programming language that you are using.</B.BODY
><B.BODY>During the project, it is important to have an overview of project data. ObjectTeam provides two facilities that enable you to generate various views of that data:</B.BODY
><B.BODY>The Report tool generates reports on data in a particular part of your project. For example, you can run a report on all classes present in a particular diagram, system, or phase. When you run a report, the repository is queried and the output displayed in a Monitor window. You can print the report or save the report data in a file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class Browser</L.LABEL
><B.BODY>The Class Browser provides an overview of all classes and class features in a phase or system, and lets you navigate through the class hierarchy. You can print the information displayed.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="27975" TYPE="XREF-TEXTCOPY">Reporting in ObjectTeam&rbwtab;6–2</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="36951" TYPE="XREF-TEXTCOPY">Using the Class Browser&rbwtab;6–11</RBW-XREF
><B.BODY>ObjectTeam offers a set of standard reports that can be run from the Browser and diagram editors. This section covers only these standard reports. For information on the following topics, refer to the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><RBW-PARABODY>Using reports made in previous versions of ObjectTeam</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Reporting versus document generation</L.LABEL
><B.BODY>The Report tool is ideal for obtaining information on the state of your project on an ad&truehy;hoc basis. If you need formal documentation on a particular part of your project, use the Document Generator instead. This tool is typically used when a phase in a project is finished. For information on the Document Generator, see the <CX5FX5FTITLE>ObjectTeam Document Generation Guide</CX5FX5FTITLE
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Corporate group name, saved group name, project name, system name, corporate group version, saved group version, creator, comments, contents, and reused in. See the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Project name, Configuration version names, project status, and who created the project</CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Project name, Configuration version name, project status, and who created the project</CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Project name, configuration version name, system name, phase name, selected system version, and status</CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Saved group name, corporate group name (if promoted), version, creator, time created, in corporate, comments, contents</CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>CDM name. (A CDM becomes unreferenced if the name of its class is changed directly in the class symbol.)</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>On Items and Properties</CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Base class name, base class type, generalization type, derived class name, derived class type</CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Data flow: From type, from node; Control flow: Flow; Result flow: To node; Update flow: To type</CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>For each use case, the communication associations to or from it and any use case generalizations associated with it</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>On Roles and Users</CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>List of all categories and their classes</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
><RBW-ICONIZE></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Report scope</L.LABEL
><B.BODY>As shown in the previous table, some reports can be called from different windows or from different Browser levels. Where you run a report from determines its scope. </B.BODY
><B.BODY>For example, if you run a Report On Classes within the CD editor, the report includes only those classes in the current diagram. If you run Report On Classes on Phase level in the Browser, the report includes all classes in the current phase.</B.BODY
><B.BODY>Reports can be run from the Browser or from the diagram editors. For a list of all available reports, see <RBW-XREF REFID="27975" TYPE="XREF-TEXTCOPY">Reporting in ObjectTeam</RBW-XREF
><RBW-PARABODY>Report On Components and Properties</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>If you specify a property name, the report includes only those items or components for which the specified property is set. If you do not specify a property name, the report inludes all items or components.</B.BODY
><RBW-PARABODY>Using the control selection boxes in the Monitor window</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>For information on how to make your option settings available to other users, see the discussion of the user environment in the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><RBW-PARABODY>Specify the desired line length and page length, and click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The next time you open a Monitor window and run a report, ObjectTeam uses the new settings. (The new settings do not affect currently open Monitor windows.)</LR.LIST.RESULT
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Line length</SL.SUBLABEL
><B.BODY>Reports are designed to fit the default line length of 132 characters. Specifying a shorter line causes wrapping, which may make the report difficult to read.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to scroll through a report</L.LABEL
><B.BODY>Reports are usually wider and longer than the default Monitor window. To view the entire contents of the report, enlarge the window or use the scroll bars. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to suspend output of a report<RBW-ANCHOR ID="Suspend Output (Options menu)"></RBW-ANCHOR
><RBW-PARABODY>To temporarily stop the output from scrolling in the Monitor window while it is being produced, select Options | Suspend Output. </RBW-PARABODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Sends a SIGTERM signal to the process. The process is aborted through its own handler.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Sends a SIGQUIT signal to the process. The process is aborted through its own handler and a core is dumped.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Sends a SIGKILL signal to the process. The process is aborted by the operating system. No locks on tables or files are removed.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to print your report<RBW-ANCHOR ID="report"></RBW-ANCHOR
><RBW-PARABODY>Specify the Printer Command, and click OK.</RBW-PARABODY
></LN.LIST.NUM
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Alternative</SL.SUBLABEL
><B.BODY>You can also set the default printer from the Browser using Options | Printer Setup | Text, as described in <RBW-XREF REFID="35959" TYPE="XREF-TEXTCOPY">Printing</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to save your report<RBW-ANCHOR ID="Save Output (File menu)"></RBW-ANCHOR
></L.LABEL
><BI.BODY.INTRO>Once the report is finished, you can save it to a file. </BI.BODY.INTRO
> A check mark next to this option directs ObjectTeam to reuse the window. Clearing the check mark locks the window and prevents ObjectTeam from using it for output from any other tool. If you run another report, a separate Monitor window is opened.</RBW-PARABODY
> A check mark next to this option directs ObjectTeam to clear the window before using it for output. Clearing the check mark causes ObjectTeam to concatenate other reports or output to the end of the current contents of the window. </RBW-PARABODY
><B.BODY>The Class Browser allows you to examine the classes in the current phase or system, and their associations, attributes, and operations.</B.BODY
>Only classes that appear in a CD appear in the Class Browser. If a class is defined by a CDM but does not appear in a CD, it does not appear in the Class Browser.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to <RBW-IDXTERM TERM1="Class Browser" TERM2="starting"></RBW-IDXTERM
><RBW-PARABODY>To start the Class Browser in the Browser, or in any Diagram Editor, select Utilities | Class Browser.</RBW-PARABODY
></P.PROCEDURE
><LRS.LIST.RESULT.SINGLE>The Class Browser window appears. If you started the Class Browser on Phase level, all classes in that phase are displayed in the Classes list. If you started the Class Browser on System level or from a diagram editor, only the classes in that system are displayed in the Classes list.</LRS.LIST.RESULT.SINGLE
>How to open a class<RBW-IDXTERM TERM1="Open (File menu)" TERM2="Class Browser"></RBW-IDXTERM
></L.LABEL
><B.BODY>When you start the Class Browser or after you reload classes, only the Classes list contains data. To populate the other list boxes, you open one of the listed classes.</B.BODY
><RBW-PARABODY>To open a class, double&truehy;click a class name in the Classes list. Alternatively, select a class name in the Classes list and select File | Open.</RBW-PARABODY
></P.PROCEDURE
><LRS.LIST.RESULT.SINGLE>The other list boxes are filled with information related to the opened class. </LRS.LIST.RESULT.SINGLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to display inherited information<RBW-IDXTERM TERM1="Flat (View menu in Class Browser)"></RBW-IDXTERM
></L.LABEL
><BI.BODY.INTRO>By default, the Class Browser displays only the attributes and operations of the selected class, and the Associations list displays only the class at the other end of the association. Sometimes, it is useful to see the information classes inherit from their parent classes.</BI.BODY.INTRO
><LR.LIST.RESULT>All features and association entries are prefixed with the class name they belong to. The Associations list displays the classes at both ends of associations.</LR.LIST.RESULT
>If the selected class appears in more than one diagram, ObjectTeam prompts you to select the CD you want to edit.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to <RBW-IDXTERM TERM1="Class Browser" TERM2="updating"></RBW-IDXTERM
>reload classes</L.LABEL
><B.BODY>You can leave the Class Browser open while you work in a Diagram Editor or in the Browser. If you add, delete, or modify classes, you can update the Class Browser by selecting File | Reload Classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section contains the following topics:</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="14379" TYPE="XREF-TEXTCOPY">Printing from the Class Browser&rbwtab;6–21</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="10544" TYPE="XREF-TEXTCOPY">Changing the Class Browser Font&rbwtab;6–22</RBW-XREF
><RBW-IDXTERM TERM1="filter" TERM2="in Class Browser"></RBW-IDXTERM
>You can use filters to restrict the information displayed in the Features list. Filters are helpful when you have many attributes or operations. You set filters using the Filter Features dialog box.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How filters work</L.LABEL
><B.BODY>The Filter Features dialog box lets you set <CX5FX5FTERM>filter elements</CX5FX5FTERM
> that specify which attributes and operations to display in the Features list. You can filter attributes or operations by name, data type, or by the value of any of their item properties. </B.BODY
><B.BODY>When you assign a value to a filter element, only attributes or operations matching the specified value are displayed in the Class Browser. </B.BODY
><B.BODY>For example, if you set the value of the attribute filter element Type to <CX5FX5FINPUT>int</CX5FX5FINPUT
>, only attributes of type integer are displayed in the Class Browser.</B.BODY
><B.BODY>For each filter element, the Filter Features dialog box displays:</B.BODY
>Note that the item properties listed here include both those set explicitly using the Edit Properties dialog box and those set implicitly by entering certain special characters in your diagram.</N2.NOTE.2
>Because you can switch on filters separately for class attributes and class operations, you can enable filters for either one, or both if you prefer.</N2.NOTE.2
><RBW-PARABODY>Select a property name in the list box and click Set Filter Element. Alternatively, double&truehy;click the property name.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The Set Filter Element dialog box appears.</LR.LIST.RESULT
><RBW-PARABODY>Specify a value for the filter.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>For text values, you can use a wildcard string using glob&truehy;style pattern matching. For Boolean values, type a 0 or 1.</LR.LIST.RESULT
><RBW-PARABODY>Click the Enabled check box and click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>This setting provides greater control of the filter set in Step 3. In the Filter Settings list box, the filter now shows Yes in the Enabled field, and the entered value in the Value field. </LR.LIST.RESULT
>To discard any changes you have made to the settings in the Filter Features dialog box, click Reset. This command sets the filters to the values in effect when the dialog box was opened. Click Cancel to reset the values and quit the dialog box.</N2.NOTE.2
><LR.LIST.RESULT>ObjectTeam updates the information in the list boxes in the Class Browser to reflect your filter settings. </LR.LIST.RESULT
><B.BODY>You can navigate your class hierarchy in the Class Browser by opening classes in the Subclasses, Superclasses, Features and Associations lists.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What you can open</L.LABEL
><B.BODY>When you double&truehy;click an entry in the Features or Associations lists, the Class Browser looks for a class name in the entry. For example, classes sometimes appear in attribute entries as attribute data types or in operation entries as parameter data types. If the Class Browser cannot find a class name, it displays a message. The class at the other end of an association is always displayed for associations. </B.BODY
><B.BODY>In Flat view, class names prefix all entries so you can open any entry. </B.BODY
>The search string should use Tcl glob&truehy;style pattern matching. For details on this syntax, see <CX5FX5FTERM>Tcl and the Tk Toolkit</CX5FX5FTERM
> by John Ousterhout.</N2.NOTE.2
><B.BODY>By default, the search is not case sensitive. To make the search case sensitive, click the Case Sensitive check box.</B.BODY
><B.BODY>To apply feature filtering to the search, click the Use Feature Filters check box. Only those features that come through the filter are displayed. For details on setting filters, see <RBW-XREF REFID="41148" TYPE="XREF-TEXTCOPY">Using Filters</RBW-XREF
><RBW-PARABODY>Select Item | Show Properties. </RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The Show Properties dialog box appears. This is the same dialog box that is displayed when you select Item | Show Properties in the Diagram Editors.</LR.LIST.RESULT
><B.BODY>For details on setting and viewing item properties, see <RBW-XREF REFID="22035" TYPE="XREF-TEXTCOPY">Specifying Properties</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to examine the scope of a selected item<RBW-IDXTERM TERM1="scope of item" TERM2="displaying"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Show Scope (Item menu in Class Browser)"></RBW-IDXTERM
>You can view the scope of only one item at a time. So if the entry contains more than one item (for example an association might contain an association name, role name, and class name), the Item Selection dialog box appears, allowing you to choose the item whose scope you want to see. Click the item name and click OK.</N2.NOTE.2
><LR.LIST.RESULT>The Show Scope dialog box appears. </LR.LIST.RESULT
><RBW-PARABODY>Specify the print command in the Printer Command field and click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The next time you print, this print command is used.</LR.LIST.RESULT
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Alternative</SL.SUBLABEL
><B.BODY>You can also set the default printer from the Browser using Options | Printer Setup | Text, as described in <RBW-XREF REFID="35959" TYPE="XREF-TEXTCOPY">Printing</RBW-XREF
><LR.LIST.RESULT>The Class Browser Font dialog box appears. The following figures show both the Windows version (first) and the UNIX version (second).</LR.LIST.RESULT
><B.BODY>The Unified Modeling Language (UML) has been positioned by James Rumbaugh and others as the legitimate successor of the Object Modeling Technique (OMT). </B.BODY
><B.BODY>Previous releases of ObjectTeam supported OMT and future releases of ObjectTeam will support UML. To support our customers during the transition from OMT to UML, the current release of ObjectTeam supports both.</B.BODY
> provides the menu items and Tcl code required to create and use diagrams supported by the OMT methodology. Therefore, this module must be active if you want to work with ObjectTeam according to this methodology.</B.BODY
><B.BODY>You can check if a module is active on a particular Browser level by selecting Utilities | Show Active Modules on that level.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>These diagrams replace some of the functionality represented by the CCD and MGD. Although CODs remain available even if you choose to use OMT notation, do NOT use both CODs and CCDs in the same project.</CELLBODY
><B.BODY>You can switch from UML look to OMT look, or vice versa, using the commands Options | OMT Look and Options | UML Look in the diagram editors.</B.BODY
>The module OMT does not need to be active for switching looks.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Future support for OMT</L.LABEL
><BI.BODY.INTRO>If you choose OMT in the current release, be aware that you can lose information when you upgrade to a future release of ObjectTeam:</BI.BODY.INTRO
><RBW-PARABODY>The Class, Sequence, State, and Use Case Diagrams are also supported for UML. Information specified in these diagrams will be preserved during future ObjectTeam upgrades.</RBW-PARABODY
><RBW-PARABODY>The Class Communication, Data Flow, and Message Generalization diagrams are not supported for UML. Information specified in these diagrams will be lost during future ObjectTeam upgrades. </RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="25359"></RBW-ANCHOR
>Relationships Among Diagrams</L.LABEL
><B.BODY>In ObjectTeam, the components in one diagram are often related to the components in another. For example, an actor in a UCD is a class in a CD. This has two consequences for your work in ObjectTeam:</B.BODY
> ObjectTeam provides special navigation paths that allow you to move from a component in one diagram to another related diagram. See <RBW-XREF REFID="33913" TYPE="XREF-TEXTCOPY">Navigating Between Diagrams on page 3–7</RBW-XREF
> The following table shows the semantic equivalence of diagram follows. The Check utility ensures that your ObjectTeam model respects these semantics. For a complete list of the checks performed for each diagram, see the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><B.BODY>The Class Diagram supports UML and OMT notation. This section describes the diagram symbols used when you select OMT notation using Options | Diagram.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Control panel</L.LABEL
><B.BODY>The following table shows the OMT symbols as they appear in the control panel of the Class Diagram.</B.BODY
>The bold names indicate the symbols that are unique to OMT. This section describes only these OMT symbols. The remaining symbols are the same in OMT and UML and are described in <RBW-XREF REFID="19294" TYPE="XREF-TEXTCOPY">Class Diagram on page 4–3</RBW-XREF
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY><CX5FX5FBULLET.EMPHASIS>End many association</CX5FX5FBULLET.EMPHASIS
></CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Link attribute box</L.LABEL
><B.BODY>In the current release of ObjectTeam, the link attribute box is not available anymore, neither in OMT, nor in UML notation. You can use an association as class instead to model the same situation </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See <RBW-XREF REFID="27609" TYPE="XREF-TEXTCOPY">Association class connector on page 4–11</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Container class<RBW-IDXTERM TERM1="container class" TERM2="symbol in CAD"></RBW-IDXTERM
><B.BODY>In the current release of ObjectTeam, the container class is not available anymore, neither in OMT, nor in UML notation. You can use a regular class instead to model a container class.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See <RBW-XREF REFID="39851" TYPE="XREF-TEXTCOPY">Class on page 4–4</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Association class connector</L.LABEL
><BI.BODY.INTRO>Association class connectors are similar in OMT and UML. These are the only differences:</BI.BODY.INTRO
><RBW-PARABODY>In OMT, an association class connector can connect either an attribute or class to an association. In UML, an association class connector connects a class to an association.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>For more information, see <RBW-XREF REFID="27609" TYPE="XREF-TEXTCOPY">Association class connector on page 4–11</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="26078"></RBW-ANCHOR
>Generalization</L.LABEL
><B.BODY>Semantically, generalizations are the same in OMT and UML. The only difference is the notation.</B.BODY
><B.BODY>In UML, the multiplicity of the association is always indicated by a multiplicity specification that appears above the association connector.</B.BODY
><B.BODY>In OMT, you can add a multiplicity specification after adding the association. For example, to indicate a multiplicity of 2 or more, add the following multiplicity specification to a many association: 2+.</B.BODY
><B.BODY>For more information, see <RBW-XREF REFID="19961" TYPE="XREF-TEXTCOPY">Associations on page 4–7</RBW-XREF
><B.BODY>The Class Communication Diagram (CCD) is not a standard OMT diagram. It is an ObjectTeam diagram used to support OMT. This diagram is added to ObjectTeam when you activate the omtdgms module, as described in the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
>Information specified in the CCD will be lost during future ObjectTeam upgrades.</W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose</L.LABEL
><B.BODY>You<RBW-IDXTERM TERM1="Class Communication Diagram"></RBW-IDXTERM
> use CCDs to focus on the interaction and communication between classes and to identify the boundaries of the system. The diagrams show the communication between classes or groups of classes.</B.BODY
><B.BODY>In a CCD, the communication patterns between classes are modeled by grouping the classes into subjects. The patterns between the individual classes of the subject are modeled in separate diagrams. You can use the CCD to generalize a number of communication sequences. CCDs are the class&truehy;level equivalent of SDs. They are similar to the Event Flow Diagrams in the OMT book.</B.BODY
><B.BODY>When drawing a CCD, the following points are of interest:</B.BODY
><B.BODY>This section describes the symbols used in the CCD. The following illustration shows the symbols as they appear in the diagram Control Panel:</B.BODY
>The Vertex, Select, Note, and Note connector symbols are common to all diagrams. They are described in <RBW-XREF REFID="35957" TYPE="XREF-TEXTCOPY">Chapter 3, Working With Diagrams</RBW-XREF
>.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class<RBW-IDXTERM TERM1="class" TERM2="symbol in CCD"></RBW-IDXTERM
></L.LABEL
><B.BODY>A class is a group of objects with similar properties (attributes), common behavior (operations), common relationships to other objects, and common semantics. Classes are arranged into hierarchies. They share common structure and behavior and are associated with other classes. You can distinguish abstract classes from concrete classes. An abstract class has no direct instances but its descendant classes do.</B.BODY
><B.BODY>Objects in a class have the same attributes and behavior patterns. Most objects distinguish themselves through differences in their attribute values and relationships to other objects. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Decomposing classes</SL.SUBLABEL
><B.BODY>To specify the internal communication of a class, actor, or subject, you break down that component into smaller units in a CCD. You can continue this process of breaking down classes, actors, or subjects until you reach a level on which further decomposition seems impossible or meaningless.<RBW-IDXTERM TERM1="Class Communication Diagram" TERM2="decomposition of"></RBW-IDXTERM
></B.BODY
><B.BODY>To decompose an actor, class, or subject, open one of these diagram components. The editor window clears and loads a new CCD that contains at least the opened component. You can now draw a CCD for the opened component.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class reference<RBW-IDXTERM TERM1="class reference" TERM2="symbol in CCD"></RBW-IDXTERM
><RBW-IDXTERM TERM1="class" TERM2="reference to existing"></RBW-IDXTERM
></L.LABEL
><BI.BODY.INTRO>A class reference represents any class that exists in another CCD, whether in the same system or a different one.</BI.BODY.INTRO
>Container class<RBW-IDXTERM TERM1="container class" TERM2="symbol in CCD"></RBW-IDXTERM
></L.LABEL
><B.BODY>A container class implements general purpose data structures. It refers to a possible actual implementation of the class. The container class refers to the organization or structure of the data so that algorithms can use it. These data structures are generally part of the library that comes with an object oriented programming language. A general purpose data structure is an instance of a container class. Possible data structures are sets, bags, dynamic arrays, lists, queues, stacks, dictionaries, associations, and trees. Container classes serve as a framework for organizing collections of other objects.</B.BODY
>Actor<RBW-IDXTERM TERM1="actor" TERM2="symbol in CCD"></RBW-IDXTERM
></L.LABEL
><B.BODY>An actor is a system boundary. It represents the interaction of the system with individuals or with another system. The actor is a kind of initiator. This initiator indicates that information or some other kind of response is required from the system.</B.BODY
><B.BODY>A subject is a group of classes that belong to the same CAD. So, a subject in a CCD represents a CAD. It can also represent a whole separate system. For large projects, it is useful to define all the subjects as separate systems.</B.BODY
><B.BODY><RBW-IDXTERM TERM1="system" TERM2="creating from CCD"></RBW-IDXTERM
>When you open a subject with scope phase, you can create a new system. If you choose to do so, a new empty CCD is also created in the new system. The name of the new system is the name of the opened subject.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Communication message<RBW-IDXTERM TERM1="communication message" TERM2="symbol in CCD"></RBW-IDXTERM
><RBW-IDXTERM TERM1="message" TERM2="symbol in CCD"></RBW-IDXTERM
></L.LABEL
><B.BODY>A communication message is a connector between classes, subjects and actors. It calls the operations that the classes contain, but does not represent the actions themselves. It tells a class to do what it was designed to do.</B.BODY
><B.BODY>The Data Flow Diagram (DFD) is an OMT diagram that is added to ObjectTeam when you activate the omtdgms module, as described in the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
>Information specified in the DFD will be lost during future ObjectTeam upgrades.</W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose</L.LABEL
><B.BODY>In OMT, you use DFDs to model what happens with data. You model the system as a network of processes that transform and exchange data. </B.BODY
><B.BODY>The DFDs show the flow of data values from their sources in objects through the processes that transform them to their destination in other objects. Values can include input values, output values, and internal data stores. Control information is only shown in the form of control flows. </B.BODY
><B.BODY>The following table lists the important elements of DFDs:</B.BODY
><RBW-PARABODY>You cannot assign the same data to two output flows from the same process. If a process produces more than one data flow, these flows are mutually exclusive. </RBW-PARABODY
>To specify what a high&truehy;level process does, it down into smaller units in more DFDs. A high&truehy;level process is an entire DFD. Each high&truehy;level process is decomposed into other processes with data flows and data stores. Each decomposition is a DFD in itself. You can continue to break down processes until you reach a level on which further decomposition seems impossible or meaningless. </B.BODY
><B.BODY>The data flows of the opened process are connected in the new diagram to the process related to the opened process. Vertices, and the flows and objects connected to them, are transferred with the flows that are connected to the decomposed process.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example DFD</L.LABEL
><BI.BODY.INTRO>The following illustration shows a sample DFD:</BI.BODY.INTRO
><B.BODY>This section describes the symbols used in the DFD. The following illustration shows the symbols as they appear in the diagram control panel:</B.BODY
>The Vertex, Select, Note and, Note connector symbols are common to all diagrams. They are described in <RBW-XREF REFID="35957" TYPE="XREF-TEXTCOPY">Chapter 3, Working With Diagrams</RBW-XREF
>.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Data process<RBW-IDXTERM TERM1="data process" TERM2="symbol in DFD"></RBW-IDXTERM
><RBW-IDXTERM TERM1="process" TERM2="symbol in DFD"></RBW-IDXTERM
></L.LABEL
><B.BODY>A data process transforms data values. </B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Process containing nonfunctional components such as data stores or external objects that cause side effects</CELLBODY
><RBW-PARABODY>Generation of new information </RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>If you open a process, you can either create a new DFD or open an existing DFD in which the process is specified.</B.BODY
><B.BODY>The data flows of the opened process are connected in the new diagram to the process with the name of the opened process. Vertices, and the flows and objects connected to them, are transferred with the flows that are connected to the decomposed process.</B.BODY
><B.BODY>If a data process has a decomposition at a lower level, an asterisk is placed inside the ellipse. The data process can be opened only if it has a name.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Data store<RBW-IDXTERM TERM1="data store" TERM2="symbol in DFD"></RBW-IDXTERM
></L.LABEL
><B.BODY>A data store stores data passively for later access. A data store responds to requests to store and access data. It does not generate any operations on its own. A data store allows values to be accessed in an order different from the order in which they were generated. </B.BODY
><B.BODY>Input flows indicate information or operations that modify the stored data such as adding or deleting elements or changing values. Output flows indicate information retrieved from the store; this information can be an entire value or a component of a value.</B.BODY
>Actor<RBW-IDXTERM TERM1="actor" TERM2="symbol in DFD"></RBW-IDXTERM
></L.LABEL
><B.BODY>An actor produces and consumes data, driving the DFD. Actors lie on the boundary of the diagram; they terminate the flow of data as sources and sinks of data. They are also known as terminators. Data flows between an actor and a diagram are inputs to and outputs of the diagram. The system interacts with people through the actor.</B.BODY
>Anchor<RBW-IDXTERM TERM1="anchor" TERM2="symbol in DFD"></RBW-IDXTERM
></L.LABEL
><B.BODY>A DFD anchor provides a start or end point. In decomposition diagrams, anchors represent the nodes connected to the decomposed process in the higher level diagram.</B.BODY
>Data flow<RBW-IDXTERM TERM1="data flow" TERM2="symbol in DFD"></RBW-IDXTERM
></L.LABEL
><B.BODY>A data flow moves data between processes or between processes and data stores. As such, it represents a data value at some point within a computation and an intermediate value within a computation if the flow is internal to the diagram. This value is not changed. </B.BODY
><B.BODY>The names of input and output flows can indicate their roles in the computation or the type of the value they move. Data names are preferably nouns. The name of a typical piece of data, the data aspect, is written alongside the arrow.</B.BODY
><B.BODY>See also <RBW-XREF REFID="20192" TYPE="XREF-TEXTCOPY">Flow names and inheritance</RBW-XREF
> below.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Result flow<RBW-IDXTERM TERM1="result flow" TERM2="symbol in DFD"></RBW-IDXTERM
></L.LABEL
><B.BODY>A result flow is a data flow that generates an object used as the target of another operation. The value of the flow is subsequently treated as an object, usually a data store.</B.BODY
><B.BODY>See also <RBW-XREF REFID="20192" TYPE="XREF-TEXTCOPY">Flow names and inheritance</RBW-XREF
> below.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Control flow<RBW-IDXTERM TERM1="control flow" TERM2="symbol in DFD"></RBW-IDXTERM
></L.LABEL
><B.BODY>A control flow is a signal that carries out a command or indicates that something has occurred. A control flow occurs at a discrete point in time. The arrow indicates the direction of the control flow. The name of the event is written beside the arrow.</B.BODY
><B.BODY>Control flows can correspond to messages in CCDs or events in STDs; however, because they duplicate information in the DFD, use them sparingly.</B.BODY
><B.BODY>See also <RBW-XREF REFID="20192" TYPE="XREF-TEXTCOPY">Flow names and inheritance</RBW-XREF
> below.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Update flow<RBW-IDXTERM TERM1="update flow" TERM2="symbol in DFD"></RBW-IDXTERM
></L.LABEL
><B.BODY>Update (or bidirectional) flows are used to indicate an update of a data store, that is, a read, change, and store operation on a data flow.</B.BODY
><B.BODY>See also <RBW-XREF REFID="20192" TYPE="XREF-TEXTCOPY">Flow names and inheritance</RBW-XREF
> below.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="20192"></RBW-ANCHOR
>Flow names and inheritance</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="flow" TERM2="symbol in DFD"></RBW-IDXTERM
>Flows in DFDs must be named. However, flows can inherit the names of the objects they are connected to. The table below shows the rules for inheritance of names. These rules are applied in the order shown, until nothing more can be inherited. In some situations, the flow’s inherited name causes an error when a Check command is carried out. The result of the inheritance is confusing in the diagram.</B.BODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Diverging flows without names inherit the name of an incoming flow with a name. If the incoming flow has several names, each diverging flow inherits all of them.</CELLBODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Converging flows without names inherit the name of an outgoing flow with a name. If the outgoing flow has several names, each converging flow inherits all of them.</CELLBODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Flows connected to a data store, control store, message queue, message box, event queue, or event flag inherit the name of that node.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
><B.BODY><RBW-IDXTERM TERM1="composite flow, in DFD"></RBW-IDXTERM
><RBW-IDXTERM TERM1="diverging flow, in DFD"></RBW-IDXTERM
><RBW-IDXTERM TERM1="converging flow, in DFD"></RBW-IDXTERM
><RBW-IDXTERM TERM1="split flow, in DFD"></RBW-IDXTERM
><RBW-IDXTERM TERM1="merging flow, in DFD"></RBW-IDXTERM
>A forked (converging or diverging) data flow is either a split or merging data flow, or a composite data flow. A composite data flow has one name for each branch. A composite flow can split into the original flows again. A split or a merging data flow has only one name.</B.BODY
><B.BODY>The name of the flow is taken as type name if no data type is specified.</B.BODY
><B.BODY>The Message Generalization Diagram (MGD) is an OMT diagram that is added to ObjectTeam when you activate the omtdgms module, as described in the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
>A communication message in a CCD or a communication association in a UCD can represent more than one message. You use the MGD to define the messages that make up the communication message or communication association. The MGD focuses on a hierarchical breakdown of a complex message in the CCD or UCD.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example MGD</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="communication message" TERM2="decomposition in MGD"></RBW-IDXTERM
>A message that represents a number of messages is a <CX5FX5FTERM>generalized message</CX5FX5FTERM
>. In the MGD, the generalized message appears at the top of the hierarchy. Messages at the bottom of the hierarchy represent the specific messages. </B.BODY
><B.BODY>In the following figure the set of messages that are generated as a result of choosing an option on a form are grouped into the general message RentalFormCommands. The hierarchy in this example has two levels; you can create hierarchies with as many levels as necessary.</B.BODY
><B.BODY>This section describes the symbols used in the MGD. The following illustration shows the symbols as they appear in the diagram Control Panel:</B.BODY
>The Vertex, Select, Note and, Note connector symbols are common to all diagrams. They are described in <RBW-XREF REFID="35957" TYPE="XREF-TEXTCOPY">Chapter 3, Working With Diagrams</RBW-XREF
>.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Message definition<RBW-IDXTERM TERM1="message" TERM2="symbol in MGD"></RBW-IDXTERM
></L.LABEL
><B.BODY>A Message Definition describes a message or part of a composite message.</B.BODY
><B.BODY>Each message definition can be a combination of other messages. Such messages are indicated by more message definition symbols and the message generalization connector that joins them to the top message definition. </B.BODY
><B.BODY>You can define the message definition in a separate MGD by using File | Open.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Message generalization connector<RBW-IDXTERM TERM1="message generalization connector" TERM2="symbol in MGD"></RBW-IDXTERM
></L.LABEL
><B.BODY>A Message Generalization Connector establishes the relationship that messages and parts of messages have with each other. The message definition, drawn on top, acts as top message. Its constituent messages or parts of the message are placed underneath.</B.BODY
>In OMT, the Sequence Diagram (SD) is called an Event Trace Diagram (ETD). In ObjectTeam, the name Sequence Diagram (SD) is used for both UML and OMT.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</L.LABEL
><B.BODY>For more information about this diagram, see <RBW-XREF REFID="14788" TYPE="XREF-TEXTCOPY">Sequence Diagram (Event Trace Diagram)</RBW-XREF
>Send events, state attributes, concurrent states, history states, and complex transitions are not used in OMT. These UML symbols remain available in the State Transition Diagram even when you choose OMT notation.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>OMT notation</L.LABEL
><B.BODY>The following figure shows the State Transition Diagram with OMT notation selected:</B.BODY
><B.BODY>The following table shows the OMT navigation options that appear by default. You can customize these options, as described in the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Navigation options</L.LABEL
><B.BODY>Each navigation option creates and opens a new diagram or opens an existing diagram.</B.BODY
>The CD, COD, SD, STD, and UCD are described in Chapter 4, Exploring Each Diagram. The CCD, DFD, MGD and the navigation options to and from these diagrams are described in Appendix A, OMT Support.</N.NOTE
><ENTRY COLNAME="5" VALIGN="TOP" MOREROWS="0"><CELLBODY>subject_name (assign sd_name) <CX5FX5FEMPHASIS>in current system if no system has been created</CX5FX5FEMPHASIS
></CELLBODY
><CELLBODY>subject_name: sd_name <CX5FX5FEMPHASIS>in system subject_name if system has been created </CX5FX5FEMPHASIS
></CELLBODY
><CELLBODY>(See also Create System below)</CELLBODY
>: (not mentioned in the table but displayed in the Select Operation dialog box). See <RBW-XREF REFID="30952" TYPE="XREF-TEXTCOPY">Systems you can navigate to</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="34996"></RBW-ANCHOR
>Diagram Name </L.LABEL
><B.BODY>The diagram names are generated from the component name from which the navigation was started. </B.BODY
><RBW-PARABODY>When you create a COD, or SD, the name of the component is assigned to the qualifier, and a dialog box appears in which you can assign the diagram name.</RBW-PARABODY
><RBW-PARABODY>When you create an STD, the name of the component is assigned to the qualifier. If the navigation process was started from a CD or SD, the STD diagram name is given the name top</RBW-PARABODY
></LB2.LIST.BULLET.2
><B.BODY>The names of the new diagrams (and systems) are generated from the component name. These names remain linked to the original component. If you change the name of the component in the original diagram, ObjectTeam changes the name of the generated diagram (or system).</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="30952"></RBW-ANCHOR
>Systems you can navigate to</L.LABEL
><B.BODY>The System column in the Select Operation dialog box displays the name of the system in which the create or open action will take place. </B.BODY
><B.BODY>If the item you are navigating from is already defined in that system, an asterisk is placed in front of the system name.</B.BODY
><B.BODY>When selecting an open or create operation, you can determine in which system the operation will be carried out by checking the value of the system field:</B.BODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>The item is defined in the current system. The operation will be carried out in this system.</CELLBODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>The item is defined in another system. The operation will be carried out in the other system.</CELLBODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>The item is defined in the current system but is referenced in another system. The operation will be carried out in the other system.</CELLBODY
><RBW-PARABODY>Label identifies the internal name of the label associated with a component. Most labels have a name; many also have additional labels as well.</RBW-PARABODY
><RBW-PARABODY>Item Type identifies the type of the item associated with the symbol or label. If no item type is listed, the element is not an item in the repository.</RBW-PARABODY
><RBW-PARABODY>Item Scope lists all valid scopes for the item associated with the symbol or label; the initial scope is indicated in bold. A scope Q indicates that the item is a qualified item; its scope is always the same as its owner item.</RBW-PARABODY
><B.BODY>This manual describes how to use versions, groups, and access control. It also describes how to save Browser settings and how to determine where generated files are placed in the file system.</B.BODY
><B.BODY>These features are particularly useful to the ObjectTeam administrator. Depending on the size and complexity of their projects, project leaders and project members might also find these features useful.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisites</L.LABEL
><B.BODY>This manual assumes that you are familiar with the following products and concepts:</B.BODY
><RBW-PARABODY>The Unified Modeling Language (UML) for Object&truehy;Oriented Development, as developed by Grady Booch, Ivar Jacobson, and James Rumbaugh.</RBW-PARABODY
><B.BODY>ObjectTeam allows you to create versions of all the objects in this hierarchy, with the exception of the project object. Each version of a parent object points to a version of each of its child objects. For example, each version of a phase object points to a version of each of its child system objects.</B.BODY
><B.BODY>Through the links between versions, a version of a configuration effectively points to a version of every object in it.</B.BODY
><B.BODY>Each version has a status that indicates whether it can be edited (working) or not (frozen). Only frozen versions can be shared by multiple configurations.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Access control</L.LABEL
><B.BODY>This chapter focuses on how to use versions and configurations. However, it is important to note that access to object versions is also controlled through the access control mechanism described in <RBW-XREF REFID="21532" TYPE="XREF-TEXTCOPY">Chapter 5, Access Control</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="38448" TYPE="XREF-TEXTCOPY">Working With Versions and Configurations&rbwtab;1–14</RBW-XREF
><B.BODY><RBW-IDXTERM TERM1="object" TERM2="that have versions"></RBW-IDXTERM
>The following types of objects are under version control. When you create, delete, or modify these types of objects, you always create, delete, or modify a version of the object.</B.BODY
><RBW-PARABODY>Documents and document objects, such as document structure matrixes and file sections (see the <CX5FX5FTITLE>ObjectTeam Document Generation Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for more information)</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Items</SL.SUBLABEL
><B.BODY>You cannot create versions of items. Item values are saved with system versions or file versions, depending on the item scope. See <RBW-XREF REFID="40295" TYPE="XREF-TEXTCOPY">Item Generations and Property Values</RBW-XREF
> for more information.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Hierarchy of object versions</L.LABEL
><B.BODY>The ObjectTeam project hierarchy defines the content of each type of object.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Each configuration version contains one or more phase versions, as well as one or more customization file versions.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Each phase version contains one or more system versions, as well as one or more customization file versions.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Each system version contains one or more file versions and one or more group versions, as well as one or more customization file versions.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>An object version in this state can be edited. Its component object versions can be working or frozen. A working object version must be in exactly one configuration version.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>An object version in this state cannot be edited. Its component object versions are also frozen. A frozen object version can be in one or more configuration versions. </CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>An object version in this state is frozen and is not in any configuration version. Background versions are removed from the repository and stored in the file system. </CELLBODY
><RBW-PARABODY>The version number for the first object version is 1. The version number for any other object version is derived from the version number of the frozen object version used to create it.</RBW-PARABODY
>Once you have added the frozen version to your configuration, you can create a new working version of the frozen object version. You can then modify the new version.</T2.TIP.2
>If you create an object version in your configuration and the version number is not what you expect, there may be an existing object with the same name that is unselected. Use the Version Browser to examine the version hierarchy. For more details, see <RBW-XREF REFID="34596" TYPE="XREF-TEXTCOPY">Version Browser</RBW-XREF
>.</W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Removing object versions</L.LABEL
><B.BODY>You remove object versions from your configuration version in one of two ways:</B.BODY
><RBW-PARABODY>Deselect a frozen object version.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>One or more configurations</L.LABEL
><B.BODY>A project can have one or more configurations. Most projects, even projects being worked on by a team of developers, use only one configuration. Your project only needs multiple configurations if you need to maintain separate, parallel streams of development.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>One configuration</L.LABEL
><B.BODY>Large projects being worked on by multiple developers often need only one configuration. Most of Cayenne’s development projects use a single configuration. In this case, developers generally work in their own systems. If developers happen to work on the same system, they are locked out of files currently in use by another developer, preventing potential conflicts.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Multiple configurations</L.LABEL
><B.BODY>Multiple configurations in a project allow you to maintain separate, parallel streams of development. You must then merge the separate branches to create an integrated version model. Multiple configurations are particularly useful in the following situations:</B.BODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Shielded development areas.</CX5FX5FBULLET.EMPHASIS
> With a single configuration, the work of every developer potentially impacts the work of every other developer. Multiple configurations ensure that the changes made by one developer (or group of developers) does not affect the work of another developer (or group of developers) until you choose to merge the configurations.</RBW-PARABODY
> If you need to maintain multiple versions of your model simultaneously, you can do so using multiple configurations. For example, you can have a configuration for Release X and a second configuration for Release X+1. You now can use one configuration for critical corrections to the older version of the model while you use the second configuration to develop the new version of the model.</RBW-PARABODY
>, describes how to use multiple configurations. It also describes how to merge the configurations to create an integrated version of the model.</B.BODY
>Items contain important model information, such as property values. You cannot create versions of items. Instead, ObjectTeam creates and handles item generations for you.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Item scope determines where its properties are stored</L.LABEL
><B.BODY>The scope of an item determines where the properties associated with that item are stored.</B.BODY
><RBW-PARABODY>Properties of items with scope system or phaseDef are stored with the system version.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>An etd_event item cannot have scope file; therefore, it is always stored with a system version. The etd_event item contains, for example, the value of the Free Text property for the event connector in the Sequence Diagram (SD). When you freeze a system version, ObjectTeam freezes the associated etd_event item generations, including the value of the Free Text property for the event connector.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Not all properties are connected to Items</L.LABEL
><B.BODY>Not all properties are associated with items. Many objects in the repository can have associated properties. These properties are stored with the object.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The Free Text property for a diagram is associated with the file version of the diagram. When you freeze a diagram file version, ObjectTeam freezes its associated properties, including the value of the Free Text property for the diagram.</B.BODY
><RBW-PARABODY>When you freeze a system version, ObjectTeam freezes the system version and all of its child file versions. Freezing a system version freezes all the property values in that system version, including all the property values in all the file versions in that system version.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>SavedGroups</SL.SUBLABEL
><B.BODY>If you are using corporate groups, you can create a group that contains the files and items that you want to save called a SavedGroup. The SavedGroup is a snapshot of the current state of all files and items in the group. See <RBW-XREF REFID="11810" TYPE="XREF-TEXTCOPY">Chapter 4, Using Groups</RBW-XREF
>Creating a group version is not the same as creating a SavedGroup. A group version contains only the rules by which ObjectTeam determines the contents of the group. It does not contain the files and items in the group.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Configurations should not share file versions</L.LABEL
>Configurations should share system versions rather than file versions. If the configurations share file versions, the property values visible from the <CX5FX5FEMPHASIS>shared</CX5FX5FEMPHASIS
> file version might be different in each configuration:</B.BODY
><B.BODY>The Browser displays object versions in the context of the project hierarchy. Thus, in the Browser, you can examine all object versions that are currently selected in your project.</B.BODY
><B.BODY>The Version Browser displays all versions of an object, regardless of whether or not they are currently selected in your project.</B.BODY
><RBW-PARABODY>The root node represents the object. It displays the name of the object and the number of versions of that object that exist.</RBW-PARABODY
><RBW-PARABODY>Each of the other nodes represents an object version. Each displays the version identifier and the creator’s user name. The border style indicates version status:</RBW-PARABODY
><RBW-PARABODY>The straight arrows show the version hierarchy. In the previous illustration, myconfig.3 is derived from myconfig.2 is derived from main.1. Both main2. and myconfig.2 are derived from main.1.</RBW-PARABODY
><RBW-PARABODY>The curved lines represent Merge Links, which are only used during merge. A Merge Link points from a source version to a target version. It indicates that ObjectTeam should use the target version rather than the source version. See <RBW-XREF REFID="11562" TYPE="XREF-TEXTCOPY">Working With Merge Links</RBW-XREF
><RBW-PARABODY>To display information about a different object, drag a new object from the Browser into the Version Browser. (In Windows, use the left mouse button. In Unix, use the middle mouse button.)</RBW-PARABODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>First selected node when one or two nodes are selected; all selected nodes when more than two nodes are selected</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Second selected node when two nodes are selected; Secondary Selection is useful when you are selecting the source and target versions for merge</CELLBODY
><RBW-PARABODY>To print the display area of the Version Browser, select File | Print View.</RBW-PARABODY
></P.PROCEDURE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Version menu commands</L.LABEL
><B.BODY>Most of the commands on the Version menu in the Version Browser are also in the Version menu in the Browser. For descriptions of these commands, see <RBW-XREF REFID="38448" TYPE="XREF-TEXTCOPY">Working With Versions and Configurations</RBW-XREF
>Working With Versions and Configurations</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="11036"></RBW-ANCHOR
>Version commands</L.LABEL
><B.BODY>Most of the commands for working with object versions are on the Version menu of both the Version Browser and the Browser. The following table provides brief descriptions of each command. <RBW-IDXTERM TERM1="configuration" TERM2="commands, list of"></RBW-IDXTERM
><RBW-IDXTERM TERM1="version" TERM2="commands, list of"></RBW-IDXTERM
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>The first version of an object is created when you create the object. Use New to create subsequent versions of an object.</CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Deletes leaf object versions, which are object versions that have not been used to create new object versions.</CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Changes the status of an object version from working to frozen. A frozen object version cannot be edited.</CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Changes the status of an object version from frozen to working. A working object version can be edited.</CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Adds to a configuration a different version of an object that is already in the configuration.</CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Changes the status of links between parent object versions and child object versions. (<CX5FX5FEMPHASIS>Note:</CX5FX5FEMPHASIS
> This command is on the File menu, not the Version menu.)</CELLBODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>For file versions, compares two versions of the same file, listing their differences.</CELLBODY
> For configuration, phase, or system versions, merges two versions, as described in <RBW-XREF REFID="14035" TYPE="XREF-TEXTCOPY">Chapter 2, Parallel Development</RBW-XREF
>In most cases, applying a version&truehy;related command to a parent object also effects its child objects. For example, freezing a phase version also freezes its system versions. The following table shows the parent&truehy;child relationships between object versions:</B.BODY
>Working with many object versions at once can cause system resource problems. If you are applying a version&truehy;related command (see <RBW-XREF REFID="11036" TYPE="XREF-TEXTCOPY">Version commands</RBW-XREF
>) to an object version that has more than 50 child object versions, perform the action on the child objects first, then on the parent object.</W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Merge commands</L.LABEL
><B.BODY>The following commands, which also appear on the Version menu, are used only for merge. They are described in <RBW-XREF REFID="14035" TYPE="XREF-TEXTCOPY">Chapter 2, Parallel Development</RBW-XREF
> For file versions, compares two versions of the same file, as described in <RBW-XREF REFID="19986" TYPE="XREF-TEXTCOPY">Comparing File Versions</RBW-XREF
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Deletes the Merge Link between two versions. </CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
><RBW-ICONIZE></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Document commands</L.LABEL
><B.BODY>The following commands, which also appear on the Version menu, are available only at the Document level. They are described in <CX5FX5FTITLE>ObjectTeam Document Generation Guide</CX5FX5FTITLE
>You can create a new version from the working version of an object. However, ObjectTeam first freezes the working version, and then creates the new version from the frozen version.</N2.NOTE.2
><RBW-PARABODY>The parent object version, if any, must be working. </RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>For example, if a phase version is frozen, you cannot create a new version of a system in that phase. You must create a new phase version (or unfreeze the phase version): you can then create a new version of a system in that working phase version.</LT.LIST.TEXT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Results</L.LABEL
><B.BODY>When you create a new version of an existing object:</B.BODY
><RBW-PARABODY>The new object version has a status of working and is identical to the frozen version used to create it. <RBW-IDXTERM TERM1="working version" TERM2="creating with New"></RBW-IDXTERM
><RBW-PARABODY>The frozen object version is removed from your configuration version. If it is not used in any other configuration version, it is removed from the repository and given the status backGround.<RBW-IDXTERM TERM1="frozen version" TERM2="creating with New"></RBW-IDXTERM
><RBW-IDXTERM TERM1="backGround version" TERM2="creating with New"></RBW-IDXTERM
></RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Effect on parent and child versions</L.LABEL
><B.BODY>Creating a new version of an object affects its parent and child versions as follows:</B.BODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Effect on parent.</CX5FX5FBULLET.EMPHASIS
> If the parent object version has a dynamicFrozen link to the child object, the link is updated. (See <RBW-XREF REFID="19213" TYPE="XREF-TEXTCOPY">Changing Link Status</RBW-XREF
>.)<RBW-IDXTERM TERM1="dynamicFrozen link" TERM2="updated by New"></RBW-IDXTERM
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Effect on child.</CX5FX5FBULLET.EMPHASIS
> Creating a new version of a parent object has no effect on the child object versions. The frozen and new versions of the parent object both point to the same frozen versions of the child objects.</RBW-PARABODY
>If you create a new parent object version based on a working version, ObjectTeam freezes the parent object version, which also freezes its child object versions.</N2.NOTE.2
><RBW-PARABODY>Select Version | New.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam creates a new version of the object, making it the working version of the object. The working version of the object is added to your configuration. The frozen version is removed from your configuration.</LR.LIST.RESULT
>If you create an object version in your configuration and the version number is not what you expect, there may be an existing object with the same name that is deselected. Use the Version Browser to examine the version hierarchy. For more details, see <RBW-XREF REFID="34596" TYPE="XREF-TEXTCOPY">Version Browser</RBW-XREF
> deletes the selected object version. If you attempt to delete a non&truehy;leaf object version, ObjectTeam displays a message.<RBW-IDXTERM TERM1="Delete (File menu)"></RBW-IDXTERM
> deletes the selected object version, if it is the only leaf object version. If it is not, ObjectTeam displays a dialog box that lists all leaf object versions of the selected object. You can select and delete one or more of the leaf object versions.<RBW-IDXTERM TERM1="Delete (Version menu)"></RBW-IDXTERM
></RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Effect on parent and child versions</L.LABEL
><B.BODY>Deleting an object version affects its parent and child versions as follows:</B.BODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Effect on child.</CX5FX5FBULLET.EMPHASIS
> If you delete a parent object version, the working child object versions are also deleted. Frozen child object versions are not affected.</RBW-PARABODY
><RBW-PARABODY>If the selected object version is not the only leaf object version, ObjectTeam displays a dialog box, listing all the leaf object versions of the selected object.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LT2.LIST.TEXT.2>Select the versions that you want to delete, and then click OK.</LT2.LIST.TEXT.2
><LR2.LIST.RESULT.2>ObjectTeam deletes the selected object versions.</LR2.LIST.RESULT.2
>Freezing an object version changes its status from working to frozen. The frozen object version cannot be edited.</B.BODY
><B.BODY>Typically, you freeze an object version to make it available to other users or so that you can return to it. For example, you are about to change the model, but you want to be able to return to the current version if the changes do not work.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Only working versions can be frozen </L.LABEL
><B.BODY>Only object versions with a status of working can be frozen; all other object versions are already frozen.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Effect on parent and child versions</L.LABEL
><B.BODY>Freezing an object version affects its parent and child versions as follows:</B.BODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Effect on parent.</CX5FX5FBULLET.EMPHASIS
> If the parent object version has a dynamicFrozen link to the child object, the link is updated. (See <RBW-XREF REFID="19213" TYPE="XREF-TEXTCOPY">Changing Link Status</RBW-XREF
>.)<RBW-IDXTERM TERM1="dynamicFrozen link" TERM2="updated by Freeze"></RBW-IDXTERM
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Effect on child.</CX5FX5FBULLET.EMPHASIS
> Working child object versions are also frozen. Frozen child object versions are not affected.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Links to child object versions</SL.SUBLABEL
><B.BODY>Freezing a parent object version also freezes the links to its child objects. As a result, a frozen parent version always references the same child object versions, regardless of the status of the links. (Link status is described in <RBW-XREF REFID="19213" TYPE="XREF-TEXTCOPY">Changing Link Status</RBW-XREF
>.)</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Notes about diagram files and groups</L.LABEL
><B.BODY>Following are a few notes on freezing diagram files and groups:</B.BODY
> When you freeze a diagram file, you freeze the file only. You do not freeze the items referenced in the file. For example, freezing a Class Diagram (CD) does not freeze the CDMs of the classes that appear in the CD.<RBW-IDXTERM TERM1="diagram" TERM2="freezing"></RBW-IDXTERM
><LT.LIST.TEXT>If you want to freeze both the diagram file and the items that it references, use Groups and SavedGroups, as described in <RBW-XREF REFID="11810" TYPE="XREF-TEXTCOPY">Chapter 4, Using Groups</RBW-XREF
> When you freeze a group, you freeze the rules that define the contents of the group, not the files and items in it. See <RBW-XREF REFID="11810" TYPE="XREF-TEXTCOPY">Chapter 4, Using Groups</RBW-XREF
><RBW-PARABODY>Enter a brief comment that describes the object version, and then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>The comment is stored with the frozen version and displayed when ObjectTeam lists the object versions. Careful use of comments can help you identify the object version that you want to use.</LT.LIST.TEXT
><LR.LIST.RESULT>ObjectTeam freezes the object version.</LR.LIST.RESULT
><RBW-PARABODY>The object version must be a leaf object version, which is one that has not been used to create other object versions.<RBW-IDXTERM TERM1="leaf object version" TERM2="unfreezing"></RBW-IDXTERM
></RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Effect on parent and child versions</L.LABEL
><B.BODY>Unfreezing an object version has no effect on either its parent or child versions.</B.BODY
><RBW-IDXTERM TERM1="configuration" TERM2="adding version to"></RBW-IDXTERM
>Selecting an object version adds it to your configuration.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Only frozen versions can be selected</L.LABEL
><B.BODY>Only frozen or backGround object versions can be selected.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose</L.LABEL
><B.BODY>You build your development environment by adding object versions to your configuration. You can add object versions that you are working on or versions that other project members are working on.</B.BODY
><RBW-PARABODY>Typically, if you are working on an object, you create the object and then create new versions of it as necessary. In this case, selecting an version is useful when you want to use a previous version of the object.</RBW-PARABODY
><RBW-PARABODY>You can also select a version of an object that someone else is working on. You do not interfere with the work of the other person because you can add only frozen versions of the objects to your configuration. The working version of the object is in the configuration of the person working on it.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Effect on parent and child versions</L.LABEL
><B.BODY>Selecting an object version affects its parent and child versions as follows:</B.BODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Choose a different version of an object.</CX5FX5FBULLET.EMPHASIS
> If the object is already in your configuration version, but you want to select a different version of the object, select the object version and then select Version | Select | Selected.</RBW-PARABODY
><RBW-PARABODY>Select the object version that you want to use. Then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam adds the object version you selected in the dialog box to your configuration version. It removes the object version selected in the information area from your configuration version; if that object version is not used in any other configuration it is removed from the repository and given the status backGround.</LR.LIST.RESULT
>Deselecting an object version removes it from your configuration. If it is not used in any other configuration, it is removed from the repository and given the status backGround.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Only frozen versions can be deselected</L.LABEL
><B.BODY>Only frozen object versions can be deselected.</B.BODY
><RBW-PARABODY>Select Version | Deselect.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam removes the selected object version from your configuration version. If it is not used in any other configuration, it is removed from the repository and given the status backGround.</LR.LIST.RESULT
></LABEL
></SUBSECTION
><SUBSECTION><SS.SUBSEC.HEAD><RBW-IDXTERM TERM1="removing" TERM2="object versions from Browser"></RBW-IDXTERM
><RBW-IDXTERM TERM1="version" TERM2="removing from Browser"></RBW-IDXTERM
><RBW-ANCHOR ID="33346"></RBW-ANCHOR
>Deactivating and Activating Configuration Versions</SS.SUBSEC.HEAD
><RBW-IDXTERM TERM1="backGround version" TERM2="creating with Deactivate"></RBW-IDXTERM
>Deactivating a configuration version changes its status from frozen to backGround. It also removes the configuration version from the repository and stores it in the file system. (Removing data from the repository can improve database performance.) The configuration version is still visible in the Browser.</B.BODY
>Version | Deactivate is also used to remove Corporate Groups from a System version, as described in <RBW-XREF REFID="11810" TYPE="XREF-TEXTCOPY">Chapter 4, Using Groups</RBW-XREF
>Activating a configuration version changes its status from backGround to frozen, and moves the configuration version back into the repository.</B.BODY
>Version | Activate is also used to add Corporate Groups to a System version, as described in <RBW-XREF REFID="11810" TYPE="XREF-TEXTCOPY">Chapter 4, Using Groups</RBW-XREF
>.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Only for configuration versions</L.LABEL
><B.BODY>Only configuration versions can be deactivated and activated.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Effect on child versions</L.LABEL
><B.BODY>The parent object of a configuration version is the project. Deactivating or activating a configuration version has no effect on the project object.</B.BODY
><RBW-PARABODY>Deactivating a configuration version also deactivates all its child object versions, unless a child object version is used by another configuration, in which case it is not affected.</RBW-PARABODY
><RBW-IDXTERM TERM1="configuration" TERM2="links to versions"></RBW-IDXTERM
>A parent object version does not contain its child object versions. Instead, the parent object version contains a list of links between the parent object version and the child object versions.</B.BODY
>An object version always has a link to its parent object, and you can always change the status of the link. However, link status is useful only when you are not the person creating new frozen versions of the object. The following scenario illustrates this situation.</B.BODY
><B.BODY>You want to reference an object that a colleague is working on. You use Version | Select to add a frozen version of the object to your configuration version. Your colleague continues to work on it and creates a new frozen version. The link status of the object in your configuration determines whether your configuration version references that new frozen version of the object automatically.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Link status</L.LABEL
><B.BODY>The status of each link allows you to choose the stability of the child object version:</B.BODY
><RBW-PARABODY>A fixed link (the default) points to a specific object version. If configurationA contains a fixed link to a frozen object version, and another configuration creates a new frozen version of the object, configurationA is not affected.<RBW-IDXTERM TERM1="fixed, link status"></RBW-IDXTERM
><RBW-PARABODY>A dynamicFrozen link points to the most recent object version. If configurationA contains a dynamicFrozen link to a frozen object version, and another configuration creates a new frozen version of the object, ObjectTeam updates the link in configurationA to point to the new frozen version of the object.<RBW-IDXTERM TERM1="dynamicFrozen link" TERM2="definition"></RBW-IDXTERM
></RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Link status displayed in Details view</L.LABEL
><B.BODY>When you are using Details view in the Browser, the status of an object’s link appears in the information area. (To display the Details view, select View | Details, if it is not already selected.)</B.BODY
><RBW-PARABODY>Select the link status that you want to use.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><BI.BODY.INTRO>In the following illustration, Pat’s configuration and Lou’s configuration both point to the same frozen version of Object Design phase.</BI.BODY.INTRO
><B.BODY>Pat wants to work on the core system. He creates a new version of the object design phase and then a new version of the core system. Lou’s configuration is not affected.</B.BODY
><B.BODY>Pat finishes his work on the core system and freezes the object design phase, which also freezes the core system. What happens to Lou’s configuration depends on the link status for the object design phase in Lou’s configuration.</B.BODY
><RBW-PARABODY>If the link status is dynamicFrozen, Lou’s configuration is updated to point to the most recent version of the object design phase. Once again, Pat’s configuration and Lou’s configuration both point to the same frozen version of object design phase.</RBW-PARABODY
>You can use Version | Compare to compare an object version in your configuration version with any frozen version of that object. Version compare is available for the following types of objects:<RBW-IDXTERM TERM1="file version" TERM2="comparing"></RBW-IDXTERM
><RBW-PARABODY>Diagrams and matrices on the system level</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Compare command for text files and local sections</L.LABEL
><B.BODY>By default, ObjectTeam uses the fcomp utility to compare text files and local sections. You can use Options | Compare Command to specify a different utility.<RBW-IDXTERM TERM1="Compare Command (Options menu)"></RBW-IDXTERM
>Compare command for diagrams and matrixes</L.LABEL
><B.BODY>ObjectTeam uses the udmcmp utility to compare diagrams and matrices. You can customize the udmcmp utility, as described in the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><B.BODY>By default, the udmcmp utility finds nodes, connectors, connected nodes, and rows to be identical if the elements in the following table are identical:</B.BODY
><RBW-PARABODY>Select the object version that you want to copy. Then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam copies the object version selected in the dialog box into the object version selected in the information area.</LR.LIST.RESULT
><RBW-PARABODY>If you have multiple developers working on the model and want to have a shielded development area for each developer (or group of developers).</RBW-PARABODY
><RBW-PARABODY>If you are developing a new release of a model and, simultaneously, need to make updates to the current release of the model.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Support for parallel development</L.LABEL
><B.BODY>In ObjectTeam, you can create separate configurations for each branch of development. When you are ready, you can merge the configurations.</B.BODY
><B.BODY>This chapter provides examples of how and when you might use parallel development in ObjectTeam. It then describes how to merge the configurations used in parallel development.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisite</L.LABEL
><B.BODY>Before merging configurations (phases or systems), you must be familiar with versions and configurations, as described in <RBW-XREF REFID="22309" TYPE="XREF-TEXTCOPY">Chapter 1, Version and Configuration Management</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><RBW-PARABODY>Scenario 2 uses parallel development to allow developers to work on multiple releases of a model.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Scenario 1: team development</L.LABEL
><B.BODY>In this scenario, multiple developers are working on one model. They are each working in their own configuration, rather than sharing a single configuration. Periodically, you must merge the developers’ changes into an integrated version of the model. The following figure illustrates this scenario.</B.BODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>One Main configuration.</CX5FX5FBULLET.EMPHASIS
> This configuration contains the integrated version of the model. All development changes are periodically merged into this one configuration.</RBW-PARABODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>A configuration for each developer (Developer configurations).</CX5FX5FBULLET.EMPHASIS
> Each developer, or group of developers, works in a separate configuration. Periodically, the Developer configurations are merged into the Main configuration.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Process</L.LABEL
><B.BODY>The following steps outline the parallel development process:</B.BODY
><RBW-PARABODY>In their own configurations, the developers create new versions of the systems and modify them as necessary. Typically, each developer focuses on a different system or different set of systems.</RBW-PARABODY
><RBW-PARABODY>When you are ready to integrate the developers’ changes, the developers freeze their configurations and you merge each Developer configuration into the Main configuration.</RBW-PARABODY
><RBW-PARABODY>The Main configuration again holds the most recent version of the model. Return to step 1 to repeat the development cycle.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Scenario 2: parallel release schedules</L.LABEL
><B.BODY>In this scenario, you have released a version of your model (Release X). You are ready to begin work on the next release (Release X+1), but must occasionally update the current release (Release X) to correct critical errors. The following figure illustrates this scenario.</B.BODY
><RBW-PARABODY>Developers working on Release X+1 update the Main configuration. Developers working on Release X update the ReleaseX configuration.</RBW-PARABODY
><RBW-PARABODY>Merge the Main configuration into the ReleaseX+1 configuration.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>If an object has been changed in both ReleaseX and ReleaseX+1, the merge process warns you of the conflicting object versions. You examine the conflicting Release X and Release X+1 versions of the object and reconcile the changes.</LT.LIST.TEXT
><RBW-PARABODY>The ReleaseX+1 configuration now contains the finished Release X+1 version of the model. In the Main configuration, select all the latest system versions from the Release X+1 configuration.</RBW-PARABODY
> version of an object can be in any number of configurations. </RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The following example shows how two configurations, a Main configuration and a Developer configuration, might be used in a project.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Main configuration</SL.SUBLABEL
><BI.BODY.INTRO>The Main configuration contains an Object Design Phase version and two System versions; the Phase and System versions are <CX5FX5FOBJECT.NAME>frozen</CX5FX5FOBJECT.NAME
> versions. Lou’s configuration is empty.</BI.BODY.INTRO
><B.BODY>The developer, Lou, wants to edit the Core system. She adds the <CX5FX5FOBJECT.NAME>frozen</CX5FX5FOBJECT.NAME
> Object Design Phase version to her configuration. Because the Phase version points to the <CX5FX5FOBJECT.NAME>frozen</CX5FX5FOBJECT.NAME
> System versions, the System versions are also added to Lou’s configuration. Both configurations now point to the same Phase and System versions.</B.BODY
>Changing the Developer configuration</SL.SUBLABEL
><BI.BODY.INTRO>Lou wants to work on the Core system, so she creates a new version of the Object Design Phase and a new version of the Core system. The new versions become <CX5FX5FOBJECT.NAME>working</CX5FX5FOBJECT.NAME
> versions in Lou’s configuration. The Main configuration does not change. The two configurations now point to the same version of the GUI NT system, but different versions of the Core system.</BI.BODY.INTRO
>Configurations should share <CX5FX5FEMPHASIS>frozen</CX5FX5FEMPHASIS
> System versions rather than File versions.</B.BODY
><B.BODY>If two configurations contain the same frozen System version, the property values in that System version are the same in both configurations. If two configurations contain the same frozen File version, not all property values available in that File version are the same in both configuations.</B.BODY
><B.BODY>See <RBW-XREF REFID="40295" TYPE="XREF-TEXTCOPY">Item Generations and Property Values</RBW-XREF
><RBW-PARABODY>Two versions of the same system</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose</L.LABEL
><B.BODY>You merge a source configuration, phase, or system into a target configuration, phase, or system. The merge operation updates the target based on the changes made to the source.</B.BODY
>The merge operation is designed to support parallel development. It is not designed to merge two unrelated configurations, phases, or systems.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Process</L.LABEL
><B.BODY>The following steps provide an overview of the merge process. This section describes each step in greater detail.</B.BODY
><RBW-PARABODY>You select a target configuration, phase, or system. You select a source configuration, phase, or system. You start the merge.</RBW-PARABODY
><RBW-PARABODY>If the source and target elements are directly derived from one another, ObjectTeam can merge the element into the target.</RBW-PARABODY
><RBW-PARABODY>If the source and target elements are not directly derived from one another, the source element conflicts with the target element. You must resolve the conflict before ObjectTeam can merge the element into the target.</RBW-PARABODY
><RBW-PARABODY>ObjectTeam opens a Merge window. The window lists each source element that must be merged into the target and whether or not the source element conflicts with a target element.</RBW-PARABODY
><RBW-PARABODY>If the source element does not conflict with the target element, you can either merge the source element into the target or use the target element.</RBW-PARABODY
><RBW-PARABODY>If the source element conflicts with the target element, you can either use the source element or use the target element. Typically, you examine the conflicting elements, merge them by hand, and then use your merged version of the element.</RBW-PARABODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="18382" TYPE="XREF-TEXTCOPY">Starting the Merge&rbwtab;2–9</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="14654" TYPE="XREF-TEXTCOPY">Reviewing the Results in the Merge Window&rbwtab;2–11</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="22277" TYPE="XREF-TEXTCOPY">Merging the Source Elements Into the Target&rbwtab;2–14</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="11562" TYPE="XREF-TEXTCOPY">Working With Merge Links&rbwtab;2–18</RBW-XREF
><B.BODY>Starting a merge operation does not change the source or target configuration, phase, or system. It displays the Merge window. The target is changed when you use the Merge window to merge the source into the target, as described in <RBW-XREF REFID="22277" TYPE="XREF-TEXTCOPY">Merging the Source Elements Into the Target</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Status of versions</L.LABEL
><B.BODY>You can merge configuration, phase, and system versions that have a status of <CX5FX5FEMPHASIS>working</CX5FX5FEMPHASIS
> or <CX5FX5FEMPHASIS>frozen</CX5FX5FEMPHASIS
>. You cannot merge versions that have a status of <CX5FX5FEMPHASIS>background</CX5FX5FEMPHASIS
>.</B.BODY
><B.BODY>If the status of the target version is <CX5FX5FEMPHASIS>working</CX5FX5FEMPHASIS
>, the source elements are merged into that target version. If the status is <CX5FX5FEMPHASIS>frozen</CX5FX5FEMPHASIS
>, ObjectTeam creates a new version of the target object and merges the source elements into that new version.</B.BODY
><RBW-PARABODY>Select the source configuration and select OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam examines each object in the source, determines how it should be merged into the target, and displays the results in the Merge window.</LR.LIST.RESULT
><RBW-PARABODY>Optionally, merge the source elements into the target, as described in <RBW-XREF REFID="22277" TYPE="XREF-TEXTCOPY">Merging the Source Elements Into the Target</RBW-XREF
>.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to merge versions of a phase or system</L.LABEL
><RBW-PARABODY>Select Version | Merge.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam examines each object in the source, determines how it should be merged into the target, and displays the results in the Merge window.</LR.LIST.RESULT
><RBW-PARABODY>Optionally, merge the source elements into the target, as described in <RBW-XREF REFID="22277" TYPE="XREF-TEXTCOPY">Merging the Source Elements Into the Target</RBW-XREF
><B.BODY>The Merge window lists all elements in the source object version that are not in the target object version. If the source version of an element is in the target, it is not listed in the Merge window.</B.BODY
>If the Merge window is empty, the source object version is a subset of (or identical to) the target object version.</T.TIP
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Information displayed</L.LABEL
><B.BODY>Like the Browser, the Merge window has a Navigation area and an Information area. When you select an object in the Navigation area, the Information area displays the following information for each element in that object:</B.BODY
>. The source and target elements do not conflict; ObjectTeam can merge the source element into the target. This occurs when the source element is not in the target, the source and target elements are directly derived from one another, or the source element is a System or Phase that contains no conflicting elements.</CELLBODY
>. The source element conflicts with the target; you must resolve the conflict before ObjectTeam can merge the source element into the target. This occurs when the source and target elements are not directly derived from one another, or the source element is a System or Phase that contains conflicting elements.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Version of <CX5FX5FVARIABLE>Name</CX5FX5FVARIABLE
> (if any) that is selected in the source version of the object selected in the Navigation area. </CELLBODY
><CELLBODY><CX5FX5FEMPHASIS>Tip</CX5FX5FEMPHASIS
>: If the Base Version and From Version are the same (or from the same configuration), and the To Version is different (or from a different configuration), the To Version is the most recent version.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Version of <CX5FX5FVARIABLE>Name</CX5FX5FVARIABLE
> (if any) that is selected in the target version of the object selected in the Navigation area. </CELLBODY
><CELLBODY><CX5FX5FEMPHASIS>Tip</CX5FX5FEMPHASIS
>: If the Base Version and From Version are the same (or from the same configuration), and the To Version is different (or from a different configuration), the To Version is the most recent version.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to filter the information</L.LABEL
><B.BODY>Select or clear the View | Show All Merge Objects command to filter the information displayed in the Merge window.</B.BODY
><RBW-PARABODY>If a phase or system in the source object version contains conflicting elements, show all elements in the phase or system.</RBW-PARABODY
><RBW-PARABODY>If a phase or system in the source object version contains no conflicting elements, show the phase or system but not the elements that it contains.</RBW-PARABODY
></LB2.LIST.BULLET.2
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to display details about an element</L.LABEL
><B.BODY>Use the following commands to display information about an element:</B.BODY
>When examining conflicting file versions, you might find it useful to compare them. See <RBW-XREF REFID="19986" TYPE="XREF-TEXTCOPY">Comparing File Versions</RBW-XREF
>Merging the Source Elements Into the Target</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Merge all source elements</L.LABEL
><B.BODY>Use the Merge window to merge the source elements into the target. To completely merge the source object version into the target object version, you must merge into the target <CX5FX5FEMPHASIS>all</CX5FX5FEMPHASIS
> of the source elements listed in the Merge window.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to merge source elements into the target</L.LABEL
>To select multiple elements, press and hold the Control key while selecting the elements, or use the Edit | Select All and Edit | Invert Selection commands.</T2.TIP.2
>If the source version of the phase or system contains an element that conflicts with the target, that element is not merged. It remains in the Merge window.</N2.NOTE.2
><RBW-PARABODY>the selected source element is in a System version (it is a file, property, or item), it does not conflict with the target, and you want to use the source version of the element.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>In the following example, you are merging the dev1 configuration into the main configuration. The dev1 configuration contains only one phase. When the Merge window appears, you select the phase and then select the Merge command. The following table shows the effect of the Merge command. Explanatory notes follow the table.</B.BODY
><RBW-PARABODY>The target configuration, main (v1) is frozen, therefore, ObjectTeam creates a new version of the target configuration, main (v2).</RBW-PARABODY
><RBW-PARABODY>All elements in the dev1 configuration are either new or directly derived from the main configuration. Therefore, none of the source elements conflict with the target.</RBW-PARABODY
><RBW-PARABODY>The dev1 configuration contains a new version of the Object Design phase, therefore, ObjectTeam creates a new version of the Object Design phase (main.5) in main (v2).</RBW-PARABODY
><RBW-PARABODY>The source Object Design phase contains a new version of systemA. In this example, the target version of systemA (main.10) has also been changed; therefore, ObjectTeam creates a new version of systemA (main.11) in the target Object Design phase.</RBW-PARABODY
><RBW-PARABODY>The source version of systemA contains new versions of diagram2 and classMatrix2, therefore, ObjectTeam selects these new versions in the target version of systemA.</RBW-PARABODY
><RBW-PARABODY>The source version of systemA contains a new item, item3, therefore, ObjectTeam copies this new item to the target version of systemA.</RBW-PARABODY
><RBW-PARABODY>The source version of systemA has a new value for the FreeText property. It conflicts with the target value, so cannot be merged.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="24858"></RBW-ANCHOR
>Overwrite command</L.LABEL
><B.BODY>Select the Overwrite command when the source element conflicts with the target and you want to use the source version of the selected element instead of the target version.</B.BODY
>The Overwrite command is only available when the source element conflicts with the target.</N.NOTE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>In the following example, you are merging the dev1 configuration into the main configuration. Both configurations are frozen.</B.BODY
><B.BODY>The source version of the Object Design phase (ObjectDesign, dev.1) is directly derived from target version. The source version of systemA (systemA, dev.1) is not directly derived from the target version. When the Merge window appears, it indicates that the source version of systemA conflicts with the target version.</B.BODY
><B.BODY>You select systemA and then select the Overwrite command. The following table shows the effect of the Overwrite command. Explanatory notes follow the table.</B.BODY
><RBW-PARABODY>To create a new system version in the target configuration, ObjectTeam must first create a new configuration version (main, v2) and a new phase version (ObjectDesign, main.5).</RBW-PARABODY
>The Create Merge Link command is only available when the source element is an object version. It is not available when the source element is a property or item.</N.NOTE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Merge Links</SL.SUBLABEL
><B.BODY>To store the fact that you want to use the target version of an element instead of the source version, ObjectTeam adds a Merge Link to the target version. The Merge Link points from the source version to the target version. In the future, when you merge these source and target versions, ObjectTeam sees the Merge Link and ignores the source version.</B.BODY
>You can display, create, and delete Merge Links in the Version Browser, as described in <RBW-XREF REFID="11562" TYPE="XREF-TEXTCOPY">Working With Merge Links</RBW-XREF
>.</N.NOTE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>In the following example, you are merging the dev1 configuration into the main configuration. Both configurations are frozen.</B.BODY
><B.BODY>The source version of the Object Design phase (ObjectDesign, dev.1) is directly derived from target version. The source version of systemA (systemA, dev.1) is not directly derived from the target version. When the Merge window appears, it indicates that the source version of systemA conflicts with the target version.</B.BODY
><B.BODY>You select systemA and then select the Create Merge Link command. The following table shows the effect of the Create Merge Link command. The new target version of systemA (main.11) is identical to the old target version (main.10), except for the addition of the Merge Link.</B.BODY
><B.BODY>A Merge Link is stored on a target object version. It points from a source object version to the target object version. When you merge the source version into the target version, ObjectTeam sees the Merge Link and ignores the source version. Merge Links are only used during merge.</B.BODY
> for a complete description of the Version Browser.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to create a Merge Link</L.LABEL
><B.BODY>Typically, you create Merge Links during a merge operation, as described in <RBW-XREF REFID="37744" TYPE="XREF-TEXTCOPY">Create Merge Link command</RBW-XREF
>. You can also create Merge Links in the Version Browser.</B.BODY
><B.BODY>When you merge a source configuration, phase, or system version into a target source configuration, phase, or system version, ObjectTeam merges each source element into the target. The following table lists the elements that appear in system, phase, and configuration versions.</B.BODY
><RBW-PARABODY>If the element is an object version (for example, a phase, system, or file) ObjectTeam compares the version numbers of the source and target object versions. </RBW-PARABODY
><RBW-PARABODY>If the source and target versions of the file are derived from one another, ObjectTeam can merge the source file version into the target.</RBW-PARABODY
>To see which version is more recent, compare the Base Version, To Version, and From Version columns in the Merge window. If the Base and To Versions are the same, the From (source) Version is more recent. If the Base and From Versions are the same, the To (target) Version is more recent.</T2.TIP.2
><RBW-PARABODY>If the source and target versions of the file are not derived from one another, the source version conflicts with the target version.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Group versions</L.LABEL
><B.BODY>When merging a source system into a target system, ObjectTeam examines each group version selected in the source system. The rules for examining group versions are the same as those for examining file versions (see <RBW-XREF REFID="41435" TYPE="XREF-TEXTCOPY">File versions</RBW-XREF
>).</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customization file versions</L.LABEL
><B.BODY>When merging a source system, phase, or configuration into a target system, phase, or configuration ObjectTeam examines each customization file version selected in the source system, phase, or configuration. The rules for examining customization file versions are the same as those for examining file versions (see <RBW-XREF REFID="41435" TYPE="XREF-TEXTCOPY">File versions</RBW-XREF
>).</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Reused corporate group versions</L.LABEL
><B.BODY>When merging a source system into a target system, ObjectTeam examines each reused corporate group version selected in the source system:</B.BODY
><RBW-PARABODY>If no version of the corporate group is selected in the target system, ObjectTeam can merge the source corporate group version into the target.</RBW-PARABODY
><RBW-PARABODY>If a different version of the corporate group version is reused in the target system, ObjectTeam can merge the source corporate group version into the target.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Items</L.LABEL
><BI.BODY.INTRO>When merging a source system into a target system, ObjectTeam examines each item in the source system:</BI.BODY.INTRO
><RBW-PARABODY>and ObjectTeam can create it in the target using the same scope that is used in the source, ObjectTeam can merge the item into the target.</RBW-PARABODY
><RBW-PARABODY>and ObjectTeam cannot create it in the target using the same scope that is used in the source, then the item conflicts with the target.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LT.LIST.TEXT>After merging the source item into the target system, ObjectTeam copies the source item properties into the target, as described in <RBW-XREF REFID="27757" TYPE="XREF-TEXTCOPY">Properties</RBW-XREF
><RBW-PARABODY>If the item exists in the target system, and the scope of the source item is different than the scope of the target item, the source item conflicts with the target.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="27757"></RBW-ANCHOR
>Properties</L.LABEL
><B.BODY>When merging a source system, phase, or configuration into a target system, phase, or configuration ObjectTeam examines each property in the source system, phase, or configuration.</B.BODY
>The same rules are used for all properties (system&truehy;, phase&truehy;, and configuration&truehy;level properties, as well as item properties).</N.NOTE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Background</SL.SUBLABEL
><B.BODY>To determine which property values to use, ObjectTeam compares three values:</B.BODY
><RBW-PARABODY>Source property — the value of the property as defined in the source item, system, phase, or configuration. If the source property is not set, its value is null.</RBW-PARABODY
><RBW-PARABODY>Target property — the value of the property as defined in the target item, system, phase, or configuration. If the target property is not set, its value is null.</RBW-PARABODY
><RBW-PARABODY>Base property — the value of the property as defined in the base system, phase, or configuration. The base version is the version from which both the source and target versions are derived. If the base property is not set, or the source and target versions are not derived from the same version, the base property is null.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Rules</SL.SUBLABEL
><B.BODY>ObjectTeam uses the following rules to examine each source property:</B.BODY
><RBW-PARABODY>If the source and target properties are different, the target property is not null, and the base property is the same as either the target or the source, ObjectTeam can merge the source property into the target.</RBW-PARABODY
>To see which property value is more recent, compare the base, source, and target values. If the base and source are the same, the target is more recent. If the base and target are the same, the source is more recent.</T2.TIP.2
>Merging Systems into Another Phase</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This section describes how to merge systems and their contents from one phase into the next, from Analysis into System Design, for example, or from System Design into Object Design.</B.BODY
>You do not merge systems from the Object Design phase into the Implementation phase, but you generate their contents into language&truehy;specific code files using an ObjectTeam code generator. For details on generating code, see the <CX5FX5FTITLE>ObjectTeam Code Generation Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for your target language.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Phase boundaries</L.LABEL
><B.BODY>Each phase is a shielded development area. Changes to a system in one phase do not (automatically) affect systems in any other phase. For example, work in the System Design phase does not change analysis data in the Analysis phase.</B.BODY
><B.BODY>However, work done in one phase can affect systems in other phases. If you have merged a system from the Analysis phase into the System Design phase, you can go back and modify a new version of that system in the Analysis phase.</B.BODY
><B.BODY>You must then decide whether those changes affect the system in the System Design phase and, if necessary, merge these changes into the System Design phase. These changes can be merged using ObjectTeam’s built&truehy;in merge mechanism.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Merging data</L.LABEL
><B.BODY>When you merge systems into another phase, ObjectTeam actually carries out three tasks:</B.BODY
><B.BODY>ObjectTeam uses a mechanism called “merging” to carry out these tasks (see <RBW-XREF REFID="17775" TYPE="XREF-TEXTCOPY">Merging Configurations, Phases, and Systems</RBW-XREF
>).</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to merge systems</L.LABEL
><B.BODY>You use the ObjectTeam Merge Window to merge data from one phase into the next. In the Merge Window, you select which system(s) you want to merge.</B.BODY
>If you want to preserve any changes made in a system in the current phase, do only select non&truehy;conflicting systems. A system is non&truehy;conflicting if it has a No in the Conflict field. </W2.WARNING.2
><LT.LIST.TEXT>See <RBW-XREF REFID="38403" TYPE="XREF-TEXTCOPY">Dealing with Merge Conflicts</RBW-XREF
><RBW-PARABODY>Select Version | Merge</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The data from the source system(s) is copied to the target phase, the source system(s) are frozen, and merge links are created.</LR.LIST.RESULT
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Merging from other Phase</SL.SUBLABEL
><B.BODY>You can also merge system data from a Phase other than the previous, using Utilities | Merge From Other Phase. You select the source Phase from the Select Merge Source dialog box, after which the Merge Window appears.</B.BODY
><B.BODY>The ObjectTeam Merge Window is very similar to the Merge Window that is used for merging versions (See <RBW-XREF REFID="40524" TYPE="XREF-TEXTCOPY">The ObjectTeam Merge Window</RBW-XREF
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>A value of No or Yes (see <RBW-XREF REFID="38403" TYPE="XREF-TEXTCOPY">Dealing with Merge Conflicts</RBW-XREF
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Version of <CX5FX5FVARIABLE>Name</CX5FX5FVARIABLE
> (if any) that is selected in the source version of the object selected in the Navigation area. </CELLBODY
><CELLBODY><CX5FX5FEMPHASIS>Tip</CX5FX5FEMPHASIS
>: If the Base Version and From Version are the same (or from the same configuration), and the To Version is different (or from a different configuration), the To Version is the most recent version.</CELLBODY
><RBW-PARABODY>You have created a new version of the merged System in the current Phase and made changes to this new version: you have added attributes and operations to classes in CDs, for example.</RBW-PARABODY
><RBW-PARABODY>Somebody (maybe you) has created a new version of the corresponding System in the previous Phase, and has made changes too. Attributes have been added to existing classes, for example.</RBW-PARABODY
><B.BODY>If you now merged version 2 of the previous Phase into the current Phase, the changes made to the classes in the current Phase would be lost, since the CDMs are copied from the other Phase. The CDMs related to existing classes are conflicting.</B.BODY
><B.BODY>But if you do not merge the CDMs from the previous Phase, the changes made to the classes in the previous Phase will not be processed in the current Phase.</B.BODY
><B.BODY>The conflict that has arisen must be resolved.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Resolving a conflict</L.LABEL
><B.BODY>To resolve a conflict, you have to decide between <CX5FX5FEMPHASIS>preserving </CX5FX5FEMPHASIS
><B.BODY>When data is merged into another Phase, ObjectTeam normally copies data from the previous phase to the current. If you want to preserve your data, you do not want that to happen. Create a merge link to prevent ObjectTeam from overwriting the target object.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Overwriting the target object</SL.SUBLABEL
><B.BODY>If you want a conflicting target object to be overwritten by its corresponding source object, you merge the source object, or the system that contains the conflicting object. The source object will then be copied over the target object and a merge link will be created automatically.</B.BODY
><RBW-PARABODY>Enter an (optional) comment and click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>A merge link is created, the source object is frozen, and the conflicting target object disappears from the Merge Window. No data is copied. </LR.LIST.RESULT
><B.BODY>If you now (re)merge the parent system, the target object will be ignored because of the merge link.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Removing merge links</L.LABEL
><B.BODY>Merge links can be created implicitly or explicitly. They are created <CX5FX5FEMPHASIS>implicitly</CX5FX5FEMPHASIS
> when objects are merged. They are created <CX5FX5FEMPHASIS>explicitly</CX5FX5FEMPHASIS
> on conflicting objects when you select Version | Create Merge Link in the Merge Window. </B.BODY
><B.BODY>You can remove a merge link by unfreezing the source object.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Unreferenced CDMs and items</L.LABEL
><B.BODY>Objects in the target phase can be overwritten as a result of a merge action, but they are never <CX5FX5FEMPHASIS>removed</CX5FX5FEMPHASIS
>. For example, if a class disappears from the target CD because it was overwritten by the source CD (which did not contain the class), the corresponding CDM becomes unreferenced, but it will not be removed.</B.BODY
><B.BODY>Or, similarly, if an attribute disappears from a class as a result of a merge action, the item becomes unreferenced, and will not be removed from the set of defined items.</B.BODY
>You can remove all unreferenced items from a system, or a diagram using Utilities | Delete Unreferenced Items on Phase or System level. You cannot remove unreferenced CDMs this way, but you can find out all the unreferenced CDMs in a system by running a report using Utilities | Reports | On Unreferenced CDMs.</T.TIP
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Comparing conflicting objects</L.LABEL
><B.BODY>Before you decide to overwrite or preserve a conflicting object, you might want to check what the differences are between the source and the target object. </B.BODY
><RBW-PARABODY>Select Version | Compare</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>A Monitoring Window appears, listing the differences between the source and the target object.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Version management</L.LABEL
><B.BODY>From the Merge Window, you can start up the Version Browser for a particular object. In the Version Browser you can, among other things, select, deselect, delete, freeze and unfreeze versions of an object.</B.BODY
>The Version Browser displays merge links between object versions within the same phase. However, it does not display merge links between object versions from different phases.</N.NOTE
> control the appearance of the Browser, as well as the default settings for many dialog box fields. ObjectTeam automatically saves these settings to a file in your home directory. Optionally, you can explicitly save selected settings at a specific level in the project hierarchy. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated files</L.LABEL
><B.BODY>Certain ObjectTeam tools, such as the Document Generator and Code Generator, produce files as their output. These files must be stored in the file system so that they are accessible to external tools, such as compilers and DTP packages. In a multiuser environment, each user should have a set of directories in which to store these generated files. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to start a second Browser with the same settings</L.LABEL
><B.BODY>Sometimes it is useful to have more than one Browser window open. When you start a new Browser from the current Browser, ObjectTeam uses the current Browser settings as the initial settings for the new Browser.<RBW-IDXTERM TERM1="Browser" TERM2="starting"></RBW-IDXTERM
> control the appearance of the browser, and the default settings for many dialog box fields. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Saved in two ways</L.LABEL
><B.BODY>The value of each browser setting is stored as an M4 environment variable. These variables are saved automatically and can also be saved explicitly.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Saved automatically to Meta4UserEnv file</L.LABEL
>When you exit from the Browser, ObjectTeam saves the current settings to the Meta4UserEnv file. When you start the Browser, ObjectTeam uses this file to initialize the Browser settings. As a result, your latest Browser settings are restored each time you start the Browser.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Saved explicitly to m4env file</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="Copy User Environment (Options menu)"></RBW-IDXTERM
><RBW-IDXTERM TERM1="m4env file"></RBW-IDXTERM
>You can use Options | Copy User Environment to save selected Browser settings to the corporate, project, configuration, phase, or system level. This command creates an m4env file at the specified level. (Only a corporate administrator can save settings to the corporate level.)</B.BODY
><B.BODY>If an m4env file exists, ObjectTeam uses the saved settings when you are at the level that holds the m4env file or at any lower level. If the same setting is saved at two different levels, ObjectTeam uses the setting saved at the higher level; the setting at the lower level is ignored.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>When to explicitly save Browser settings</L.LABEL
><B.BODY>Saving a Browser setting to a particular level ensures that the setting is always used at that level and lower.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>Options | Printer Setup | Graphics allows you to specify the printer used to print diagrams. If you save this Browser setting at the project level, you ensure that all diagrams are printed using the specified printer. ObjectTeam users working in that project cannot use the Options | Printer Setup | Graphics dialog box to change the setting.</B.BODY
><RBW-PARABODY>Select Options | Copy User Environment.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>A submenu appears, allowing you to select the level at which you want to save the settings. The submenu includes only the current level and higher levels. For example, if you are at the configuration level, the submenu commands are: To ConfigVersion Environment, To Project Environment, and To Corporate Environment.</LR.LIST.RESULT
>Certain ObjectTeam tools, such as the Document Generator and the Code Generator, produce files as their output. These files must be stored in the file system to be accessible to external tools, such as compilers and DTP packages. The collection of files in the file system produced by a particular user is part of the user environment.</B.BODY
>ObjectTeam uses the File System Path Part property to determine the location of a generated file. You can set this property at any level (corporate, project, configuration version, phase version, system version, or file version). The File System Path Part properties at the different levels provide the path information, as shown in the following table.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The property value at corporate&truehy;level. If the value begins with a slash mark (/), it is treated as an absolute path. If this value is a dot (.) or specifies a relative directory, the path is <CX5FX5FVARIABLE>user_home_dir</CX5FX5FVARIABLE
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The result of adding the current corporate path to the value of the property fileSystemPath of the project. If this value is a dot, nothing is added to the current path. If this is an absolute directory, it becomes the path of the project. If the property is not set, the name of the project is added to the path.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The result of adding the current project path to the value of the File System Path Part property of the configuration version. If this value is a dot, nothing is added to the current path. If it is an absolute directory, it becomes the path of the configuration version. If the property is not set, the following is added:</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The result of adding the current configuration version path to the value of the File System Path Part property of the phase version. If this value is a dot, nothing is added to the current path. If it is an absolute directory, it becomes the path of the phase version. If the property is not set, the name of the phase version is added.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The result of adding the current phase version path to the value of the File System Path Part property of the system version. If this value is a dot, nothing is added to the current path. If it is an absolute directory, it becomes the path of the system version. If the property is not set, the name of the system version is added.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The result of adding the current system version path to the value of the File System Path Part property of the file version. If this value is a dot, nothing is added to the current path. If it is an absolute directory, it becomes the path of the file version. If the property is not set, the name of the file version is added.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>User Jim is generating a document Core_sys in the Object Design phase in configuration version test.1. The File System Path Part property is not set for configuration version, phase version, system version or file version. By default, the generated files are saved in:</B.BODY
><B.BODY>Jim now sets the File System Path Part property of his configuration version test.1 to testdocs. Also, because he does not want to navigate down the file system tree to look at his generated files, he specifies that the phase name be left out of the path by specifying a dot (.) for the File System Path Part property of the phase version. As a result, the generated files are now saved in the following folder:</B.BODY
><B.BODY>Cayenne strongly recommends that the File System Path Part property be set at corporate (or project) level to point to a network drive. This setting ensures that all generated files are stored in a central location, which simplifies backups, and that all generated files can be accessed by all members of the project team.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changing the File System Path Part</L.LABEL
><B.BODY>ObjectTeam uses the File System Path Part property to locate generated files. Always use caution when changing this property.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="37818"></RBW-ANCHOR
>How to change the File System Path Part property</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Before you begin</SL.SUBLABEL
><B.BODY>Freeze all generated files affected by the change. For example, if you are changing the property at the project level, freeze all generated files in the project. (Freezing the files stores the content of the file in the repository.)</B.BODY
><RBW-PARABODY>Click OK to close the Edit Properties dialog box.</RBW-PARABODY
></LN.LIST.NUM
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Accessing the generated files in the new location</SL.SUBLABEL
><B.BODY>After changing the File System Path Part property, you can access any generated file. When you access the file, ObjectTeam looks in the new location for the file. The file does not exist.ObjectTeam then copies the latest version of the file out of the repository and into the new location.</B.BODY
>p is an organizational unit in a system that combines files and items. Groups are not part of the hierarchical tree structure of the project, but rather a view of a selected part of the currently visible contents of a system. </B.BODY
> Diagram versions do not include the items referenced in the diagram. If you want to be able to restore a diagram and the items and item properties in it, you must create and save a group that contains the diagram and its related items.</RBW-PARABODY
> Often a diagram or portion of a diagram can be reused by different projects. If you create a group that contains the relevant diagram components and related items, you can promote that group to the corporate level. A corporate group can be accessed by other projects, but cannot be changed by any project.</RBW-PARABODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Sharing model data.</CX5FX5FBULLET.EMPHASIS
> Often portions of a system, perhaps a class or a portion of a diagram, created by one developer can be a useful starting point for another developer. If you create a group that contains the relevant diagram components and related items, other developers can copy the group to their own configurations and then modify the components as necessary.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisites</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="group" TERM2="prerequisites for using"></RBW-IDXTERM
>To create useful groups, you must carefully specify the related files and items that belong in it. To do so, you must be familiar with the following:</B.BODY
>provides the menu items and Tcl code required to use (corporate) groups in ObjectTeam. Therefore, this module must be active on the Browser levels where it is going to be used.</B.BODY
><B.BODY>You can check if a module is active on a particular Browser level by selecting Utilities | Show Active Modules on that level.</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="35319" TYPE="XREF-TEXTCOPY">Creating Group Versions and SavedGroup Versions&rbwtab;4–18</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="28675" TYPE="XREF-TEXTCOPY">Creating and Using Corporate Groups&rbwtab;4–21</RBW-XREF
><RBW-PARABODY>Specify its contents.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>You use rules to specify the contents</L.LABEL
><B.BODY>Specifying the contents of a group means identifying the files and items in it. Because your systems are constantly changing, you specify rules that ObjectTeam can use to identify the files and items in the group, rather than specifying individual files and items.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>ObjectTeam uses the rules to build the group</L.LABEL
><B.BODY>The following table shows how ObjectTeam uses the set of rules that you specify to determine the contents of the group:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Uses the File Selectors rule to add additional files to the group based on what items are already in the group.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Uses the Item Selectors rule to add additional items to the group based on what files are already in the group.</CELLBODY
>You can specify one or more rules. ObjectTeam uses all the rules that you specify to identify the files and items in the group.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Subgroups</L.LABEL
><B.BODY>The modes Explicit Group Version and Group Version Filter can only be used for group versions that contain subgroups. Unlike group versions in the current release, group versions in previous releases of ObjectTeam could contain subgroups.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Groups contain current file versions</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="version" TERM2="of object in group"></RBW-IDXTERM
>When ObjectTeam adds a file to a group, it uses the current, selected version of the file. To create a group composed of specific file versions, you must use saved groups, as described in <RBW-XREF REFID="35319" TYPE="XREF-TEXTCOPY">Creating Group Versions and SavedGroup Versions</RBW-XREF
><RBW-PARABODY>Open the group. (In the information area, double&truehy;click on the group, or select the group and then click File | Open.)</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT><RBW-IDXTERM TERM1="Edit Group Structure dialog box" TERM2="picture of"></RBW-IDXTERM
>The Edit Group Structure dialog box appears. Overview mode, the default mode (see <RBW-XREF REFID="19688" TYPE="XREF-TEXTCOPY">Overview Mode</RBW-XREF
>),displays all files and items in the group.</LR.LIST.RESULT
><RBW-PARABODY>Use Item Selector mode to specify the rules for adding items to the group based on what files are already in the group.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>The remainder of this section describes how to use each mode of the Edit Group Structure dialog box to specify the rules that define the contents of a group.</B.BODY
>Use Explicit File mode to add selected files to the group.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Adding a file adds an item</SL.SUBLABEL
><B.BODY>When you add a file to the group, ObjectTeam also adds the item associated with that file. For example, if you use Explicit File to add the CoreClasses CD to the group, the group contains</B.BODY
><LR.LIST.RESULT>The New Explicit File dialog box appears, displaying a list of all files in the current system that are not in the group.</LR.LIST.RESULT
><RBW-PARABODY>Select one or more files. Then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam adds the files and their items to the group and updates the Contents list, displaying the files added to the group.</LR.LIST.RESULT
>Use File Filter mode to create a filter that defines a set of files to add to the group. You can create filters based on name, type, and property values.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Adding a file adds an item</SL.SUBLABEL
><B.BODY>When you add a file to the group, ObjectTeam also adds the item associated with that file. For example, if you create a file filter that adds the CoreClasses CD to the group, the group contains<RBW-IDXTERM TERM1="item" TERM2="adding to group"></RBW-IDXTERM
><RBW-PARABODY>The Show button allows you select one or more file filters, then updates the Contents list to show only those files added to the group using the selected filters. (To display all files added to the group using File Filter mode, select all file filters.)</RBW-PARABODY
><B.BODY>The New Item Filter dialog box allows you to create a file filter. Select one or more of the options, which are described following the illustration:</B.BODY
> Select the Name check box and use Tcl global pattern matching to specify a file name. For example, to add all files whose names begin with client or are qualified by client, type <CX5FX5FINPUT>client*</CX5FX5FINPUT
>; to add only files qualified by client, type <CX5FX5FINPUT>client:*</CX5FX5FINPUT
> Select the Type check box and use Tcl global pattern matching to specify a file type. The following table lists the file types, which are case sensitive:</RBW-PARABODY
> Select the Property check box, specify a property name, and use Tcl global pattern matching to specify a property value.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See the Tcl documentation for details on Tcl global pattern matching. See <RBW-XREF REFID="39383" TYPE="XREF-TEXTCOPY">Appendix A, OMT Support</RBW-XREF
>, for more information about the OMT diagrams.</B.BODY
><RBW-PARABODY>Specify the options. Then select OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam adds the files that match the filter criteria to the group, adds the items associated with those files to the group, and updates the Contents list to include the files added to the group.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to display the files added by a particular file filter</L.LABEL
><RBW-PARABODY>Select one or more of the file filters. Then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam removes the selected file filters. Files added to the group only by the selected file filters are removed from the group along with their associated items.</LR.LIST.RESULT
>Use Item Filter mode to create a filter that defines a set of items to add to the group. You can create item filters based on name, type, and property values.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-IDXTERM TERM1="Edit Group Structure dialog box" TERM2="Item Filter mode"></RBW-IDXTERM
>Edit Group Structure dialog box</L.LABEL
><B.BODY>In this mode, the fields of the Edit Group Structure dialog box are used as follows:</B.BODY
><RBW-PARABODY>The Show button allows you select one or more item filters, and then updates the Contents list to show only those items added to the group using the selected filters. (To display all items added to the group using Item Filter mode, select all item filters.)</RBW-PARABODY
><B.BODY>The New Item Filter dialog box allows you to create an item filter. Select one or more of the options, which are described following the illustration.</B.BODY
> Select the Name check box and use Tcl global pattern matching to specify an item name. For example, to add all items whose names begin with client or are qualified by client, type <CX5FX5FINPUT>client*</CX5FX5FINPUT
>. To add only items qualified by client, type <CX5FX5FINPUT>client:*</CX5FX5FINPUT
> Select the Type check box and use Tcl global pattern matching to specify an item type. The following table lists the item types, which are case sensitive:</RBW-PARABODY
> Select the Property check box, specify a property name, and use Tcl global pattern matching to specify a property value.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See the Tcl documentation for details on Tcl global pattern matching.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using item filters</L.LABEL
><B.BODY>Adding and removing item filters is similar to adding and removing file items. Displaying the items added to the group using a particular item filter is similar to displaying the files added the group using a particular file filter.</B.BODY
><B.BODY>For details on these procedures, see <RBW-XREF REFID="26915" TYPE="XREF-TEXTCOPY">File Filter Mode</RBW-XREF
>Use File Selector mode to specify selection criteria that add files to the group based on what items are already in it.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Adding a file adds an item</SL.SUBLABEL
><B.BODY>When you add a file to the group, ObjectTeam also adds the item associated with it. For example, if you specify selection criteria that adds the CoreClasses CD to the group, the group contains</B.BODY
><RBW-PARABODY>The New button allows you to specify the selection criteria that add files to the group based on what items are already in the group.</RBW-PARABODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Any file that contains a parent component (for example, a superclass) that is attached to any of the items</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Any file that contains a leaf component (for example, a subclass) that is attached to any of the items</CELLBODY
><RBW-PARABODY>ObjectTeam adds to the group any file that is found in step 2 and that has a type specified in the File Types<CX5FX5FBULLET.EMPHASIS> </CX5FX5FBULLET.EMPHASIS
><RBW-PARABODY>Specify the file selection criteria. Then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam uses the file selection criteria and all other rules specified in all other modes of the Edit File Structure dialog box to update the contents of the group. It then updates the Contents list box to display all files and items in the group.</LR.LIST.RESULT
><RBW-PARABODY>Select one or more of the file selectors. Then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam removes the selected file selection criteria, uses the remaining file selection criteria and all other rules specified in all other modes of the Edit File Structure dialog box to update the contents of the group. It then updates the Contents list box to display all files and items in the group.</LR.LIST.RESULT
><RBW-PARABODY>The New button allows you to specify the selection criteria that add items to the group based on what files are already in the group.</RBW-PARABODY
><RBW-PARABODY>ObjectTeam adds to the group all the items in all of those files that match the criteria specified in the Type and Qualified boxes. The Qualified field for each item type can be Yes or Don’t Care.</RBW-PARABODY
><B.BODY>If the group contains the CDM file, Person, an item selector that specifies items of type de with the qualification Don’t Care returns all items of type de:</B.BODY
><RBW-PARABODY>Specify the item selection criteria. Then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam uses the item selection criteria, and all other rules specified in all other modes of the Edit File Structure dialog box to update the contents of the group. It then updates the Contents list to display all files and items in the group.</LR.LIST.RESULT
><RBW-PARABODY>Select one or more of the item selectors. Then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam removes the selected item selection criteria and uses the remaining item selection criteria and all other rules specified in all other modes of the Edit File Structure dialog box to update the contents of the group. It then updates the Contents list to display all files and items in the group.</LR.LIST.RESULT
>Creating Group Versions and SavedGroup Versions</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction </L.LABEL
><B.BODY>Groups have a special type of version control. The reason is that they are not so much a part of the hierarchical tree structure of the project, but rather a view of a selected part of the currently visible contents of a system. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Two version types</L.LABEL
><B.BODY>Group versions support two version types:</B.BODY
><RBW-PARABODY>SavedGroup version stores the names and versions of all files and items in the group.<RBW-IDXTERM TERM1="group" TERM2="saving contents of"></RBW-IDXTERM
><B.BODY>You need a group to make a SavedGroup. You need a SavedGroup to make a corporate group.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Group versions</L.LABEL
><B.BODY>Freezing a group version and creating a new one does not affect the members of the group. Only the settings of the explicit lists, filters, and selectors defined in the Edit Group Structure dialog box are part of the group. The main reason for freezing a group version is so that you can modify the composition of the group and be able to restore the original composition if necessary.</B.BODY
>Groups that are part of the current group are not frozen automatically. If you want to be able to restore the exact settings of the group structure, you must freeze the included groups also.</N.NOTE
><RBW-PARABODY>Select Copy Definition and/or Copy Contents and click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>Copy Definition copies the definition of the group to the new system. Copy Contents copies the actual contents the group. </LR.LIST.RESULT
>You can also import a group by dragging it to a system.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>SavedGroup versions</L.LABEL
><BI.BODY.INTRO>When you create a SavedGroup version, ObjectTeam stores a list of all objects in the group with their versions in the <saved groups> pseudo object. All objects in the group are frozen. </BI.BODY.INTRO
><B.BODY>The main reason for creating saved groups is to be able to easily retrieve earlier versions of diagrams, including their associated items and properties. Diagram versions do not include the items referenced in the diagram. If you want to be able to restore a diagram, and the items and item properties in it, create a saved group that contains the diagrams and the items and properties in the diagram. Restoring the saved group restores your diagram, including the items and properties. <RBW-IDXTERM TERM1="diagram" TERM2="and SavedGroup"></RBW-IDXTERM
><RBW-PARABODY>Select Version | Snapshot.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>A dialog box appears in which you can enter a comment, such as the reason the saved group was created. This comment appears in the Info dialog box.</LR.LIST.RESULT
><RBW-PARABODY>Enter a comment, and then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>In the <saved groups> pseudo object, ObjectTeam creates a saved group version with the same name as the group version and the contents of the group version are frozen.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Restoring a SavedGroup </L.LABEL
><B.BODY>When you restore a SavedGroup version, the object versions listed in the SavedGroup become the selected versions and appear in the information area. Other versions of these objects are unselected but still available.</B.BODY
><BI.BODY.INTRO>For files, the versions that were the selected versions when the SavedGroup was made, become the selected versions again. The items and their properties are overwritten by the items and properties as they were at the time the SavedGroup was created. The group composition, defined in the Edit Group Structure dialog box is not affected.</BI.BODY.INTRO
><B.BODY>By promoting a SavedGroup from system to corporate level, you create a corporate group. The group and its contents become available for use in all other projects. Together, these corporate groups form the corporate model.<RBW-IDXTERM TERM1="corporate modeling"></RBW-IDXTERM
>Because corporate groups are always created from SavedGroups, a corporate group and its contents are always frozen. </N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose</L.LABEL
><B.BODY>Corporate groups allow you to share design data among projects. One primary use of the corporate model is make one set of commonly used subsystems available to projects throughout the corporation. Doing so reduces both development time and maintenance time. Careful use of corporate groups can also promote standardization and stimulate reuse of design data.</B.BODY
><B.BODY>A corporate group can be created only from a SavedGroup; thus, ObjectTeam ensures that the corporate model is not changed arbitrarily. Conversely, a system always has a fixed link to a corporate group; thus, ObjectTeam ensures that changes to the corporate model do not change the system unexpectedly.</B.BODY
><RBW-IDXTERM TERM1="group" TERM2="promoting to corporate"></RBW-IDXTERM
>When you promote a SavedGroup to the corporate level, it becomes a corporate group. Creating a new version of the SavedGroup does not update the corresponding corporate group. If you want to replace the corporate group, you must promote the new version of the SavedGroup to the corporate level. This promotion ensures that the corporate model is not changed arbitrarily.</B.BODY
>The <saved groups> object is visible in two places: under the group itself or on the system level. The <saved groups> object under the group shows all saved group versions of that group. The <saved groups> object on the system level shows all saved group versions for all groups within the system.</N2.NOTE.2
><RBW-PARABODY>Specify a name for the corporate group and, optionally, a comment describing the group. Then select OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam makes the SavedGroup a corporate group. In the Information area of the Browser, under the heading <CX5FX5FPROCEDURE.NAME>In Corporate</CX5FX5FPROCEDURE.NAME
>, the status <CX5FX5FPROCEDURE.NAME>Yes</CX5FX5FPROCEDURE.NAME
> appears next to the file versions that make up this group version, indicating that these file versions are now part of the corporate model. The name of the corporate group is added to the pseudo object <corporate groups> on the corporate level.</LR.LIST.RESULT
><RBW-PARABODY>All file versions and items in the corporate group version are copied to the system. Conflicts between existing item generations in the system and item generations from the corporate group are solved by overwriting the existing item generations.</RBW-PARABODY
><RBW-PARABODY>A fixed link to the corporate group version is established. You cannot establish a dynamic link. If someone changes the corporate group, and you want those changes in your system, you must copy the corporate group into your system again. Doing so ensures that changes to the corporate model do not affect any system without warning.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>You cannot modify the properties of the files and items copied from the corporate group, but you can modify their scope.</B.BODY
><RBW-PARABODY>Select the corporate group that you want to use, and then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam adds references to the files (or groups) of the selected corporate group to the system,and then updates the information area of the Browser. All the files have fixed links and a status of reused.</LR.LIST.RESULT
><RBW-PARABODY>Select the corporate group that you want to remove, and then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam removes all references to the files or groups of the selected corporate group from the system,and then updates the information area of the Browser. </LR.LIST.RESULT
>Because the Cayenne repository is a shared resource, access control is particularly important. Using the features described in this chapter, the corporate administrator can give project members access to appropriate areas of the repository, restricting access to other areas.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>Your organization has project leaders, analysts, designers and programmers. You use the access control features to give the project leaders read/write access to the entire project, the analysts read/write access to the analysis phase, the designers read access to the analysis phase and read/write access to the design phase, and the programmers read access to the design phase and read/write access to the implementation phase.</B.BODY
> provides the menu items and Tcl code required to use the security and access control features of ObjectTeam. Therefore, this module must be active on the Browser levels where it is going to be used.</B.BODY
><B.BODY>You can check if a module is active on a particular Browser level by selecting Utilities | Show Active Modules on that level.</B.BODY
><RBW-PARABODY>At the corporate or project level, you create UserRoleLinks. A link between a user and a role indicates that the user has access to the role.</RBW-PARABODY
><RBW-PARABODY>ObjectTeam defines a set of actions for each object; for example, the set of actions for the system object includes Create and Destroy. </RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>For every object, you define a set of access rules that specifies, for every role and every action, whether the role can perform the action.</LT.LIST.TEXT
><B.BODY>If you know who the users of a project are going to be, what roles they must be able to play, and what access each role needs to have, you can use ObjectTeam’s automatic access control mechanism. This mechanism allows you to set up access control before the users of the project populate and use objects in it.</B.BODY
><B.BODY>You specify the Users, Roles, UserRoleLinks, and the allowed and prohibited actions on phase objects within a configuration version in two customization files. </B.BODY
><B.BODY>These files are the input for Security | Setup Access on the configuration level. This command creates users, roles, user role links, and access rules according to the specifications in the customization files.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See <RBW-XREF REFID="33041" TYPE="XREF-TEXTCOPY">How to Set up Access Control Automatically</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Managing the details</L.LABEL
><BI.BODY.INTRO>The combination of users, roles, and access rules allows you to control access to every object in the repository. ObjectTeam does not require that you specify access rules for every object in the repository. It helps you manage access rules by allowing you to use the repository’s class hierarchy to specify access rules at the level appropriate for your site. For example, you can specify a set of access rules at the project level to define access control for all objects in a project.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>The access control process</L.LABEL
><B.BODY>This illustration gives an overview of the relationships between the terms in the access control process. It does not explain the entire security process.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Names derived from the operating system users. By registering users in the repository with the same name as in the operating system, access can be controlled per user.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>A UserRoleLink between a role and a user means the user has access to the role. The status of a UserRoleLink determines whether the role is always activated, initially activated, or initially deactivated.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>An intermediate object between users and actions on objects. Object access is defined for roles. A user can activate one or more roles.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>A rule that defines whether a role is permitted to perform an action on an object. The collection of all access rules for an object and a role is a RoleRight. Access rules can be defined per object or per class of objects.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Every parent object in the repository has a controlled list for each of its child object types. When a child object is created, ObjectTeam adds that object to the appropriate controlled list on the parent object.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Your effective roles and the object’s role rights determine your access rights to an object</CELLBODY
>A childRight specifies the <CX5FX5FEMPHASIS>initial</CX5FX5FEMPHASIS
> role rights assigned to the objects added to the controlled list.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Version and configuration management</L.LABEL
><B.BODY>This chapter focuses on how to control access to objects using the access control mechanisms. However, it is important to note the access to object versions is also controlled through versions and configurations, as described in <RBW-XREF REFID="22309" TYPE="XREF-TEXTCOPY">Chapter 1, Version and Configuration Management</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><B.BODY>The repository should contain a user object for every person who uses ObjectTeam. During a session, the user object identifies the person using ObjectTeam.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>ObjectTeam users must match operating system users</L.LABEL
><B.BODY>Users do not log on to ObjectTeam, but they do log on to the operating system. When a user starts the Browser, ObjectTeam does the following:</B.BODY
><RBW-PARABODY>Enter the name of the new user, and then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam creates the user. It also creates a role with the same name as the user and makes it the user’s default role.</LR.LIST.RESULT
>The roles described in this chapter have no relation to the roles used to specify associations in Class Diagrams (CDs).</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose</L.LABEL
><B.BODY>Access to objects is based on roles. A user can activate one or more roles. Generally, if a certain role has access to an object and a user has that role active, the user has access to the object.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Roles that ObjectTeam defines</L.LABEL
><B.BODY>ObjectTeam creates the following special roles:</B.BODY
> When a user creates a repository, ObjectTeam creates a SuperUser role and a corporate&truehy;level UserRoleLink between the role and the user; the status of the UserRoleLink is defaultOn. The SuperUser role at corporate level has unrestricted access to all objects in the repository, can create users and roles, and can create UserRoleLinks at the corporate or project level.</RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>When a user creates a project, ObjectTeam creates a SuperUser role and a project&truehy;level UserRoleLink between the role and the user. The status for the UserRoleLink is defaultOff; the user activates the role when necessary. The SuperUser role at the project level has unrestricted access to all objects in the project and can create UserRoleLinks at the project level.</LT.LIST.TEXT
> When you create a new user, ObjectTeam creates a role with the same name and creates a corporate&truehy;level UserRoleLink between the role and the user. To ensure that the user’s default role is always activated, the status for the UserRoleLink is alwaysOn.</RBW-PARABODY
> Every repository contains a guest user, a guest role, and a corporate&truehy;level UserRoleLink between them. To ensure that the Guest role is always activated for a Guest user, the status for the UserRoleLink is alwaysOn. If an unknown user starts the Browser, ObjectTeam uses the Guest user and role for the session. </RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Roles that you define</L.LABEL
><B.BODY>You can define additional roles. Typically, the roles that you define are based on the job functions required for a project; for example, you can create the roles Analyst and Programmer.</B.BODY
><RBW-PARABODY>Enter the name of the new role, and then click OK. </RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam creates the role. To give a user access to this role, create a UserRoleLink between the user and the role, as described in <RBW-XREF REFID="19607" TYPE="XREF-TEXTCOPY">UserRoleLinks</RBW-XREF
><B.BODY>UserRoleLinks can be defined at the corporate or project level. UserRoleLinks defined at the project level supplement those defined at the corporate level.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose</L.LABEL
><B.BODY>UserRoleLinks define a link between a user and role. If such a link exists, the user has access to the role.</B.BODY
><B.BODY>The UserRoleLinks provide a many&truehy;to&truehy;many relationship between users and roles. That is, each user can have access to one or more roles, and each role can be accessed by one or more users.</B.BODY
><RBW-PARABODY>To examine corporate&truehy;level UserRoleLinks, move to the corporate level. To examine project&truehy;level UserRoleLinks, move to the project level.</RBW-PARABODY
>At the corporate level, you can examine the UserRoleLinks for a particular user. Open the <users> object, and then open the user that you are interested in. The information area lists all roles linked to this user; that is, it displays all UserRoleLinks for this user.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to create a UserRoleLink<RBW-IDXTERM TERM1="creating" TERM2="UserRoleLinks"></RBW-IDXTERM
><RBW-PARABODY>To create a corporate&truehy;level UserRoleLink, move to the corporate level. To create a project&truehy;level UserRoleLink, move to the project level.</RBW-PARABODY
><RBW-PARABODY>Select File | New | UserRoleLink(s). </RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>A dialog box appears with a list of all users not already linked to this role. If all users are already linked to this role, File | New | UserRoleLink is unavailable.</LR.LIST.RESULT
>You can change the status of your own UserRoleLinks, unless the status is alwaysOn. To change a status of alwaysOn or to change the status of another user’s UserRoleLink, you must have the SuperUser role activated.</N.NOTE
><RBW-PARABODY>To change the status of a corporate&truehy;level UserRoleLink, move to the corporate level. To change the status of a project&truehy;level UserRoleLink, move to the project level.</RBW-PARABODY
>The roles you have activated define your effective context, which determines your access to repository objects. If you have activated project&truehy;level roles, these roles are in your effective context only if you are at or below project level.</B.BODY
><B.BODY>Once you have specified roles, you can define role rights for each object. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role rights</L.LABEL
><B.BODY>ObjectTeam defines a set of actions for each object. To specify the role rights for an object, you specify, for each role and each action, whether the role can perform the action. </B.BODY
><B.BODY>The following illustration shows the dialog box that you use to specify the role rights for an object:</B.BODY
><B.BODY>ObjectTeam defines a set of valid actions for each type of object in the repository. Because you can control acess to each action, the actions are called controlled actions.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Controlled objects</L.LABEL
><B.BODY>You can specify role rights for every object in the repository. Any object for which role rights can be defined is called a controlled object.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Controlled classes and controlled lists</L.LABEL
><BI.BODY.INTRO>Specifying the role rights for every object in the repository would be a time&truehy;consuming and error&truehy;prone task. ObjectTeam provides two mechanisms that allow you to define role rights that controlled objects can inherit:</BI.BODY.INTRO
> allow you to define role rights for a class of objects. You can define role rights for controlled classes at the corporate or project level.</RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>For example, if you set the role rights for the controlled class, ConfigVersion, at the project level, every configuration version that you create in that project inherits those role rights.</LT.LIST.TEXT
> allow you to define role rights for an object’s child objects. Controlled lists are available only for objects that have child objects, this includes all objects that are under version control because each version is considered a child object.</RBW-PARABODY
> for examples of role rights on controlled lists.</LT.LIST.TEXT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Specifying role rights</L.LABEL
><B.BODY>Typically, the corporate administrator defines role rights on controlled classes and controlled lists at the corporate level. A project leader might modify the role rights on the controlled classes and controlled lists at the project level. Occassionally, a project leader or team member might modify the role rights for a controlled object to control access to that particular object.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section contains the following topics:</B.BODY
><B.BODY>On an object, each combination of role and action define an access rule. The set of access rules for an object are the object’s role rights.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role rights</SL.SUBLABEL
><B.BODY>You specify role rights for each object. For each role and each action, the role rights specify whether the role can perform the action.</B.BODY
><B.BODY>You view the access rights for each object. ObjectTeam uses your effective context and the object’s role rights to determine your access rights to the object.</B.BODY
><RBW-PARABODY>In the Objects list, if necessary, select the object whose role rights you want to edit. </RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>You can specify role rights for controlled objects, controlled classes, and controlled lists. (See <RBW-XREF REFID="42612" TYPE="XREF-TEXTCOPY">Controlled Objects</RBW-XREF
><RBW-PARABODY>In the Actions list, specify one of the following permissions for each action:<RBW-IDXTERM TERM1="access rule" TERM2="permissions"></RBW-IDXTERM
><LR.LIST.RESULT>ObjectTeam updates the object’s role rights. (See <RBW-XREF REFID="20462" TYPE="XREF-TEXTCOPY">How ObjectTeam Evaluates Access Rights</RBW-XREF
> for an explanation of how ObjectTeam uses the role rights to determine whether a user has access to an object.)</LR.LIST.RESULT
><RBW-PARABODY>Select Security | Role Rights | Show.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The Show Role Rights dialog box appears. This dialog box is similar to the Edit Role Rights dialog box shown in the previous section.</LR.LIST.RESULT
><RBW-PARABODY>Select Security | Show Access Rights</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The object’s access rules appear in the Show Access Rights dialog box.</LR.LIST.RESULT
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Not all access rules are stored in the repository</SL.SUBLABEL
><B.BODY>ObjectTeam stores all access rules that allow or prohibit an action. If one or more actions are allowed or prohibited for a role, ObjectTeam stores all the access rules for that role. If all actions for a role are undefined, ObjectTeam does not store access rules for that role.</B.BODY
><B.BODY>For example, in the Edit Role Rights dialog box shown earlier in this section, no action is allowed or prohibited for the docu role. If, for example, the destroyAction were prohibited for the docu role, eight access rules for the docu role would be stored , one for each valid action.</B.BODY
><B.BODY>For each object type, ObjectTeam defines a set of actions; for example, actions for the Project object include create and destroy. These actions are called controlled actions because you can specify access control rules for them.</B.BODY
><B.BODY>The controlled actions for an object type are defined by ObjectTeam and cannot be changed.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to view an object’s controlled actions</L.LABEL
><B.BODY>The Edit Role Rights, Show Role Rights, and Show Access Rights dialog boxes, as described in <RBW-XREF REFID="19555" TYPE="XREF-TEXTCOPY">Role Rights, Access Rules, and Access Rights</RBW-XREF
>, also include this information. They list all controlled actions; the actions that do not apply to the selected object appear dimmed.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Controls access to all other actions. If a role is allowed this action, it can change the permissions of other actions; otherwise, the role cannot change permissions of other actions.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Applies to controlled classes. By setting rights to this action you can control whether someone can make a particular controlled object. For example, if create for controlled class ConfigurationVersionList is set to denied, the user cannot make any new configuration versions.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Applies to all objects and controls a user’s ability to change some property of an object, including its status. For example, without modify rights to a system version object, a user cannot make a new version of that system version or edit its properties.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>This applies to controlled lists and controls a user’s rights to insert object in that list, that is, to make new versions of an object. For example without insert rights to a SystemVersionList, a user cannot add any objects to that list and make a new version of a particular system.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Applies to version of objects. It controls the ability to freeze objects, and thus change their status.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Applies to versions of objects. It controls the ability to change the status of objects. For example, you could prevent a user from changing the status of an object version from fixed to dynamic frozen.</CELLBODY
><RBW-IDXTERM TERM1="object" TERM2="role rights for class of"></RBW-IDXTERM
><RBW-IDXTERM TERM1="role right" TERM2="for class of object"></RBW-IDXTERM
></SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>The role rights that you specify for a controlled class apply to all objects of that type. This provides an easy way to specify role rights for a large number of objects at one time.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Conflicts</SL.SUBLABEL
><B.BODY>If you specify role rights on a controlled class and an object of that type, ObjectTeam uses the most restrictive access control rules to determine access rights. Thus, if an action is prohibited on either the controlled class or the object, ObjectTeam prohibits the action.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The controlled class GroupVersion is defined at the project level. In the role rights for the controlled class GroupVersion, you prohibit the destroyAction for the tester role. All group versions in the project now have the role rights for the controlled class GroupVersion. The tester role cannot delete a group version from the project.</B.BODY
>When you specify the role rights for a controlled class, ObjectTeam does not change the role rights for all objects of that type. However, when evaluating access rules for an object, ObjectTeam checks the role rights of its controlled class.</N.NOTE
><RBW-PARABODY>Select a Role from the Roles list.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>Under Actions the role rights of the selected controlled class are now displayed. </LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</L.LABEL
><B.BODY>For more information about role rights, access rules, access rights, and the procedures used to view and specify them, see <RBW-XREF REFID="19555" TYPE="XREF-TEXTCOPY">Role Rights, Access Rules, and Access Rights</RBW-XREF
>Any object for which you can define role rights is called a controlled object. The role rights that you specify for a controlled object apply only to that object, which allows you to limit access to it.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Conflicts</SL.SUBLABEL
><B.BODY>If you specify role rights on both a controlled class and a controlled object of that type, ObjectTeam uses the most restrictive role rights to determine the user’s access rights. Thus, if an action is prohibited on either the class or the object, ObjectTeam prohibits the action.</B.BODY
><RBW-PARABODY>All actions for all other roles are undefined.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The controlled class GroupVersion is defined on the project level. In the role rights for the controlled class GroupVersion, you allow the destroyAction for the tester role. However, for the controlled object myGroupVersion, you prohibit the destroyAction for the tester role. The tester role can delete any group version from the project except myGroupVersion.</B.BODY
><RBW-PARABODY>Select Security | Show Access Rights.</RBW-PARABODY
></LN.LIST.NUM
><LRS.LIST.RESULT.SINGLE>The Show Access Rights dialog box appears, displaying your access rights to the object based on your effective context.</LRS.LIST.RESULT.SINGLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</L.LABEL
><B.BODY>For more information about role rights, access rules, access rights, and the procedures used to view and specify them, see <RBW-XREF REFID="19555" TYPE="XREF-TEXTCOPY">Role Rights, Access Rules, and Access Rights</RBW-XREF
>In ObjectTeam, a parent object has a controlled list for each of its child object types. When you create a child object, ObjectTeam adds it to the appropriate controlled list on the parent object.</B.BODY
><B.BODY><RBW-IDXTERM TERM1="version" TERM2="access control for"></RBW-IDXTERM
>For example, each system object has a controlled list, SystemVersionList. When you create a new version of the system, ObjectTeam adds the system version to SystemVersionList. Similarly, each project object has a controlled list, ConfigList. When you add a configuration to the project, ObjectTeam adds the configuration object to ConfigList.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Two types of role rights</L.LABEL
><B.BODY>For each controlled list, you specify two types of role rights: </B.BODY
>ownRight determines who can add objects to or remove objects from the controlled list. You use ownRight role rights to control who creates and deletes child objects.</RBW-PARABODY
>childRight specifies the initial role rights assigned to the objects added to the controlled list. You use childRight role rights to define the initial role rights of child objects.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Naming conventions for controlled lists</L.LABEL
><B.BODY>The following naming convention identifies the contents of each list:</B.BODY
>LinkList lists links between versions of the parent object and versions of the child object.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>The links created and entered into this list are not immediately visible in the Browser. For example, the object that links a phase version and a system version does not appear in the Browser. However, Browser operations often affect the links created and entered into this list. For example, when you change the link status of a system version from fixed to dynamicFrozen you are changing the property of the link object.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>List of controlled lists</L.LABEL
><B.BODY>The following table lists all parent objects and their controlled lists.</B.BODY
><B.BODY>The following example shows how to use a controlled list that contains child objects other than object versions. On the controlled list, ConfigList, you specify the following role rights:</B.BODY
><RBW-PARABODY>childRight: no permissions specified</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>These settings ensure that only you can create Configuration versions in the project (you are the only one who can insert configurations into the ConfigList). They ensure that there are no special restrictions on the Configurations that you create.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example 2</L.LABEL
><B.BODY>The following example shows how to use a controlled list that contains object versions. On the controlled list, PhaseVersionList, you specify the following role rights:</B.BODY
><RBW-PARABODY>childRight: allows the freezeAction for the QA&truehy;Manager role</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>This ensures that anyone can create a new phase version (there are no special restrictions on the PhaseVersionList). However, only the QA&truehy;Manager role can freeze the phase versions that are created.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example 3</L.LABEL
><B.BODY>The following example shows how to use a controlled list that contains links between object versions. On the controlled list, PhaseSystemLinkList, you specify the following role rights:</B.BODY
><RBW-PARABODY>childRight: allows the modifyAction for your default role</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>This ensures that only you can add a system version to the phase, either by adding a new system to the phase or by creating a new version of a system already in the phase. When a new system version is added, a link between the phase version and the system version must also be added to the PhaseSystemLinkList. You are the only user who can insert a link into that controlled list.</B.BODY
><B.BODY>It also ensures that, once the link is created, you are the only who can modify it. In this case, for example, you are the only who can change the link status of the system version.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Controlled classes versus ownRights of controlled lists</L.LABEL
>Because every controlled list is an object, a controlled class exists for every controlled list. Specifying the role rights on the controlled class (for the controlled list) affects every controlled list of that type. Specifying the ownRole rights on the controlled list affects only that particular controlled list.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>For example, setting the insertAction for the controlled class SystemList (defined at project level) sets the insertAction of every SystemList in the project. These settings control who can add systems to the project. Setting the insertAction for the ownRights role rights of the controlled list SystemList (defined at the phase level) affects only this list. This controls who can add systems to the phase.</B.BODY
>If the controlled class affects only one controlled list, then specifying the role rights of the controlled class has the same effect as specifying the ownRights of that one controlled list. For example, a project has only one ConfigList. Specifying the role rights of the controlled class ConfigList (defined at the project level), has the same effect as specifying the ownRights of the controlled list ConfigList (defined at the project level).</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Controlled classes versus childRights of controlled lists</L.LABEL
>There are two significant differences between setting childRight role rights on a controlled list and setting role rights on a controlled class:</B.BODY
><RBW-PARABODY>The childRight role rights on a controlled list define the initial role rights for each object added to the list. Changing the childRight role rights on a controlled list has no effect on existing objects.</RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>The role rights on a controlled class define the role rights for all objects of that type. Changing the role rights on a controlled class changes the role rights for all objects of that type.</LT.LIST.TEXT
><RBW-PARABODY>Control classes are defined at the corporate and project level. Many controlled lists are defined at lower levels.</RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>For example, the controlled class System is defined at the project level. Specifying role rights on the controlled class System defines the role rights for every system in the project. The controlled list SystemVersionList is defined at the sytem level. Specifying childRight role rights on the controlled list SystemVersionList defines the initial role rights for every version of that particular system.</LT.LIST.TEXT
><RBW-PARABODY>To specify the role rights for a controlled list, select the object, then select Security | Role Rights | Edit.</RBW-PARABODY
></P.PROCEDURE
><LRS.LIST.RESULT.SINGLE>The Edit Role Rights dialog box appears. Use the Type box in the dialog box to select ownRight or childRight.</LRS.LIST.RESULT.SINGLE
><RBW-PARABODY>To view the role rights for a controlled list, select the object, and then select Security | Role Rights | Show.</RBW-PARABODY
></P.PROCEDURE
><LRS.LIST.RESULT.SINGLE>The Show Role Rights dialog box appears. Use the Type box of the dialog box to select ownRight or childRight.</LRS.LIST.RESULT.SINGLE
><RBW-PARABODY>To view your access rights for a controlled list, select the object, and then select Security | Show Access Rights.</RBW-PARABODY
></P.PROCEDURE
><LRS.LIST.RESULT.SINGLE>The Show Access Rights dialog box appears, displaying your access rights to the object based on your effective context.</LRS.LIST.RESULT.SINGLE
>Your access rights are based on the ownRights of the controlled list. The childRights of the controlled list do not affect your access rights to the controlled list.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</L.LABEL
><B.BODY>For more information about role rights, access rules, access rights, and the procedures used to view and specify them, see <RBW-XREF REFID="19555" TYPE="XREF-TEXTCOPY">Role Rights, Access Rules, and Access Rights</RBW-XREF
>Because a user’s effective context is dynamic (that is, the user can activate and deactivate roles), the user’s access rights for any repository object are also dynamic. Every time you carry out an action on an object, ObjectTeam checks your access rights to that object.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Most restrictive role rights are used</L.LABEL
><B.BODY>ObjectTeam always uses the most restrictive role rights to define access rights. For example, if an action is allowed for one active role and prohibited for another active role, ObjectTeam prohibits the action.</B.BODY
><RBW-PARABODY>Checks for SuperUser in your effective context. If SuperUser is in your effective context, the action is allowed regardless of which access rules are specified for this object.</RBW-PARABODY
><RBW-PARABODY>Checks the class of the object to determine whether you have access to the action. The action is prohibited in the following cases:</RBW-PARABODY
><RBW-PARABODY>Checks the object to determine whether you have access to the the action. The action is prohibited in the cases shown in step 2.</RBW-PARABODY
>Suppose the user Fred and the role ProjectMember exist at the corporate level. The project manager creates a UserRoleLink between Fred and ProjectMember with a status of defaultOff. Fred now has two UserRoleLinks: his default role, Fred, and the role ProjectMember. Fred has not activated the ProjectMember role, so only his default role is in his effective context. </B.BODY
><BI.BODY.INTRO>Fred enters the command to freeze his current configuration version. ObjectTeam checks his access rights as follows:</BI.BODY.INTRO
><B.BODY>Now, the project manager adds an access rule to the controlled class ConfigVersion that allows the freezeAction for the ProjectMember role. Fred, still without the ProjectMember role in his effective context, again enters the command to freezes his current configuration version. ObjectTeam checks his access rights as follows:</B.BODY
><B.BODY>Because user Joe is not a registered user in the repository he has only the role Guest in his effective context. Users Jill and Jim are both registered users. Jill has the roles Jill and ProjectMember in her effective context. Jim has the roles Jim and Analyst in his effective context.</B.BODY
><RBW-PARABODY>Joe cannot read Obj2, because a role right prohibits the action for role Guest, which is in Joe’s effective context. Jill and Jim can read Obj2 because they do not have Guest in their effective contexts, and no role right allows read access for any role.</RBW-PARABODY
><RBW-PARABODY>Only Jill can modify the access rules on Obj1 and Obj2, because the role rights on the objects allow the action for the role Jill, and she is the only with that role in her effective context. </RBW-PARABODY
><RBW-PARABODY>Only Jill can freeze Obj1 and Obj2, because the role rights on class Cl explictly allow the action for the role ProjectMember, and she is the only user with that role in her effective context.</RBW-PARABODY
>How to Set up Access Control Automatically</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>If you know who the users of a project are, what roles they should be able to play, and which access these Roles need to have, you can use ObjectTeam’s automatic access control mechanism.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Automatic Access Control mechanism</L.LABEL
><B.BODY>You can use the automatic access control mechanism to:</B.BODY
> on the corporate level contains an example specification of access rights for the Roles ProjectManager, Analyst, Designer, Programmer, Tester, and QA&truehy;Officer.</B.BODY
><EWM.EXAMPLEW.MONO> ...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> # Role Name | Phase Name | Access Rights</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO></EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> ProjectManager | * | M C R U D</EWM.EXAMPLEW.MONO
><B.BODY>The phase for which you specify the role’s access rights. You can use the special characters for Tcl glob style pattern matching in the phase names, such as asterisks (*). Use just one asterisk to specify the role’s access rights for all phases.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Access Rights</SL.SUBLABEL
><B.BODY>This field contains a subset of the values M, C, R, U and D. With these values you can set certain controlled actions to Allowed or Prohibited for the role in the specified phase:</B.BODY
> file (see, for example, the roles Analyst, Designer and Programmer) shows that certain controlled actions can be set implicitly to Prohibited for all phases and set explicitly to Allowed for one or more specific phases. </B.BODY
> on the corporate level contains an example specification of UserRoleLinks for the Roles ProjectManager, Analyst, Designer, Programmer, Tester, and QA&truehy;Officer. However, no users are defined:</B.BODY
><EM.EXAMPLE.MONO>...</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO># Role Name&rbwtab;&rbwtab;&rbwtab;| Users</EM.EXAMPLE.MONO
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>The users allowed to activate the role, but for whom the role will not be activated initially</CELLBODY
>Users whose names do not appear in the Users box are not allowed to activate the corresponding Role.</N.NOTE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The following example distributes the Roles ProjectManager, Analyst, Designer, Programmer, Tester and QA&truehy;Officer over the users joe, john, mary, paula, jim and bob.</B.BODY
><EM.EXAMPLE.MONO>...</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO># Role Name&rbwtab;&rbwtab;&rbwtab;| Users</EM.EXAMPLE.MONO
><B.BODY>Joe has all roles except QA&truehy;officer in his effective context. Bob has only one role, QA&truehy;Officer. John and Mary each have the two roles Analyst and Designer. Mary plays the Designer role and will be able to play the Analyst role too. Paula has two roles, Programmer and Tester. Jim has only one role, Tester.</B.BODY
>Use Security | Show Effective Roles to see your effective roles. Use Security | Activate Role to make the SuperUser role part of your set of effective roles, you are allowed to do so.</T2.TIP.2
><RBW-PARABODY>Restart the ObjectTeam Browser.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The access control rules as defined in the customization files roles.roles and userroles.userrroles are now in effect.</LR.LIST.RESULT
> requires the module <CX5FX5FEMPHASIS>Persistent properties</CX5FX5FEMPHASIS
> and one module of type <CX5FX5FEMPHASIS>CodeGeneration</CX5FX5FEMPHASIS
>. You select a code generation module from a dialog box. Depending on the code generation module you select, new dialog boxes appear from which you are to select a module.</B.BODY
><B.BODY>These are the modules required to run the tool for importing .var files and exporting ObjectTeam class models:</B.BODY
><B.BODY>This section describes how to import Cayenne GroundWorks .var files into ObjectTeam.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose</L.LABEL
><B.BODY>Importing a GroundWorks data model into ObjectTeam allows you to use the Entity Relationship Diagrams (ERDs) created in GroundWorks as a starting point for the Class Diagrams (CDs) in ObjectTeam.</B.BODY
>This tool is not designed to maintain synchronized versions of the GroundWorks and ObjectTeam models.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What is converted</L.LABEL
><B.BODY>This tool converts GroundWorks entities, entity type hierarchies, attributes, and relationships to ObjectTeam classes, class hierarchies, attributes, and associations. These are the primary objects used for modeling and code generation in ObjectTeam.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What is not converted</L.LABEL
><B.BODY>The following GroundWorks objects are not converted: allowed value tables, business subject areas, free attributes, keywords, maps, notes, process models, process specification diagrams, and synonyms.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How it works</L.LABEL
><B.BODY>ObjectTeam reads in a .var file and converts it into a combination of CD and CDM files. In the process:</B.BODY
><RBW-PARABODY>Dimensions and domains are converted into attribute data types (either standard data types or classes representing user&truehy;defined data types).</RBW-PARABODY
><LR.LIST.RESULT>The Reverse Engineer VAR dialog box appears. The following illustrations show both the Windows and UNIX dialogs. In Windows, use the File Name and Files of Type fields to filter the list of files displayed. On UNIX systems,use the Filter Field and Filter button to filter the list of files displayed.</LR.LIST.RESULT
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>If selected, separate CDs are generated for classes that exceed the maximum size. </CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Max Class Width & Height</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a class. When a class exceeds this size, it is folded.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Max Tree Width & Height</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a class tree. When a class hierarchy exceeds this size, it is split.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a diagram. When a diagram exceeds this size, a new diagram is created.</CELLBODY
><B.BODY>This section describes the conversion of GroundWorks entities and their attributes. The conversion of entity relationships is described in <RBW-XREF REFID="36211" TYPE="XREF-TEXTCOPY">Relationships and Partnership Sets</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Conversion of entities</L.LABEL
><B.BODY>When you import a .var file, each entity is converted to a class.</B.BODY
><RBW-PARABODY>The class’s Persistent class property is set. This property is visible only in the Object Design phase and only if the target language for code generation (as defined by the active ObjectTeam code generation module) supports persistent code generation.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Entity type hierarchy</SL.SUBLABEL
><B.BODY>An entity type hierarchy is converted to a class hierarchy. All classes in the hierarchy are defined in a single CD named <CX5FX5FTERM>superentity</CX5FX5FTERM
>Tree.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Conversion of attributes</L.LABEL
><BI.BODY.INTRO>When you import a .var file, each entity attribute is converted to an attribute in the generated class.</BI.BODY.INTRO
><RBW-PARABODY>The dimension/domain of the entity attribute is used to determine the data type of the generated attribute (see <RBW-XREF REFID="30182" TYPE="XREF-TEXTCOPY">Data type mappings</RBW-XREF
>). Subdomains are converted as described in <RBW-XREF REFID="32421" TYPE="XREF-TEXTCOPY">Subdomains</RBW-XREF
><RBW-PARABODY>If the entity attribute’s Nulls Allowed field is selected, the Nullable property of the class attribute is set to Default (indicating that Nulls are allowed); otherwise, the Nullable property of the generated attribute is set to No.</RBW-PARABODY
><RBW-PARABODY>If the entity attribute’s Source Type field is set to derived, the name of the generated attribute begins with a slash (/).</RBW-PARABODY
><RBW-PARABODY>Shared attributes are converted as top&truehy;level entity attributes, not as component attributes.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Conversion of methods</L.LABEL
><B.BODY>GroundWorks methods are not imported into ObjectTeam. But if an entity has exactly one attribute or exactly one relationship, the generated class includes one method: a $create operation.</B.BODY
><B.BODY>An ObjectTeam class that has exactly one attribute or relationship is a <CX5FX5FTERM>typedef class</CX5FX5FTERM
>; these classes are treated specially by ObjectTeam’s code generators. Adding the $create operation to the class ensures that the generated class is not a typedef class.</B.BODY
>For character fields, <CX5FX5FTERM>length</CX5FX5FTERM
> is the maximum length of the character field, as specified on the Domain form. If the maximum length is 1 (the default), <CX5FX5FTERM>length</CX5FX5FTERM
> is not included in the ObjectTeam data type.</N.NOTE
><RBW-PARABODY>In GroundWorks models, you read the optionality of a relationship from the partnership set at the <CX5FX5FEMPHASIS>near end</CX5FX5FEMPHASIS
> of the relationship and the multiplicity of the relationship from the <CX5FX5FEMPHASIS>far end</CX5FX5FEMPHASIS
><RBW-PARABODY>In ObjectTeam models, you read both the optionality and the multiplicity of the relationship from the <CX5FX5FEMPHASIS>far end</CX5FX5FEMPHASIS
> of the relationship.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>The following table summarizes these differences:</B.BODY
><B.BODY>Each relationship between two entities is converted to the ObjectTeam notation. In ObjectTeam, the relationship appears in the CD of the <CX5FX5FEMPHASIS>source entity</CX5FX5FEMPHASIS
><B.BODY>IOR relationships are converted to multiple relationships. From the perspective of the entity that owns the IOR partnership set, all of the generated relationships are <CX5FX5FEMPHASIS>optional</CX5FX5FEMPHASIS
>Typically, the entity that owns the IOR partnership set is the source entity for all the IOR relationships; therefore, all relationships generated for the IOR relationship typically appear in one CD.</N.NOTE
>The rel partnership set on the entor entity becomes two rel roles associated with the entor class. To prevent naming conflicts, the roles are named rel and rel2.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Conversion of XOR relationships</L.LABEL
><B.BODY>ObjectTeam does not distinguish between IOR and XOR relationships when importing a .var file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Conversion of AND relationships</L.LABEL
><B.BODY>AND relationships are converted to multiple relationships. From the perspective of the entity that owns the AND partnership set, all the generated relationships are <CX5FX5FEMPHASIS>mandatory</CX5FX5FEMPHASIS
>Typically, the entity that owns the AND partnership set is the source entity for all the AND relationships; in this case, all relationships generated for the AND relationship appear in one CD.</N.NOTE
>The rel partnership set on the entand entity becomes two rel roles associated with the entand class. To prevent naming conflicts, the roles are named rel and rel2.</N.NOTE
><B.BODY>This section describes the conversion of owner attributes and their component attributes. The conversion of subdomains (see <RBW-XREF REFID="32421" TYPE="XREF-TEXTCOPY">Subdomains</RBW-XREF
>) is similar.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Conversion of component attributes</L.LABEL
><B.BODY>When you import a .var file, each owner attribute is converted to a class named <CX5FX5FTERM>attrName</CX5FX5FTERM
>_Type. Component attributes are converted to attributes in the <CX5FX5FTERM>attrName</CX5FX5FTERM
><RBW-PARABODY>Attribute details (dimension, domain, description, nulls allowed, and source type) are converted as described in <RBW-XREF REFID="11577" TYPE="XREF-TEXTCOPY">Basic Conversion</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Source ERD</SL.SUBLABEL
><BI.BODY.INTRO>The following ERD has been edited slightly; in GroundWorks, component attributes are not indented.</BI.BODY.INTRO
><RBW-PARABODY>A one&truehy;to&truehy;one relationship connects the superdomain class with the class of the attribute’s owner entity (or owner attribute).</RBW-PARABODY
></LB2.LIST.BULLET.2
><LT2.LIST.TEXT.2>Each owner entity (owner attribute) must have exactly one superdomain class; each superdomain class may have zero or one owner entities (owner attributes).</LT2.LIST.TEXT.2
><RBW-PARABODY>Other attribute details (description, nulls allowed, and source type) are converted as described in <RBW-XREF REFID="11577" TYPE="XREF-TEXTCOPY">Basic Conversion</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Source ERD</SL.SUBLABEL
><B.BODY>The following illustration shows an entity with two attributes. The domain of the name attribute is the fullname domain, which has two subdomains: firstname and lastname.</B.BODY
><B.BODY>This chapter describes how to export an ObjectTeam (persistent) class model to a GroundWorks data model.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose</L.LABEL
><B.BODY>Exporting an ObjectTeam (persistent) class model allows you to use the Class Diagrams (CDs) and corresponding Class Definition Matrices (CDMs) created in ObjectTeam as a starting point for the Entity Relationship Diagrams (ERDs) in GroundWorks.</B.BODY
>This tool is not designed to maintain synchronized versions of the ObjectTeam and GroundWorks models.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Persistent classes</L.LABEL
><B.BODY>The module GroundWorks (VAR) Interface, that needs to be active in order to export GroundWorks <CX5FX5FFILE.NAME>.var</CX5FX5FFILE.NAME
> files, requires another module, called Persistent Properties. The latter module allows you to specify a class in a CD as persistent, using the class property Persistent.</B.BODY
><B.BODY>If SQL code is generated in ObjectTeam for persistent classes, ObjectTeam builds up an SQL model. This model is used to translate CD and CDM data to SQL tables, columns, and relationships. The same model is used to export persistent ObjectTeam classes to a GroundWorks <CX5FX5FFILE.NAME>.var</CX5FX5FFILE.NAME
> file.</B.BODY
><B.BODY>The following classes (and group of classes) from the SQL Model are used to generate <CX5FX5FFILE.NAME>.var</CX5FX5FFILE.NAME
><CHAPTERNONUM><CN.CHAPTER.NOX23>How to Use This Manual<RBW-SYSOBJ TYPE="MIFmarker"><RBW-DATAFLD TYPE="number">0</RBW-DATAFLD
><RBW-TEXTFLD TYPE="text">Object Team - Ada Professional Developers Toolkit</RBW-TEXTFLD
></RBW-SYSOBJ
></CN.CHAPTER.NOX23
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>About this manual</L.LABEL
><B.BODY>ObjectTeam provides code generation tools that enable you to generate object&truehy;oriented code for a range of object&truehy;oriented programming languages. This guide focuses on Ada 83 and Ada 95 as target languages. </B.BODY
><B.BODY>This manual explains the following things:</B.BODY
><RBW-PARABODY>How you can customize the default code generation process.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisites</L.LABEL
><B.BODY>This book assumes a basic knowledge of ObjectTeam, including familiarity with the information provided in the <CX5FX5FTITLE>ObjectTeam Getting Started</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> and <CX5FX5FTITLE><CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
></CX5FX5FTITLE
>.</B.BODY
><B.BODY>Furthermore, knowledge of Ada 83 or Ada 95 is necessary to understand the constructions generated from the Class Diagrams. You also need this knowledge to complete the generated code.</B.BODY
><B.BODY>If you plan to customize the default code generation process, you should be familiar with Tcl and the object&truehy;oriented extensions to Tcl supplied with ObjectTeam. For details on Object Tcl, refer to the <CX5FX5FTITLE>ObjectTeam Programming Interface Guide</CX5FX5FTITLE
><RBW-TEXTFLD TYPE="text">ObjectTeam - Ada Professional Developers Toolkit</RBW-TEXTFLD
></RBW-SYSOBJ
></C.CHAPTER.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This chapter introduces the concepts and procedures used by the ObjectTeam Ada Professional Developers Toolkit.</B.BODY
><B.BODY>The chapter introduces the concepts of code generation, synchronized engineering, and reverse&truehy;engineering. Short examples are provided of each.</B.BODY
><B.BODY>This manual assumes a moderate understanding of how to use ObjectTeam, the Unified Modeling Language (UML) notation, and the Ada 83 or Ada 95 programming languages.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
>What is the ObjectTeam Ada Professional Developers Toolkit?</L.LABEL
><B.BODY>The ObjectTeam Ada Professional Developers Toolkit (<RBW-IDXTERM TERM1="APDT" TERM2="What is it?"></RBW-IDXTERM
>APDT) is a suite of tools providing ObjectTeam with code generation, synchronous engineering, and reverse&truehy;engineering capability for the Ada 83 and Ada 95 programming languages.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Terms</L.LABEL
><B.BODY>Here is a short description of key concepts used throughout this manual:</B.BODY
> (or forward engineering) is generating source code from design models. Code re&truehy;generation, or the ability to generate code taking into account previously generated and modified code is a key part of “synchronized engineering”.</RBW-PARABODY
> is the process of step&truehy;wise refinement of both design (UML) and source code, with both kept in synch with the other. In practice, this requires that changes to the code automatically be represented in the design, and that changes to the design incorporate previously generated and modified code. </RBW-PARABODY
> is generating design models from code for the sole purpose of loading in design objects needed by new elements for referral or documenting purposes. </RBW-PARABODY
><RBW-PARABODY>Populate ObjectTeam design models with representations of existing code so that “as built” documentation can be produced with ObjectTeam documentation tools.</RBW-PARABODY
><RBW-PARABODY>Load design representations of existing code into design models that can then be referred to (or re&truehy;used) when designing new systems.</RBW-PARABODY
><RBW-TEXTFLD TYPE="text">Ada Professional Developers Toolkit</RBW-TEXTFLD
></RBW-SYSOBJ
>code generation in ObjectTeam is the process of translating diagrams into program code. The ObjectTeam APDT translates the Class Diagrams and their related Class Definition Matrices into Ada specification and body files. Code generation involves the following steps:</B.BODY
><RBW-PARABODY>The APDT translates the Class Diagrams and the Class Definition Matrices that are stored in the repository into a Code Generation model.</RBW-PARABODY
><RBW-PARABODY>This Code Generation model is translated into Ada source code.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>During design, you define a class more precisely by specifying its features, such as attributes and methods, relationships with other classes and inheritance:</B.BODY
><B.BODY>Here is an example Ada specification, automatically generated for the class “Address” from the above example. Note that to save space, some white space has been removed from this code (and all code used in this manual).</B.BODY
><EWM.EXAMPLEW.MONO>&truehy;&truehy; Specification file for Address</EWM.EXAMPLEW.MONO
>Synchronized engineering refers to incremental development that keeps design and implementation synchronized. In practice it means being able to generate code, change the code, bring that changed code back into ObjectTeam, make changes in the design, and to then generate code again (with the existing code being re&truehy;used).</B.BODY
><B.BODY>Synchronized engineering involves these steps:</B.BODY
>In the current version of APDT, only code that was originally generated by the APDT may be used in a synchronized engineering manner.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changing the source code</L.LABEL
><B.BODY>In the prior example of automatically generated Ada code, the source code is sprinkled with comments looking like <CX5FX5FTERM>“&truehy;&truehy;OT Ignore” </CX5FX5FTERM
>. These comments are indicators of where the generated source code can be changed without affecting the synchronization. </B.BODY
><B.BODY>After a <CX5FX5FTERM>“&truehy;&truehy;OT Ignore”</CX5FX5FTERM
> comment, you may add your implementing and/or non&truehy;design affecting code.</B.BODY
><B.BODY>After a <CX5FX5FTERM>“&truehy;&truehy;OT Analyze”</CX5FX5FTERM
> comment, you may still add or modify code, but you must take into account that the APDT will attempt to synchronize these changes into the ObjectTeam model used to generate the original source code. These kinds of changes can be made:</B.BODY
><RBW-PARABODY>Add or alter comments describing the purpose of each design entity</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>If you make changes where it will affect design, then the APDT will update the appropriate class definition matrices (CDM), or create new CDMs if new classes have been introduced by the code changes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changing the ObjectTeam Design</L.LABEL
><B.BODY>After the altered source code and the ObjectTeam design have been brought into synch, it’s then possible to continue with design adaptations.</B.BODY
><B.BODY>Similar kinds of changes are permitted:</B.BODY
><RBW-PARABODY>Creation of new relationships or generalizations</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>It is possible to make changes in the design that then makes existing code obsolete. For instance, one could remove a method, or delete a class.</B.BODY
><B.BODY>Changes such as this result in a code section at the bottom of a re&truehy;generated source file surrounded by the comments:</B.BODY
>Reverse engineering is not the process of importing code so that it can be maintained from within ObjectTeam. The APDT code generator cannot merge changes made in ObjectTeam diagrams with the existing code used to create those diagrams.</N.NOTE
> and <CX5FX5FEMPHASIS>Ada95 Code Generation </CX5FX5FEMPHASIS
>provide the menu items, the properties and the Tcl code required to use the Ada Professional Developer’s Toolkit. Therefore, before moving to the Object Design phase, make sure the Ada Code generation module of your choice is active.</B.BODY
><B.BODY>You can check if a module is active on a particular Browser level by selecting Utilities | Show Active Modules on that level.</B.BODY
> for details on how to activate a module.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Object Design and Implementation </L.LABEL
><B.BODY>This chapter describes the tasks of the Object Design phase. Chapter 3, Building an Ada Application, Chapter 4, Mapping Modeling Data to Ada 95 Code , and Chapter 5, Mapping Modeling Data to Ada 83 Code describe the tasks of the Implementation phase. Chapter 6, Synchronized Engineering describes incremental development and synchronized engineering. You work iteratively in these phases to generate code and complete your application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose of object design</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="Object Design" TERM2="activities in this phase"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Object Design" TERM2="development phase in ObjectTeam project"></RBW-IDXTERM
>In ObjectTeam, the CDs (and the objects defined in the CDs) provide all the source data needed for code generation. The goal of object design is to add to the CDs all the data required for successful code generation. For example, you add properties (such as the Attribute Access property, which establishes read/write access to an attribute) and incorporate language&truehy;specific syntax (such as data type specifications for attributes and the arguments of operations).</B.BODY
><B.BODY>You might also add data to diagrams other than CDs. The code generator does not use other diagrams, but they are useful for describing the behavior of classes, their attributes and operations.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="25958" TYPE="XREF-TEXTCOPY">Refining the Class Diagrams&rbwtab;2–3</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="36972" TYPE="XREF-TEXTCOPY">Hints and Tips for Effective Code Generation&rbwtab;2–6</RBW-XREF
>Introduction<RBW-IDXTERM TERM1="Class Association Diagram"></RBW-IDXTERM
></L.LABEL
><B.BODY>The CDs and the objects defined in the CDs provide all the source data needed for code generation. <RBW-IDXTERM TERM1="Class Association Model"></RBW-IDXTERM
>These diagrams distinguish the classes in a system and describe their identities and their features. In the Object Design phase, you must add to the CDs sufficient detail for successful code generation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using data from diagrams other than CDs</L.LABEL
><B.BODY>Diagrams other than the CDs are not used as input for code generation. However, they contain valuable information that can help you to complete and verify the CDs. The following table summarizes how you can use these other diagrams to help you find important objects that are not yet in the CDs.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>STD state names (enumerated list as an attribute value)</CELLBODY
><CELLBODY>STD condition on an event</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Classes</L.LABEL
><B.BODY>When you work on CDs, you focus on the implementation of classes. The CD must include all classes and the associations (and inheritance) between classes. In the Object Design phase, you may introduce new classes to ease implementation and improve performance.</B.BODY
><B.BODY>You must include all attributes and operations for each class. The attributes of a class map to the attributes of the class type. The operations of the class map to functions and procedures of the class type. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>External classes</L.LABEL
><B.BODY>A class must have at least one attribute or one operation to generate code. Classes that have no attributes or operations are translated as external classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Associations</L.LABEL
><B.BODY>You must define the associations between all classes, including any constraints.</B.BODY
><B.BODY>Role names must also be defined. Every association needs at least one role name. Every mandatory association must have a role name. Without a role name, you cannot use the association.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role names in Analysis and System Design</SL.SUBLABEL
><B.BODY>In the Analysis and System Design phases, role names distinguish a class by showing the role the class is playing in a relationship with another class. Each role name defines the role of the class within the context of a single association. It also indicates the use and direction of the association toward the class that plays a role. For example, a manager can be both the boss of a coworker and an employee of a company.</B.BODY
>Role names in Object Design and Implementation</SL.SUBLABEL
><BI.BODY.INTRO>In the Object Design and Implementation phases, the use of role names is extended. The code generator creates access methods for an association if the class at the far end has a role name for the association. In the previous example, the code generated for Coworker includes access methods for Manager; the code generated for Manager does not include access methods for Coworker.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attributes</L.LABEL
><B.BODY>You must specify each attribute completely, including its data type. The way to specify a data type for an attribute is to include the type in the class symbol, for example:</B.BODY
><B.BODY>Data types of attributes and arguments can be standard ObjectTeam types, standard types for your target language, or class types and subtypes. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Operations</L.LABEL
><BI.BODY.INTRO>You must specify each operation completely. This includes specifying such aspects as:</BI.BODY.INTRO
><RBW-PARABODY>Any parameters, as well as their data types</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Properties</L.LABEL
><BI.BODY.INTRO><RBW-IDXTERM TERM1="property" TERM2="using - to specify implementation details"></RBW-IDXTERM
>In the Object Design phase, a variety of properties allow you to specify many implementation details. <RBW-IDXTERM TERM1="property" TERM2="using - to specify implementation details"></RBW-IDXTERM
>These details are incorporated in the final code.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Checking</L.LABEL
><B.BODY>The last activity in object design is to use Check | Global Model to check the CDs. The CDs must be error&truehy;free before they can be used for code generation. See the <CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for more information about the Check utility.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</L.LABEL
><B.BODY>Chapter 5, Mapping Modeling Data to Ada 83 Code, and Chapter 4, Mapping Modeling Data to Ada 95 Code, describe how the ObjectTeam model is translated into code. You can use this information to help you complete the CDs in the Object Design phase.</B.BODY
>Hints and Tips for Effective Code Generation</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Following are a few tips for effective code generation. It may be helpful to be aware of these items as you prepare for code generation, and then again as you generate and regenerate your source files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Understanding the translations</L.LABEL
><B.BODY>Before generating code, read through this guide. It contains detailed information about the data that you must include in your CDs for successful code generation. It also explains how the code generator translates the ObjectTeam model into source code files, what changes you can make to the source code files, and how to regenerate them without losing your changes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Naming conventions</L.LABEL
><B.BODY>Agree upon and follow a naming convention for projects, configurations, systems, classes, special characters, and so on. In addition, consider the following:</B.BODY
><RBW-PARABODY>When naming classes, do not leave a space between words. Code generators cannot handle blank spaces in identifier (class) names.</RBW-PARABODY
><RBW-PARABODY>Do not use the same name for a class and a system, or for a class and a CD. Class, system, and diagram names are all stored in the repository as items of type <CX5FX5FEMPHASIS>cl</CX5FX5FEMPHASIS
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing code generation</L.LABEL
><B.BODY>The code generators execute Tcl scripts that translate a model into source code. You can modify these scripts or create your own.. Always use caution when customizing or creating scripts; such scripts are not supported.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using multiple languages in a single application</L.LABEL
><B.BODY>Each ObjectTeam code generator is designed to generate code for one language. You can create an application that uses multiple languages by using different code generators to generate code for different systems; however, the generated code is not integrated across systems. </B.BODY
><B.BODY>The ObjectTeam code generators are not designed to provide language integration. To build an application that uses multiple languages, you must do the following: </B.BODY
>When you create a separate ObjectTeam system for each language&truehy;specific subsystem, be sure to define your classes in the appropriate system. When ObjectTeam generates code for the current system, it generates code for the classes that are defined in that system. It does not generate code for classes referenced, but not defined in, the current system; such classes are treated as external classes.</N.NOTE
>Typically, the ultimate goal of modeling an application is to produce code that implements the application. In ObjectTeam, you can generate a significant portion of the code automatically, then complete the code by adding the details not specified in the model.</B.BODY
><RBW-PARABODY>Only the CDs (and the objects defined in the CDs) are used for code generation. Therefore, before code generation, it is critical that the CDs be fully defined, as described in <RBW-XREF REFID="30937" TYPE="XREF-TEXTCOPY">Chapter 2, Preparing Your ObjectTeam Model for Code Generation</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Steps in code generation</L.LABEL
><B.BODY>The following table provides an overview of the code generation process. This chapter describes each step in greater detail.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Generate code for your systems in the Implementation phase. During this step, ObjectTeam runs the Tcl scripts that generate the application source code files.</CELLBODY
> System level in the Implementation phase is fundamentally different than System level in other phases. The System files in the Implementation phase are source files, not diagram files.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Edit the source files. ObjectTeam generates a large portion of your application code, but not all of it. In this stage, you finish writing the application code.</CELLBODY
><CELLBODY>Changes you make to the source files are not lost. When you regenerate the source files, the code generator recognizes your changes and transfers them to the newly generated files.<RBWAUTO-0004><RBW-IDXTERM TERM1="code regeneration"></RBW-IDXTERM
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Test the executable. If necessary: correct the source files, the model, or both; regenerate the files; and return to step 3.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Illustration of code generation</L.LABEL
><BI.BODY.INTRO>The following illustration shows how ObjectTeam generates code. The CDs and CDMs shown at the top are in the Object Design phase.</BI.BODY.INTRO
><B.BODY>The scripts written for code generation retrieve information from the code generation models, format this information and write the results to source code files. Code generation models are built from the CDs in the Object Design phase.</B.BODY
><B.BODY>The default <RBW-IDXTERM TERM1="Tcl" TERM2="script files used for code generation"></RBW-IDXTERM
>Tcl scripts used by otsh to generate Ada83 source code can be found under the <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
>\<CX5FX5FFILE.NAME>modules</CX5FX5FFILE.NAME
>\<CX5FX5FFILE.NAME>ada83</CX5FX5FFILE.NAME
>\<CX5FX5FFILE.NAME>tcl</CX5FX5FFILE.NAME
> directory tree. The default scripts for generating Ada95 source code can be found under the <RBWAUTO-0007>M4_home</RBWAUTO-0007
><RBW-PARABODY>Changes that you make to the generated files are preserved when you regenerate the files.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>For more information, see <RBW-XREF REFID="28849" TYPE="XREF-TEXTCOPY">Chapter 6, Synchronized Engineering</RBW-XREF
></B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-IDXTERM TERM1="class library" TERM2="including in code generation"></RBW-IDXTERM
><RBW-ANCHOR ID="35964"></RBW-ANCHOR
>Configuration</L.LABEL
><B.BODY>The code that ObjectTeam generates could be any object&truehy;oriented programming language, but this guide focuses on Ada. Before generating Ada code, you may configure your APDT environment.</B.BODY
><B.BODY>You can configure the settings of the default values that are applied when the design is transformed into Ada83 or Ada95 code.</B.BODY
><B.BODY>For more information, see <RBW-XREF REFID="21577" TYPE="XREF-TEXTCOPY">Chapter 8, Configuring the APDT Code Generators</RBW-XREF
><B.BODY>When you generate source files, the code generator uses the CDs and CDMs that are in the Object Design phase to create Ada source files in the Implementation phase. At System level of the Implementation phase, you can then refine the source code and complete the application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Implementation Phase is different</L.LABEL
><B.BODY>The System level of the Implementation phase is fundamentally different from System level of any other phase. In the Implementation phase, the System files are Ada files. In other phases, the System files are ObjectTeam diagrams.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generate code on Phase or System level</L.LABEL
><B.BODY>You can generate code on the Implementation Phase level or on the System level of the Implementation phase.</B.BODY
><RBW-PARABODY>On the <CX5FX5FBULLET.EMPHASIS>Implementation Phase level</CX5FX5FBULLET.EMPHASIS
>, you can generate code for one or more systems. This creates a matching system in the Implementation Phase that contains the generated source files. To regenerate code for an existing system, use System level.</RBW-PARABODY
><RBW-PARABODY>On the <CX5FX5FBULLET.EMPHASIS>System level of the Implementation phase</CX5FX5FBULLET.EMPHASIS
>, you can (re)generate code for the entire system, or regenerate selected source files.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>Typically, you use Implementation Phase level to generate code for a system initially and System level to regenerate code subsequently.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to generate code on Implementation Phase level</L.LABEL
> to generate code for one or more systems in the Object Design phase. You can select only systems that do not yet exist in the Implementation phase.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>ObjectTeam opens a Monitor window for displaying log messages, then generates the source files.</LR.LIST.RESULT
> to (re)generate code for all classes that are defined in this system.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>ObjectTeam opens a Monitor window for displaying log messages, then generates the files. The following illustration shows the Monitor window after generating code for a system.</LR.LIST.RESULT
><BI.BODY.INTRO>Source files are stored in the repository as external files. They are also written to the <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
> directory, where <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
> is the file path for your generated files. For more information on the user environment, see the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>. The following illustrations show how the source files appear in the Browser. </BI.BODY.INTRO
><B.BODY>The code generator generates code for all classes defined in the current system. It does not generate code in the following situations:</B.BODY
><RBW-PARABODY>If a CD in the current system contains a class that is defined in another system, the code generator does not generate code for that class.</RBW-PARABODY
><B.BODY>The OOPL Model, which is generated from the CDs in the Object Design phase, contains information used to generate code. The objects in this model are organized in such a way that code can be generated easily.</B.BODY
> provides a detailed description of the classes in the OOPL Model.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated code</L.LABEL
><B.BODY>The Ada code generators generate the following files for classes in the CDs of the Object Design phase:<RBW-IDXTERM TERM1="C++ header file" TERM2="generating"></RBW-IDXTERM
><B.BODY>After the code has been generated, you can relate each generated Ada specification and body file to a specific class in a CD of the Object Design phase.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Package specification files</L.LABEL
><B.BODY>The generated package specification files contain all the necessary <RBWAUTO-0007>with</RBWAUTO-0007
> statements and do not need editing.</B.BODY
><B.BODY>If, however, you choose to edit a package specification file, you can use the round&truehy;trip engineering task to move your changes back into your model so that they are not lost when you regenerate code. See <RBW-XREF REFID="28849" TYPE="XREF-TEXTCOPY">Chapter 6, Synchronized Engineering</RBW-XREF
> for more information.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Package body files</L.LABEL
><B.BODY>The generated package body files serve as framework files. They contain a subprogram for each method of the classes in the CDs, but the subprogram bodies are empty. You need to fill in the following:</B.BODY
><RBW-PARABODY>The bodies of the subprograms that are defined in the package body. No executable code is created for the subprogram. Instead, the following line is generated:</RBW-PARABODY
></LB.LIST.BULLET
><EM.EXAMPLE.MONO>&truehy;&truehy;!! Implement this function !!</EM.EXAMPLE.MONO
><RBW-PARABODY>In the Information area, double&truehy;click on the source file that you want to edit, or select the source file and then select File | Edit.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The default Text Editor starts up with the corresponding file in the user environment.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Update diagrams</L.LABEL
><B.BODY>Depending on the type of additions you have made to the source files, you may need to edit the CDs to reflect your changes. If you do so, be sure to use Check | Global Model to check the updated diagrams before regenerating the source files.</B.BODY
><RBW-PARABODY>All procedural code in the source files must be completely defined for the implementation of methods (see <RBW-XREF REFID="26759" TYPE="XREF-TEXTCOPY">Editing (Generated) Source Files</RBW-XREF
><RBW-PARABODY>The source code files required for implementing associations for Ada83 or Ada95. These files can be found in M4_home/modules/ada83/config/src for Ada83 code generation and in M4_home/modules/ada95/config/src for Ada95 code generation.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to build an executable</L.LABEL
><B.BODY>For building an Ada83 or Ada95 executable, you must use the tools provided with your Ada compiler.</B.BODY
><B.BODY>See your Ada complier documentation for details on compiling and linking an Ada application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Conduct a final check for errors</L.LABEL
><B.BODY>As always, before you distribute anything, conduct a quality check of your work. If necessary, fix the source files, fix the ObjectTeam model, regenerate the code, and retest the executable.</B.BODY
><RBW-TEXTFLD TYPE="text">Object Team - Ada Professional Developers Toolkit</RBW-TEXTFLD
></RBW-SYSOBJ
></C.CHAPTER.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This chapter explains how particular parts of classes and class specifications result in particular parts of Ada 95 source code.</B.BODY
><B.BODY>The first section of the chapter explains some principles of the code generation process. The next six sections describe the relationship between class specifications and the generated code. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
>Code generation in ObjectTeam is the process of translating diagrams into program code. In the Object Design Phase, you prepare Class Diagrams and their attributes, operations and associations with each other. When generating Ada 95 code only Class Diagrams are used. Also, code is only generated for only for non&truehy;persistent classes.</B.BODY
><B.BODY>During design, you define a class more precisely by specifying its features:</B.BODY
><RBW-PARABODY>Bi&truehy;Directional associations (associations with role names on each side) generate code that will not compile. <RBW-XREF REFID="x3gQn310nsem" TYPE="XREF-TEXTCOPY">Mapping Associations as Classes</RBW-XREF
> describes an alternate method.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Exanple</L.LABEL
><B.BODY>ObjectTeam maps an ObjectTeam class into an Ada record type defined in its own package. The root class of an inheritance hierarchy maps to an Ada 95 tagged record type. Source files for both package spec and body are generated. Here is a short example:</B.BODY
><B.BODY>You can edit the properties of a class, its attributes, operations, parameters, and data types in the Object Design phase. You do this by selecting the class symbol then by choosing Edit Properties<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
> from the Item menu on the Class Diagram editor’s menubar.</B.BODY
><B.BODY>The <RBW-IDXTERM TERM1=""></RBW-IDXTERM
>properties you establish for a class and its characteristics determine the code that is generated for the class. Some properties may generate something other than a class in the resulting code, such as a new type.</B.BODY
> to the record type of the class.<RBW-IDXTERM TERM1="Record types" TERM2="setting class visibility"></RBW-IDXTERM
> The record types are <CX5FX5FTERM>Public</CX5FX5FTERM
> (the default), <CX5FX5FTERM>Private</CX5FX5FTERM
>, <CX5FX5FTERM>Limited</CX5FX5FTERM
>, or <CX5FX5FTERM>Opaque</CX5FX5FTERM
>. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Record and access type names</L.LABEL
><B.BODY>By default, the Ada95 code generator produces a record type named “Instance” and an access type named “Link” for each ObjectTeam Class.</B.BODY
><B.BODY>You can customize the name used for the record type by modifying the M4 variable M4_Ada95_Class_Record_Type_Name. Simularly, you can customize the name used for the access type by modifying the variable M4_Ada95_Class_Access_Type_Name. You must do so, however, before generating code.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
></B.BODY
><B.BODY>See Chapter 8, Configuring the APDT Code Generators, for more information on M4 variables affecting code generation. </B.BODY
><B.BODY>If the access type<RBW-IDXTERM TERM1="Access type" TERM2="optional for a class"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Classes" TERM2="access type is not required"></RBW-IDXTERM
> is not required for a class, you can include the following length clause in the appropriate <CX5FX5FFILE.NAME>&truehy;OT Analyze</CX5FX5FFILE.NAME
> section of the package specification so that it does not reserve storage for the collection associated with the access type:<RBW-IDXTERM TERM1="Access type" TERM2="length clause"></RBW-IDXTERM
> </B.BODY
><E.EXAMPLE>for Link’storage_size use 0;</E.EXAMPLE
><B.BODY>Below are examples of the Ada 95 code that is generated for the class example on the previous page, for each record type. The tagged keyword is generated for the top class in an inheritance hierarchy<RBW-IDXTERM TERM1="Ada code examples" TERM2="class record types"></RBW-IDXTERM
>. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Code generated for a class with public record type<RBW-IDXTERM TERM1="Public record types" TERM2="code example"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Classes" TERM2="public record types"></RBW-IDXTERM
>Code generated for classes with private extension record type<RBW-IDXTERM TERM1="Opaque record types" TERM2="code example"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Classes" TERM2="Opaque record types"></RBW-IDXTERM
></L.LABEL
><B.BODY>Note that the Private Extensions type is valid only for child classes in an inheritance hierarchy. The example below assumes that <parent> is the class name of the parent. </B.BODY
><E.EXAMPLE>package Object_Class is</E.EXAMPLE
><E.EXAMPLE>&rbwtab;type Instance is new <parent> with private;</E.EXAMPLE
><E.EXAMPLE>&rbwtab;type Link is access Instance;</E.EXAMPLE
><B.BODY>By deriving a class from a controlled or limited controlled type, Ada 95 allows a class to define initialization, finalization, and adjustment functionality. To support this concept, each ObjectTeam class has a Controlled property that specifies whether it is Controlled, Limited Controlled, or Not Controlled. The default is Not Controlled.</B.BODY
><B.BODY>When a class is set to Controlled then that class, when generated into Ada 95, will be a subclass of the standard Ada package <CX5FX5FFILE.NAME>Ada.Finalization.Controlled</CX5FX5FFILE.NAME
>. It will therefore implicitly have Initialize, Finalize, and Adjust procedures. Note that these procedures will not appear in the generated code, since they are defined in the parent. They can be overwritten by creating operations in the class called Initialize, Finalize, and Adjust. When a class is Limited Controlled, the generated class will be a subclass of <CX5FX5FFILE.NAME>Ada.Finalization.Limited_Controlled</CX5FX5FFILE.NAME
>, and will implicitly have Initialize, Adjust, and Finalize procedures.</B.BODY
><B.BODY>As an example, if the Object_Class class from the start of this chapter is generated with Control set to Controlled (and public access), the following code is generated.</B.BODY
><B.BODY>In an inheritance hierarchy, only the root class is derived from <CX5FX5FFILE.NAME>Ada.Finalization.Controlled</CX5FX5FFILE.NAME
>. Therefore, the code generator ignores the Controlled property for all subclasses. When the root class is a controlled type, it is not generated as a tagged type. Initialize, Finalize, or Adjust procedures, if defined in the root class, may need to be overridden in the child classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Child syntax</L.LABEL
><B.BODY>Ada 95 supports two syntaxes for package names. A package name can have a simple name, such as Object_Class, or it can have a name in Child Library Unit format, in which the name is a composition of names from the derivation tree for the class. For example, if class B is a subclass of A, and C is a subclass of B, then C could be denoted as A.B.C. This is termed child syntax.</B.BODY
><B.BODY>The Ada 95 code generator supports a Child Syntax property for classes. The value is False, by default. When this property is set to True for a class, the class name will be generated in its child syntax form. This not only includes how the name will appear in its defining specification and body file, but also how the class name will appear in all references and associations from other classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Representing abstract classes and operations</L.LABEL
><B.BODY>You can represent abstract classes and operations in ObjectTeam using the standard UML notation.</B.BODY
><B.BODY>The code generator interprets any class containing an abstract operation as an abstract class. An abstract operation is identified in Class Diagrams by the keyword {abstract} after the operation declaration. An abstract operation cannot be implemented by its declaring class—it must be implemented in a subclass.</B.BODY
><B.BODY>Abstract classes that are generated in Ada 95 code have the keyword <CX5FX5FTERM>abstract</CX5FX5FTERM
> in their record types. Abstract operations have the keywords <CX5FX5FTERM>is abstract</CX5FX5FTERM
> following the declaration of their return types. </B.BODY
><B.BODY>Specify a standard data type such as <CX5FX5FTERM>integer</CX5FX5FTERM
> or the name of another class. The optional dollar sign specifies a class&truehy;based attribute.<RBW-IDXTERM TERM1="Class-based attributes" TERM2="syntax"></RBW-IDXTERM
>[$] means the attribute may optionally be prefixed by a $, indicating the attribute is class&truehy;based.</T.TIP
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Ada 95 constructs</L.LABEL
><B.BODY>The code generator produces the following Ada 95 constructs for an att<RBW-IDXTERM TERM1="Attribute properties" TERM2="Ada constructs"></RBW-IDXTERM
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-IDXTERM TERM1="Class record component" TERM2="attribute properties"></RBW-IDXTERM
>class record component</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Private or public, depending on the Class Visibility property setting</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>get member function</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Private or public depending on the Read/Write Access attribute setting. No function is generated if Read/Write is set to None.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Private or public depending on the Read/Write Access attribute setting. No function is generated if Read/Write is set to None.</CELLBODY
><B.BODY>The attribute name is not important. However, you may want to insert additional text after the standard type. Select the class name in the left window of the Edit Properties dialog box, then add this text in the Subtype Text field.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Defining non&truehy;standard types</L.LABEL
><B.BODY>To have the Ada code generator include non&truehy;standard types and subtypes in a system’s specification file, you must first define them. Do this in the system’s user&truehy;defined types specification file named <CX5FX5FFILE.NAME>system_name_Types.ads</CX5FX5FFILE.NAME
>. Once defined, you can include these non&truehy;standard types and subtypes in all other system specification files that reference them.</B.BODY
><B.BODY>Edit the properties for this class, then add the following entry in the Subtype Text field:<RBW-IDXTERM TERM1="Class properties" TERM2="subtype text"></RBW-IDXTERM
><B.BODY>This generates the following Ada 95 code in the user section (after a <CX5FX5FFILE.NAME>&truehy;&truehy;OT Analyze</CX5FX5FFILE.NAME
> comment) of the user&truehy;defined types<RBW-IDXTERM TERM1="User-defined types file" TERM2="code for subtypes"></RBW-IDXTERM
> file:</B.BODY
><E.EXAMPLE>subtype String20 is Character (1 . . 20);</E.EXAMPLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Defining enum types</L.LABEL
><B.BODY>To define an enum type class,<RBW-IDXTERM TERM1="Classes" TERM2="defining enum types"></RBW-IDXTERM
> you must specify class&truehy;based attributes<RBW-IDXTERM TERM1="Class-based attributes" TERM2="enum types"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Attributes" TERM2="defining enum type classes"></RBW-IDXTERM
> (those specified with a $) of the type enum. Do not specify any associations that generate code for the typedef class,<RBW-IDXTERM TERM1="Typedef class" TERM2="defining enum types"></RBW-IDXTERM
> operations, subclasses, or superclasses.</B.BODY
><B.BODY>The following is an example of an enum class definition<RBW-IDXTERM TERM1="enum class" TERM2="example"></RBW-IDXTERM
><B.BODY>The resulting code is generated in the system types specification:</B.BODY
><E.EXAMPLE>type EnumEx1 is (X,Y,Z);<RBW-IDXTERM TERM1="Ada code examples" TERM2="enum type classes"></RBW-IDXTERM
></E.EXAMPLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing attribute properties</L.LABEL
><B.BODY>The value of an attribute’s Read/Write Access property determines in which section of the specification file, private or public, the code <RBW-IDXTERM TERM1="Package specification file" TERM2="get and set subprograms"></RBW-IDXTERM
>Get and set subprograms in Ada 95 packages</L.LABEL
><B.BODY>For each attribute A of type T, the code generator creates these additional subprograms based on the attribute’s read/write access. If set to None then no Get/Set sub&truehy;programs are generated.</B.BODY
><B.BODY>In the package specification file:<RBW-IDXTERM TERM1="Package specification file" TERM2="get and set subprograms"></RBW-IDXTERM
><RBW-IDXTERM TERM1="get and set subprograms" TERM2="specification file"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Ada code examples" TERM2="get and set in Ada packages"></RBW-IDXTERM
>Generating get and set subprograms for attribute properties</L.LABEL
><B.BODY>The following example shows how the code generator converts the attributes of a class into Ada 95 code.<RBW-IDXTERM TERM1="Attributes of a class" TERM2="converted into Ada code"></RBW-IDXTERM
> The value of an attribute’s Read/Write Access property determines in which section of the package body and specification file the code generator produces the get and set subprograms.</B.BODY
><B.BODY>Standard Type<RBW-IDXTERM TERM1="Standard types" TERM2="get and set subprograms"></RBW-IDXTERM
> are not generated in Ada code. However, if you want to define a class with one attribute and no operations, you may add the $create() operation to denote that the class is not a typedef (subtype) class.<RBW-IDXTERM TERM1="$create() operation"></RBW-IDXTERM
><B.BODY>Operations of a an ObjectTeam class map to primitive subprograms of an Ada record type.<RBW-IDXTERM TERM1="Operations" TERM2="Ada code mapping"></RBW-IDXTERM
></B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Specifying operation syntax</L.LABEL
><B.BODY>Use the following syntax to specify the operations of a class. The optional dollar sign specifies a class&truehy;based operation.<RBW-IDXTERM TERM1="Class-based operations" TERM2="representing in OMT"></RBW-IDXTERM
> That is, it applies to the entire class rather than an instance of the class.</B.BODY
><B.BODY>Listed below are examples of operations that you can specify for a class<RBW-IDXTERM TERM1="Classes" TERM2="specifying operations for"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Operations" TERM2="in a class"></RBW-IDXTERM
>. The subprogram declarations<RBW-IDXTERM TERM1="Subprogram declarations" TERM2="for operations"></RBW-IDXTERM
> the system generates for the operation (or method) are based on whether the operation property is public or private.<RBW-IDXTERM TERM1="Properties" TERM2="setting for operations"></RBW-IDXTERM
> Edit Properties dialog box to specify properties of operations. The Method Access property determines in which section of the package specification, visible or private, the code generator produces the subprogram. The values are <RBW-IDXTERM TERM1="Methods" TERM2="operation properties"></RBW-IDXTERM
>public (the default) or private. There are also properties that allow you to specify whether or not an operation is classwide, and to specify a Tcl procedure to automatically generate the subprogram body.</B.BODY
><B.BODY>If an Ada 95 function returns a value that can be of any type derived directly or indirectly from a certain tagged type (i.e. any subclass of a given root class) it is called a classwide function. To support this, the Ada 95 code generator defines an operation property called Classwide, which can either be False (the default) or True. </B.BODY
><B.BODY>When the property is set to True, the return type for the function in the generated code will be a type defined as an access to the class of the tagged type. This access type is defined as</B.BODY
><B.BODY>type Class_Link is access all Instance’Class</B.BODY
><B.BODY>where the text “_Link” in the above type name is created from the M4 variable M4_Ada95_Class_Access_Type, and may be configured by the user. (See Chapter 8, Configuring the APDT Code Generators for infomation on M4 variables affecting code generation). </B.BODY
><B.BODY>For example, if in the Object_Class example at the start of this chapter, the Get_Object_Name() function’s Classwide property is set to True (if for example, the String class had subclasses corresponding to valid types that the function could return), then the following declaration would be generated for Object_Class (assuming public visibility) :</B.BODY
><B.BODY>The Classwide property for an operation is only relevant if the operation defines a function, as opposed to a procedure, since it only affects the return type for the function.</B.BODY
><B.BODY>In addition, the property is only relevant if the type returned by the function maps to an Ada tagged type. See <RBW-XREF REFID="S1gQn1e4nsem" TYPE="XREF-TEXTCOPY">Mapping Inheritance</RBW-XREF
> for more information on the creation of Ada tagged types.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generating operation body contents</L.LABEL
><B.BODY>The initial code generated for the body of an operation contains an empty subprogram body and the following comment:<RBW-IDXTERM TERM1="Bodies of operations" TERM2="initial code generation"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Operations" TERM2="initial code for bodies"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Code generation" TERM2="initial body contents"></RBW-IDXTERM
></B.BODY
><E.EXAMPLE>&truehy; &truehy; !! Implement this subprogram !!</E.EXAMPLE
><B.BODY>You must fill the empty bodies with the appropriate Ada 95 declarations, statements, and comments<RBW-IDXTERM TERM1="Comment lines" TERM2="code bodies"></RBW-IDXTERM
> between the User sections that appear throughout the generated code before compiling it. Otherwise, the compiler will report an error.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Inserting code in the generated code files</L.LABEL
><B.BODY>You can edit and insert your own code between the User sections of the specification file (indicated by the <CX5FX5FFILE.NAME>&truehy;&truehy;OT Ignore</CX5FX5FFILE.NAME
> and <CX5FX5FFILE.NAME>&truehy;&truehy;OT Analyze</CX5FX5FFILE.NAME
> comment lines) to fill in the bodies of operations. When you regenerate code, the code generator saves your code and inserts it in the appropriate section of the specification file.<RBW-IDXTERM TERM1="Operations" TERM2="editing bodies"></RBW-IDXTERM
>Generate the body using a Tcl procedure<RBW-IDXTERM TERM1="Code generation" TERM2="using Tcl to generate bodies"></RBW-IDXTERM
></L.LABEL
><B.BODY>You can also create a Tool Command Language (Tcl) procedure<RBW-IDXTERM TERM1="Tcl procedures" TERM2="for bodies of operations"></RBW-IDXTERM
> to automatically generate the body of an operation.<RBW-IDXTERM TERM1="Operation bodies" TERM2="generating automatically"></RBW-IDXTERM
> This is often done when generating code for the first time. For example, you can specify a Tcl procedure for a general purpose function, such as printOn, to print all the data members of a class to standard output. You can use this type of function for any class. The contents of the function are the same for every class; only the class is different. Specify the procedure as a class attribute for an operation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Syntax for creating a Tcl procedure</L.LABEL
><EM.EXAMPLE.MONO>proc operation::<attrib value> { oper class sect } { }</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>attrib value procedure name and class attribute value</EM.EXAMPLE.MONO
>You may need to create <CX5FX5FFILE.NAME>u_genada95.tcl</CX5FX5FFILE.NAME
> by copying <CX5FX5FFILE.NAME>genada95.tcl</CX5FX5FFILE.NAME
>. </N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing properties for parameters</L.LABEL
><B.BODY>In Object Design, you can also define properties for parameters of operations. Choose Edit Properties from the Item menu on the Class Diagram menubar. Specify a value that must appear in the function declaration. Also set a Parameter Mode<RBW-IDXTERM TERM1="Modes" TERM2="setting for operation parameters"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Parameter modes" TERM2="setting for operations"></RBW-IDXTERM
> value of <CX5FX5FTERM>in</CX5FX5FTERM
>, <CX5FX5FTERM>out</CX5FX5FTERM
>, <CX5FX5FTERM>in out</CX5FX5FTERM
>, or <CX5FX5FTERM>access</CX5FX5FTERM
>. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Classwide parameters</L.LABEL
><B.BODY>If an Ada 95 parameter represents a value that can be of any type derived directly or indirectly from a certain tagged type (i.e. any subclass of a given root class) it is called a classwide parameter. To support this, the Ada 95 code generator defines a parameter property called Classwide, which can either be False (the default) or True. </B.BODY
><B.BODY>When the Classwide property for a parameter is set to True, then the type for the parameter in the generated code will be a type defined as an access to the class of tagged type. This access type is defined as</B.BODY
><B.BODY>type Class_Link is access all Instance’Class</B.BODY
><B.BODY>where the text “_Link” in the above type name is created from the M4 variable M4_Ada95_Class_Access_Type, and may be configured by the user. (See Chapter 8, Configuring the APDT Code Generators for infomation on M4 variables affecting code generation). </B.BODY
><B.BODY>For example, suppose the following operation appears for a class on a CD diagram, and that parameter Shape is specified with the Classwide property set. The property might be set because the parameter can be a Triangle, Square, or Rectangle, all of which are subclasses of Polygon.</B.BODY
><B.BODY>In this case the corresponding Ada 95 code would be generated.</B.BODY
><E.EXAMPLE> procedure Fill (Self : Instance; Shape : in Polygon.Class_Link);</E.EXAMPLE
><B.BODY>The Classwide property for parameters is only relevant if the paramter type maps to an Ada tagged type. See <RBW-XREF REFID="S1gQn1e4nsem" TYPE="XREF-TEXTCOPY">Mapping Inheritance</RBW-XREF
> for more information on the creation of Ada tagged types.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Specifying overloaded operations</L.LABEL
><B.BODY>You can specify overloaded operators for operation names in classes in Class Diagrams<RBW-IDXTERM TERM1="Operators" TERM2="overloading operations"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Class Association Diagrams" TERM2="overloading operations"></RBW-IDXTERM
><B.BODY>The Ada 95 code generator supports inheritance by recognizing the root class of an inheritance hierarchy and generating for it a tagged record type in its own Ada package. Because the Ada 95 language supports inheritance, the tagged record type provides complete support for single inheritance. Multiple inheritance is not supported by the Ada 95 code generator.</B.BODY
><B.BODY>The code generator does not distinguish between overlapping and non&truehy;overlapping generalizations.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Mapping single inheritance</L.LABEL
><B.BODY>The diagram below shows how single inheritance is represented in ObjectTeam. The attribute Weight_Type in this example is not a standard Ada type. It was added to the customization file object’s <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
> file for this example.<RBW-IDXTERM TERM1="Single inheritance" TERM2="representing in OMT"></RBW-IDXTERM
>Ada code for single inheritance<RBW-IDXTERM TERM1=""></RBW-IDXTERM
></L.LABEL
><B.BODY>In addition to the “Link” access type generated for all classes mapped to records, an additional access type “Class_Link” is generated that is declared as an access to the tagged record’s class.</B.BODY
><B.BODY>Note that the names “Link” and “Class_Link” here are only defaults and may be customized by modifying the M4 variable M4_Ada95_Class_Access_Type_Name. </B.BODY
><B.BODY>See Chapter 8, Configuring the APDT Code Generators, for more information on M4 variables affecting code generation. </B.BODY
><B.BODY>The above diagram example produces the following Ada 95 code:<RBW-IDXTERM TERM1="Single inheritance" TERM2="representing in OMT"></RBW-IDXTERM
><B.BODY>Ada 95 supports dynamic dispatching. Therefore, the Ada 95 code generator supports polymorphism by default. Unlike the Ada 83 code generator, the Ada 95 code generator does not have a Polymorphic M4 variable setting and, as a result, does not generate any additional Ada packages.</B.BODY
><B.BODY>An association in ObjectTeam maps to Ada 95 components in the record types for some or all of the related classes.<RBW-IDXTERM TERM1="Access components" TERM2="when generated for classes"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Record types" TERM2="classes in associations"></RBW-IDXTERM
> The code generator creates a component for a given class involved in an association if a rolename is specified at the far end of the association.<RBW-IDXTERM TERM1="Rolenames" TERM2="classes in associations"></RBW-IDXTERM
></B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Association types<RBW-IDXTERM TERM1="Associations" TERM2="types that generate Ada code"></RBW-IDXTERM
></L.LABEL
><B.BODY>The Ada 95 code generator generates code for the following types of associations:</B.BODY
><RBW-PARABODY>Associations modeled as classes.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>If an association is modeled as a class, the system generates an additional Ada 95 package to implement the association.<RBW-IDXTERM TERM1="Ada packages" TERM2="associations as classes"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Associations" TERM2="modeled as a class"></RBW-IDXTERM
><B.BODY>The following generic packages generate code for associations. These packages can be found in the directory <RBWAUTO-0007>M4_home/modules/ada95/config/src</RBWAUTO-0007
> and must be compiled and linked with the generated Ada95 code..<RBW-IDXTERM TERM1="Ada environment" TERM2="generic packages, configuring"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Generic packages" TERM2="configuring for Ada"></RBW-IDXTERM
> The first two packages are used in one&truehy;to&truehy;many and many&truehy;to&truehy;many associations<RBW-IDXTERM TERM1="one-to-many associations" TERM2="generic packages"></RBW-IDXTERM
><B.BODY>The following conditions apply to most of the package specifications in this section:<RBW-IDXTERM TERM1="Package specifications" TERM2="conditions"></RBW-IDXTERM
><RBW-PARABODY>Only the code for the source class is shown because the destination class is not affected by a unidirectional association and because bidirectional associations are implemented as two unidirectional associations.<RBW-IDXTERM TERM1="Source classes" TERM2="binary associations"></RBW-IDXTERM
><RBW-PARABODY>Text within brackets [ ] appears in either the specification or body file, depending on the class visibility property setting.<RBW-IDXTERM TERM1="Text in brackets" TERM2="class visibility property setting"></RBW-IDXTERM
> This includes <CX5FX5FTERM>with</CX5FX5FTERM
> statements, which always appear in the specification files, and <RBWAUTO-0007>body</RBWAUTO-0007
> in the first line of a package definition, which appears only in the body file.<RBW-IDXTERM TERM1="with statements" TERM2="in package specifications"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Class visibility" TERM2="bracketed text in package specifications"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Body" TERM2="package body definition"></RBW-IDXTERM
><RBW-PARABODY>Association names are not used in code generation; role names are used as the name of the source class’s record component for the association reference.<RBW-IDXTERM TERM1="Association names" TERM2="in code generation"></RBW-IDXTERM
><RBW-PARABODY>In some cases, an association may generate one or two additional package specifications which serve as an intermediate package between the class and the generic package.<RBW-IDXTERM TERM1="Package specifications" TERM2="intermediate"></RBW-IDXTERM
><B.BODY>The sections that follow describe the types of associations you can represent in ObjectTeam and the Ada code that is generated for each type. The example omits the Get and Set subprograms for simplicity.</B.BODY
><B.BODY>Below are examples of unidirectional and bidirectional associations as they are represented in ObjectTeam’s Class Diagram Editor.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Unidirectional association<RBW-IDXTERM TERM1="Unidirectional association" TERM2="representing in OMT"></RBW-IDXTERM
></L.LABEL
><B.BODY>If an association has a role name at only one end, it is unidirectional.</B.BODY
><B.BODY>Below is the Ada 95 code generated for Source_Class in the unidirectional association. The code for Destination_Class is not affected.</B.BODY
><B.BODY>Note that the source end of a unidirectional assoication uses the optional indicator (0..1). </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Bidirectional association<RBW-IDXTERM TERM1="Bidirectional associations" TERM2="example of circular dependency"></RBW-IDXTERM
></L.LABEL
><B.BODY>A bidirectional association has role names on both ends of the association.</B.BODY
><B.BODY>The Ada code resulting from this bidirectional association example will not compile because Class1 and Class2 reference each other, causing a circular dependency.<RBW-IDXTERM TERM1="Circular dependency" TERM2="correcting"></RBW-IDXTERM
> You can correct this association by constructing a link class on the association. <RBW-IDXTERM TERM1="Link attribute box" TERM2="associations"></RBW-IDXTERM
><B.BODY>An optional association is represented with the notation “0..1”, as shown below for a unidirectional association..<RBW-IDXTERM TERM1="Associations" TERM2="optional"></RBW-IDXTERM
> The Ada 95 code generated for this type of association is identical to the code for a normal association, except that it contains a comment above the association reference indicating the optionality of the association.</B.BODY
><RBW-IDXTERM TERM1="Multiplicity" TERM2="representing in OMT"></RBW-IDXTERM
></L.LABEL
><B.BODY>Multiplicity is represented with a “*” at the end of the assoiciation. The diagram below represents a unidirectional multiple association.</B.BODY
> as an ordered association in ObjectTeam by adding the text {ordered} to the the constraint field of the association. The example below specifies the multiplicity association, shown previously, as an ordered association.</B.BODY
><B.BODY>This example will generate the same Ada code for Source_Class as shown in the previous, non&truehy;ordered example, except that every instance of Unordered_Set<RBW-IDXTERM TERM1="Unordered_Set" TERM2="Ada code results"></RBW-IDXTERM
> is replaced with Ordered_Set.<RBW-IDXTERM TERM1="Ordered_Set" TERM2="Ada code results"></RBW-IDXTERM
></B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Implementing qualified associations</L.LABEL
><B.BODY>Use the qualified association symbol in the ObjectTeam Class Diagram editor to represent qualified associations.<RBW-IDXTERM TERM1="Qualified associations" TERM2="representing in OMT"></RBW-IDXTERM
><B.BODY>The source end of a qualified association must be optional (“0..1”) with no rolename. The destination end must have a role name, and may be optional (“0..1”), mandatory (“1”) , or many (“*”).</B.BODY
><B.BODY>The property “Data Type” for the association must be set to a standard type or to a class type.</B.BODY
><B.BODY>The diagram below shows how to represent a mandatory source&truehy;end qualified association.</B.BODY
><B.BODY>For an optional association, the “1” on the destination end of the association would be “0..1”. The same code would be generated, but a comment indicating that the association is optional would be added.</B.BODY
>Ada code generated for Source_Class<RBW-IDXTERM TERM1=""></RBW-IDXTERM
></L.LABEL
><B.BODY>The code example below assumes that the value of the “Data Type” property for the association is Data_Type.<RBW-IDXTERM TERM1="Normal/Optional qualified associations" TERM2="example of"></RBW-IDXTERM
><B.BODY>The diagram below shows how to represent a multiplicity qualified association.<RBW-IDXTERM TERM1="Multiplicity" TERM2="qualified associations"></RBW-IDXTERM
><B.BODY>If you had defined the multiplicity qualified association as an ordered association, the generated Ada 95 code would be similar to the normal qualified association, except that every instance of <CX5FX5FTERM>Unordered_Set</CX5FX5FTERM
> would be replaced with <CX5FX5FTERM>Ordered_Set</CX5FX5FTERM
><B.BODY>The Ada 95 code generator will translate and generate code for associations modeled as classes.<RBW-IDXTERM TERM1="Associations as classes" TERM2="representing in OMT"></RBW-IDXTERM
> The diagram below shows how an association modeled as a class is represented in ObjectTeam. The code generator ignores any association label,<RBW-IDXTERM TERM1="Association labels" TERM2="associations as classes"></RBW-IDXTERM
> if one exists, and instead, uses the name of the class itself to reference the association in code.</B.BODY
><B.BODY>The Ada 95 code generated for an association as class includes an additional Ada Package for the association itself that captures the association class.<RBW-IDXTERM TERM1="Ada packages" TERM2="link attribute associations"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Link attributes" TERM2="in Ada code"></RBW-IDXTERM
> To avoid circular compilation dependencies between this class and the source and/or destination classes,<RBW-IDXTERM TERM1="Source classes" TERM2="code for link attribute assocations"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Destination classes" TERM2="code for link attribute associations"></RBW-IDXTERM
> the system generates an alternate package that only declares a link type.<RBW-IDXTERM TERM1="Alternate packages" TERM2="link attribute associations"></RBW-IDXTERM
><B.BODY>The source and/or destination classes with this alternate package refer to the association class. The Ada 95 code for this class is automatically generated within its own file as shown in the next example, with the name <CX5FX5FTERM>Assoc_Class_Alt</CX5FX5FTERM
><B.BODY>An Aggregation is a relationship that exists when one object contains or is part of another object.<RBW-IDXTERM TERM1="Aggregations" TERM2="defined"></RBW-IDXTERM
> ObjectTeam represents aggregation with a diamond&truehy;shaped symbol at the source end of the aggregation, as shown below.<RBW-IDXTERM TERM1="Aggregations" TERM2="representing in OMT"></RBW-IDXTERM
><B.BODY>The Ada 95 code generated for an aggregation is the same as that generated for binary associations, except that it generates a comment above the reference to distinguish the aggregation from a binary association, Source_Class in this example.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Ada code generated for aggregation relations<RBW-IDXTERM TERM1=""></RBW-IDXTERM
>Modeling Data to Ada 83 Code<RBW-SYSOBJ TYPE="MIFmarker"><RBW-DATAFLD TYPE="number">0</RBW-DATAFLD
><RBW-TEXTFLD TYPE="text">Object Team - Ada Professional Developers Toolkit</RBW-TEXTFLD
></RBW-SYSOBJ
></C.CHAPTER.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This chapter explains how particular parts of classes and class specifications result in particular parts of Ada 83 source code.</B.BODY
><B.BODY>The first section of the chapter explains some principles of the code generation process. The next six sections describe the relationship between class specifications and the generated code. The final section describes generating code for special classes, which follows a different pattern.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
> you prepare the Class Diagrams for code generation by adding details that define how classes and their characteristics will be implemented in code. The Ada 83 code generator produces code only from Class Diagrams.</B.BODY
> may reside in other diagrams such as the <RBW-IDXTERM TERM1=""></RBW-IDXTERM
>Collaboration Diagram and <RBW-IDXTERM TERM1=""></RBW-IDXTERM
>State Transition Diagram. Refer to these diagrams to uncover any additional classes that you may need to add to the Class Diagrams for implementation purposes. Also look for additional attributes, operations, and associations and add these to the Class Diagrams. You might also look for ways to simplify complex associations. The code generator interprets the implementation details in Class Diagrams and translates them into Ada 83 constructs in the resulting code files.</B.BODY
> maps to an Ada record type declared in its own Ada package. A class must have at least one attribute or one operation to generate code. <RBW-IDXTERM TERM1=""></RBW-IDXTERM
>You create classes in Class Diagrams using the Class Diagram editor. You specify attributes and operations for a class by entering them<RBW-IDXTERM TERM1=""></RBW-IDXTERM
> inside the class symbol on the diagram.</B.BODY
><B.BODY><RBW-IDXTERM TERM1=""></RBW-IDXTERM
>Example of a class with one attribute and one operation:</B.BODY
><RBW-PARABODY>Inheritance of the class</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing class properties</L.LABEL
><B.BODY>You can edit the properties of a class, its attributes, operations, parameters, and data types in the Object Design phase. You do this by selecting the class symbol then by choosing Edit Properties<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
> from the Item menu on the Class Diagram editor’s menubar.</B.BODY
><B.BODY>The <RBW-IDXTERM TERM1=""></RBW-IDXTERM
>properties you establish for a class and its characteristics determine the code that is generated for the class. Some properties may generate something other than a class in the resulting code, such as a new type.</B.BODY
> to the record type of the class.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
>. The record types are <CX5FX5FTERM>Public</CX5FX5FTERM
> (the default), <CX5FX5FTERM>Private</CX5FX5FTERM
>, <CX5FX5FTERM>Limited</CX5FX5FTERM
>, or <CX5FX5FTERM>Opaque</CX5FX5FTERM
>. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Record and access type names</L.LABEL
><B.BODY>By default, the Ada83 code generator produces a record type named “Instance” and an access type named “Link” for each ObjectTeam Class.</B.BODY
><B.BODY>You can customize the name used for the record type by modifying the M4 variable M4_Ada83_Class_Record_Type_Name. Simularly, you can customize the name used for the access type by modifying the variable M4_Ada83_Class_Access_Type_Name. You must do so, however, before generating code.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
></B.BODY
><B.BODY><RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
>See Chapter 8, Configuring the APDT Code Generators for information on M4 variables affecting code generation. See the <RBWAUTO-0007>ObjectTeam Customization Guide</RBWAUTO-0007
> for information on how to modify M4 variables.</B.BODY
>If a class does not require an access type<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
>, you can include the following length clause in the appropriate user section of the package specification so that it does not reserve storage for the collection associated with the access type:<RBW-IDXTERM TERM1=""></RBW-IDXTERM
> </N.NOTE
><E.EXAMPLE>for Link’storage_size use 0;</E.EXAMPLE
><B.BODY>Below are examples of the Ada code that is generated for each record type:<RBW-IDXTERM TERM1=""></RBW-IDXTERM
></B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Code generated for classes with public record types<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Private or public, depending on the Class Visibility property setting. </CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>get member function<RBW-IDXTERM TERM1=""></RBW-IDXTERM
></CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Private or public depending on the Read/Write Access attribute setting. No function is generated if Read/Write is set to None.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>set member function<RBW-IDXTERM TERM1=""></RBW-IDXTERM
></CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Private or public depending on the Read/Write Access attribute setting. No function is generated if Read/Write is set to None.</CELLBODY
><B.BODY>The attribute name is not important. However, you may want to insert additional text after the standard type. Select the class name in the left window of the Edit Properties dialog box, then add the additional text in the Subtype Text field.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Defining non&truehy;standard types</L.LABEL
><B.BODY>To have the Ada code generator include non&truehy;standard types and subtypes in a system’s specification file, you must first define them. Do this in the system’s user&truehy;define types specification file named <CX5FX5FFILE.NAME>system_name_Types.ads</CX5FX5FFILE.NAME
>. Once defined, you can include these non&truehy;standard types and subtypes in all other system specification files that reference them.</B.BODY
><B.BODY>Edit the properties for this class and add the following entry in the Subtype Text field:<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
></B.BODY
><E.EXAMPLE>Subtype text = (1..20)</E.EXAMPLE
><B.BODY>This generates the following Ada 83 code in the user section (after an <CX5FX5FFILE.NAME>&truehy;&truehy;OT User</CX5FX5FFILE.NAME
> &truehy; comment) of the user&truehy;defined types<RBW-IDXTERM TERM1=""></RBW-IDXTERM
> file:</B.BODY
><E.EXAMPLE>subtype String20 is Character (1 . . 20);</E.EXAMPLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Defining enum types</L.LABEL
><B.BODY>To define an enum type class,<RBW-IDXTERM TERM1=""></RBW-IDXTERM
> you must specify class&truehy;based attributes<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
> (those specified with a $) of the type enum. Do not specify any associations that generate code for the typedef class,<RBW-IDXTERM TERM1=""></RBW-IDXTERM
> operations, subclasses, or superclasses.</B.BODY
><B.BODY>The following is an example of an enum class definition<RBW-IDXTERM TERM1="enum class" TERM2="example"></RBW-IDXTERM
><B.BODY>The resulting code is generated in the system types specification:</B.BODY
><E.EXAMPLE>type EnumEx1 is (X,Y,Z);<RBW-IDXTERM TERM1=""></RBW-IDXTERM
></E.EXAMPLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing attribute properties</L.LABEL
><B.BODY>The value of an attribute’s Read/Write Access property determines in which section of the specification file, private or public, the code <RBW-IDXTERM TERM1=""></RBW-IDXTERM
>Get and set subprograms in Ada 83 packages</L.LABEL
><B.BODY>For each attribute A of type T, the code generator creates these additional subprograms based on the attribute’s read/write access. If set to None then no Get/Set sub&truehy;programs are generated.</B.BODY
><B.BODY>In the package specification file:<RBW-IDXTERM TERM1=""></RBW-IDXTERM
>Generating get and set subprograms for attribute properties</L.LABEL
><B.BODY>The following example shows how the code generator converts the attributes of a class into Ada 83 code.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
> The value of an attribute’s Read/Write Access property determines in which section of the package body and specification file the code generator produces the get and set subprograms.</B.BODY
> are not generated in Ada code. However, if you want to define a class with one attribute and no operations, you may add the $create() operation to denote that the class is not a typedef (subtype) class.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
> The code generator produces the Ada files but not a subtype statement. The $create() operation does not generate any code.</N.NOTE
><B.BODY>Ada 95 Specification<RBW-IDXTERM TERM1="Standard data types" TERM2="Ada specification"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Ada specification file" TERM2="get and set subprograms"></RBW-IDXTERM
><B.BODY>Operations of an ObjectTeam class map to primitive subprograms of an Ada record type.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
></B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Specifying operation syntax</L.LABEL
><B.BODY><RBW-IDXTERM TERM1=""></RBW-IDXTERM
>Use <RBW-IDXTERM TERM1=""></RBW-IDXTERM
>the following syntax to specify the operations of a class. The optional dollar sign specifies a class&truehy;based operation.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
> That is, it applies to the entire class rather than an instance of the class.</B.BODY
><B.BODY>Listed below are examples of operations that you can specify for a class<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
>. The subprogram declarations<RBW-IDXTERM TERM1=""></RBW-IDXTERM
> the system generates for the operation (or method) are based on whether the operation property is public or private.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
> Edit Properties dialog box to specify properties of operations. The Method Access property determines in which section of the package specification, visible or private, the code generator produces the subprogram. The values are <RBW-IDXTERM TERM1=""></RBW-IDXTERM
>public (the default) or private, or none. You can also specify a Tcl procedure to automatically generate the subprogram body.</B.BODY
><B.BODY>The initial code generated for the body of an operation contains an empty subprogram body and the following comment:<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
></B.BODY
><E.EXAMPLE>&truehy; &truehy; !! Implement this subprogram !!</E.EXAMPLE
><B.BODY>You must fill the empty bodies with the appropriate Ada declarations, statements, and comments<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
> between the User sections that appear throughout the generated code before compiling it. Otherwise, the compiler will report an error.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Manually fill in the user sections of the code</L.LABEL
><B.BODY>You can manually edit the code files and insert comments and additional code between the User sections (represented as <CX5FX5FFILE.NAME>&truehy;&truehy;OT User+</CX5FX5FFILE.NAME
> and <CX5FX5FFILE.NAME>&truehy;&truehy;OT User&truehy;</CX5FX5FFILE.NAME
>). When you regenerate, the code generator saves and inserts your text in the appropriate section of the specification file.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
></B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generate the body using a Tcl procedure<RBW-IDXTERM TERM1=""></RBW-IDXTERM
></L.LABEL
><B.BODY>You can also create a Tool Command Language (Tcl) procedure<RBW-IDXTERM TERM1=""></RBW-IDXTERM
> to automatically generate the body of an operation.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
> This is often done when generating code for the first time. For example, you can specify a Tcl procedure for a general purpose function, such as printOn, to print all the data members of a class to standard output. You can use this type of function for any class. The contents of the function are the same for every class; only the class is different. Specify the procedure as a class attribute for an operation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Syntax for creating a Tcl procedure</L.LABEL
><EM.EXAMPLE.MONO>proc operation::<attrib value> { oper class sect } { }</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>attrib value procedure name and class attribute value</EM.EXAMPLE.MONO
>You may need to create <CX5FX5FFILE.NAME>u_genada83.tcl</CX5FX5FFILE.NAME
> by copying <CX5FX5FFILE.NAME>genada83.tcl</CX5FX5FFILE.NAME
>. </N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing properties for parameters</L.LABEL
><B.BODY>In Object Design, you can also set properties for parameters of operations. Choose Edit Properties from the Item menu on the Class Diagram menubar. Specify a value that must appear in the function declaration. Also, set a Parameter Mode<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
> value of <CX5FX5FEMPHASIS>in</CX5FX5FEMPHASIS
>, <CX5FX5FEMPHASIS>out</CX5FX5FEMPHASIS
>, or <CX5FX5FEMPHASIS>in out</CX5FX5FEMPHASIS
>. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Specifying overloaded operations</L.LABEL
><B.BODY>You can specify overloaded operators for operation names in classes in Class Diagrams.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
> The following table lists the operators you can specify in a class and the corresponding Ada 83 operator generated in code.The following table shoes the mapping of overloaded operators:</B.BODY
><RBW-TABLE><TGROUP COLS="2"><COLSPEC COLNAME="1" COLWIDTH="225p"><COLSPEC COLNAME="2" COLWIDTH="225p"><THEAD><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLHEADING>Operator Specified In A Class</CELLHEADING
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLHEADING>Operator In Ada 95 Code</CELLHEADING
>Superclasses are also referred to as <RBW-IDXTERM TERM1=""></RBW-IDXTERM
>base classes, and subclasses are referred to as <RBW-IDXTERM TERM1=""></RBW-IDXTERM
>derived classes.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Mapping single inheritance</L.LABEL
><B.BODY>The diagram below shows how ObjectTeam represents single inheritance. Because the attribute type Weight_Type is not a standard Ada type, it was added to the customization file object’s <RBWAUTO-0004>stand_types.stand_types</RBWAUTO-0004
> file for this example.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><B.BODY>As a result of setting the Attribute Access property of the base class (Component) to Public, the Ada body and specification files include its attribute record and the operations for the subclass definitions Receiver and Transmitter. This example omits the Get and Set subprograms for simplicity.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Ada code for single inheritance<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><B.BODY>The Ada code generated from the Receiver and Transmitter classes in this example is identical to that shown in the previous single inheritance example, with the following exception.</B.BODY
><B.BODY>The Ada code generator cannot automatically determine from which superclass to generate the My_Weight() function<RBW-IDXTERM TERM1=""></RBW-IDXTERM
> and initiate<RBW-IDXTERM TERM1=""></RBW-IDXTERM
> procedures for the inheriting class, Receiver_Transmitter. Therefore, it generates these procedures from both the Receiver and Transmitter superclasses in the resulting code file. You choose which function and initiate procedure you want by editing the file and removing the comment delimiters from those entries.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
></B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Ada code for multiple inheritance<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><B.BODY>The code generator produces the following additional Ada package for polymorphic<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
> classes when you enable the polymorphism M4 configuration variable. Enabling the polymorphism M4 variable would generate the package for the single inheritance diagram shown previously. See Chapter 2, Preparing ObjectTeam for use with the APDT, for information about modifying the M4 variables.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Ada code for polymorphic classes<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><B.BODY>An association in ObjectTeam maps to Ada access components in the record types for some or all of the related classes.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
> The code generator creates an access component for a class in an association if a rolename is specified at the far end of the association<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-PARABODY>Associations modeled as classes</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>If an association link attribute is modeled as a class, the system generates an additional Ada 83 package to implement the association.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><B.BODY>The following generic packages generate code for associations. These packages can be found in the directory <RBWAUTO-0007>M4_home/modules/ada83/config/src </RBWAUTO-0007
>and must be compiled and linked with the generated Ada83 code..<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
> The first two packages are used in one&truehy;to&truehy;many and many&truehy;to&truehy;many associations. Keywords<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
> are shown in italics. The<RBW-IDXTERM TERM1=""></RBW-IDXTERM
> type names <CX5FX5FTERM>Ordered_Set, Unordered_Set</CX5FX5FTERM
>, and <CX5FX5FTERM>Dictionary</CX5FX5FTERM
> must be unique to avoid possible conflicts.</B.BODY
><EM.EXAMPLE.MONO>generic</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> type Element is private;</EM.EXAMPLE.MONO
><RBW-PARABODY>Only the code for the source class is shown because the destination class is not affected by a unidirectional association and because bidirectional associations are implemented as two unidirectional associations.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-PARABODY>Text within brackets [ ] appears in either the specification or body file, depending on the class visibility property setting.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
> This includes <CX5FX5FEMPHASIS>with</CX5FX5FEMPHASIS
> statements, which always appear in the specification files, and <CX5FX5FTERM>body</CX5FX5FTERM
> in the first line of a package definition, which appears only in the body file.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-PARABODY>Association names are not used in code generation; role names are used as the name of the source class’s record component for the association reference.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-PARABODY>In some cases, an association may generate one or two additional package specifications which serve as an intermediate package between the class and the generic package.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
></RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>The sections that follow describe the types of associations you can represent in ObjectTeam and the Ada code that is generated for each type. The examples omit the Get and Set subprograms for simplicity.</B.BODY
><B.BODY>Below are examples of unidirectional and bidirectional associations as they are represented in ObjectTeam’s Class Diagram Editor.</B.BODY
><B.BODY>Below is the Ada 83 code generated for Source_Class in the unidirectional association. The code for Destination_Class is not affected.</B.BODY
><B.BODY>A bidirectional association has role names on both ends of the association.</B.BODY
><B.BODY>The Ada code resulting from this bidirectional association example will not compile because Class1 and Class2 reference each other, causing a circular dependency.<RBW-IDXTERM TERM1="Circular dependency" TERM2="correcting"></RBW-IDXTERM
> You can correct this association by constructing a link attribute box or a link class on the association. <RBW-IDXTERM TERM1="Link attribute box" TERM2="associations"></RBW-IDXTERM
><B.BODY>An optional association is represented with the notaion “0..1”, as shown below for a unidirectional association.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
> The Ada 83 code generated for this type of association is identical to the code for a normal association, except that it contains a comment above the association reference indicating the optionality of the association.</B.BODY
><B.BODY>You can specify any multiplicity association<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
> as an ordered association in ObjectTeam by adding the text {ordered} to the the constraint field of the association. The example below specifies the multiplicity association, shown previously, as an ordered association.</B.BODY
><B.BODY>This example will generate the same Ada code for Source_Class as shown in the previous, non&truehy;ordered example, except that every instance of Unordered_Set<RBW-IDXTERM TERM1=""></RBW-IDXTERM
> is replaced with Ordered_Set.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
></B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Implementing qualified associations</L.LABEL
><B.BODY>Use the qualified association symbol in the ObjectTeam Class Diagram editor to represent qualified associations.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
></B.BODY
><B.BODY></B.BODY
><B.BODY>The source end of a qualified association must be optional (“0..1”) with no rolename. The destination end must have a role name, and may be optional (“0..1”), mandatory (“1”), or many (“*”).</B.BODY
><B.BODY>The property “Data Type” for the association must be set to a standard type or to a class type.</B.BODY
>Ada code generated for Source_Class<RBW-IDXTERM TERM1=""></RBW-IDXTERM
></L.LABEL
><B.BODY>The code example below assumes that the value of the “Data Type” property for the association is Data_Type.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><B.BODY>If you had defined the multiplicity qualified association as an ordered association, the generated Ada 83 code would be similar to the normal qualified association, except that every instance of <CX5FX5FTERM>Unordered_Set</CX5FX5FTERM
> would be replaced with <CX5FX5FTERM>Ordered_Set</CX5FX5FTERM
>.</B.BODY
><B.BODY><RBW-XREF REFID="37770" TYPE="XREF-TEXTCOPY">Mapping Associations as Classes</RBW-XREF
><B.BODY>The Ada 83 code generator will translate and generate code for associations modeled as classes.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
> The diagram below shows how an association modeled as a class is represented in ObjectTeam. The code generator ignores any association label,<RBW-IDXTERM TERM1=""></RBW-IDXTERM
> if one exists, and instead, uses the name of the class itself to reference the association in code.</B.BODY
><B.BODY>The Ada 83 code generated for an association as class includes an additional Ada Package for the association itself that captures the association class. To avoid circular compilation dependencies between this class and the source and/or destination classes, the system generates an alternate package that only declares a link type.</B.BODY
><B.BODY>The source and/or destination classes with this alternate package refer to the association class. The Ada 83 code for this class is automatically generated within its own file as show in the next example, with the name<RBWAUTO-0007> Assoc_Class_Alt</RBWAUTO-0007
><B.BODY>An Aggregation is a relationship that exists when one object contains or is part of another object.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
> ObjectTeam represents aggregation with a diamond&truehy;shaped symbol at the source end of the aggregation, as shown below.<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><B.BODY>The Ada 83 code generated for an aggregation is the same as that generated for binary associations, except that it generates a comment above the reference to distinguish the aggregation from a binary association, Source_Class in this example.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Ada code generated for aggregation relations<RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-TEXTFLD TYPE="text">Object Team - Ada Professional Developers Toolkit</RBW-TEXTFLD
></RBW-SYSOBJ
></C.CHAPTER.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This chapter explains how to use the APDT for incremental development and synchronized engineering.</B.BODY
><B.BODY>Incremental development refers to the ability to make constant improvement or adaptation of design or code.</B.BODY
><B.BODY>Synchronized Engineering is the process of keeping code and design consistent, without losing information added while in one portion or the other.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><RBW-TEXTFLD TYPE="text">Object Team - Ada Professional Developers Toolkit</RBW-TEXTFLD
></RBW-SYSOBJ
>Introduction</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose of Synchronized Engineering</L.LABEL
><B.BODY>The purpose of Synchronized Engineering is to keep your implementation and your design in synch with one another. As design changes are made, they can be rippled down through the implementation &truehy; without breaking the implementation, or if some code is made obsolete then it is identified and stored in a safe place. Simiarly, as code changes, areas mapping back to design are captured back into the appropriate CD or CDM in the ObjectTeam repository.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Quick Start &truehy; Adapting Code Changes into the ObjectTeam model</L.LABEL
><B.BODY>If you just wish to try Synchronized Engineering, but not pore over the manual here are the steps for synchronizing changes made to code into the ObjectTeam model:</B.BODY
><RBW-PARABODY>Answer any questions that are diaplyed in the Execution window. No changes are committed unless you specify them explicitly.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>This maps code back into your design. You may now continue on with further design or coding changes.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Quick Start &truehy; Regenerating Code to match the ObjectTeam model</L.LABEL
>Code Regeneration refers to synchronizing the implementation source code with changes made in the ObjectTeam design model. Here are the “quick” steps for doing this:</B.BODY
><RBW-PARABODY>Select Utilities | Generate Ada* | New to regenerate all changes made in the object design, or select Utilities | Generate Ada* | Selected to update only the files you chose in Step 2.</RBW-PARABODY
><RBW-PARABODY>Associations may only be added, modified or deleted in ObjectTeam. You may not delete or add new associations in code and synchronize those changes to the ObjectTeam model. Use ObjectTeam to make design association changes.</RBW-PARABODY
><RBW-PARABODY>Chapter 8, Configuring the APDT Code Generators, describes how to customize ObjectTeam with your projects standard data types, as well as how to configure the code generator to use them. This involves customization of the <CX5FX5FFILE.NAME>lang_types.lang_types</CX5FX5FFILE.NAME
> and <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
> customization files. </RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>When mapping changes in Ada source code back into ObjectTeam, the APDT doesn’t use these types, but instead creates new classes as appropriate to represent what it finds in the source files.</LT.LIST.TEXT
>Synchronous engineering is the process of updating code to match design and vice versa.</B.BODY
><B.BODY>In practice this means mapping the ObjectTeam model into areas of the source code that are marked as “affecting the design”, and in mapping changes in those areas back into the ObjectTeam model.</B.BODY
><B.BODY>Areas affecting design are preceded with a <CX5FX5FFILE.NAME>&truehy;&truehy;OT Analyze</CX5FX5FFILE.NAME
> comment. The section is ended with an <CX5FX5FFILE.NAME>&truehy;&truehy;OT Ignore</CX5FX5FFILE.NAME
> comment. These comments tell the system that the following is a special area in the source that is to be synchronized with the ObjectTeam model.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What You Can Change</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="source" TERM2="what you can change"></RBW-IDXTERM
>The code generators generate a variety of comments telling you what they did, and where you may edit at will, or where you should edit with the understanding that the design may change as a result of the edits.</B.BODY
><B.BODY>The APDT parses your code completely, performing both syntactic and semantic parsing. It uses comments placed there when code was generated to let it know:</B.BODY
><RBW-PARABODY>What kind of ObjectTeam representation caused a block of code to be generated (useful for understanding what it should sycnchronize with)</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>The APDT ignores code placed after the <CX5FX5FFILE.NAME>&truehy;&truehy;OT Ignore </CX5FX5FFILE.NAME
>comment. No changes made between those comments will be brought back into ObjectTeam.</B.BODY
><B.BODY>Code following a <CX5FX5FFILE.NAME>&truehy;&truehy;OT Analyze</CX5FX5FFILE.NAME
> comment will be entirely regenerated during a synchronous engineering update. This section is also the only area that the ADPT will analyze to map changes back into the ObjectTeam model.</B.BODY
><B.BODY>The APDT also ignores code placed after <CX5FX5FFILE.NAME>&truehy;&truehy;OT OBSOLETE</CX5FX5FFILE.NAME
> comments. This code has been obsoleted by design changes made in the originating ObjectTeam design. Rather than deleting it, it is left in the source file but marked with <CX5FX5FFILE.NAME>&truehy;&truehy;OT OBSOLETE</CX5FX5FFILE.NAME
> so the APDT will ignore it next time the design and code are synched. You may remove this code, or perhaps re&truehy;use it elsewhere (which is why it isn’t deleted).</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What you SHOULDN’T Change</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="source" TERM2="what you shouldnd5 t change"></RBW-IDXTERM
>The APDT is quite liberal about what code changes you may make in your code. However, it can get confused if you alter the comments it has placed strategically throughout the code. </B.BODY
>This doesn’t mean you can’t change code! Just don’t change the comment itself. The APDT Ada parser looks for these, and their form and structure is how it distinguishes them from comments you may place in the code.</N.NOTE
>One of the most powerful features of ObjectTeam is its configuration and version management system. Any change can be backed out of.</B.BODY
><B.BODY>All changes the APDT makes either in Implementation or in Object Design are made through this versioning system. You can back out if you so desire.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Confirmation of All Changes</L.LABEL
><B.BODY>In addition, when synchronizing Ada code to object design, the APDT asks you whenever it proposes a change to an object. It queues the answers prior to one final question as to commit the entire changes into the ObjectTeam repository.</B.BODY
><B.BODY>You can decline, but save the questions to a log file for perusal offline. After further thought you may then go back and re&truehy;do the synchronization process, answering yes and no as you see fit from your further analysis.</B.BODY
><B.BODY>Some options in Ada synchronized engineering are controlled by M4 environment variables.</B.BODY
><B.BODY>Normally, these variables can be set in a variety of ways, either at the operating system level, or within ObjectTeam (as described in earlier sections). However, with the current version of APDT, the M4 environment variables controlling synchronized engineering must be set at the operating system level.</B.BODY
><B.BODY>The M4 environment variables controlling Ada synchronized engineering are M4_Ada83_Class_Record_Type_name, M4_Ada95_Class_Record_Type_Name, and M4_ada_tmpdir.</B.BODY
><B.BODY>M4_Ada83_Class_Record_Type_Name and M4_Ada95_Class_Record_Type_Name control the name of the primary type around which a class implementing package is built. The default value is “instance”.</B.BODY
><B.BODY>M4_ada_tmpdir defines where temporary files are placed during synchronized engineering. The default for Unix is /var/tmp. </B.BODY
><B.BODY>You can make design changes within the ObjectTeam Design Editor, or in the source code (after <CX5FX5FFILE.NAME><RBW-IDXTERM TERM1="comments" TERM2="--OT Analyze"></RBW-IDXTERM
>&truehy;&truehy;OT Analyze</CX5FX5FFILE.NAME
> comments).</B.BODY
><B.BODY>Although the way you make design changes may differ, the results are still the same. The APDT Synchronous Engineering system will generate new code reflecting design changes made in ObjectTeam, and it will make CD and CDM changes to reflect design changes it finds in the code.</B.BODY
>Attributes may be deleted, added, re&truehy;ordered, or renamed. Renaming an attribute has the effect of deleting and adding it. However, if you rename an attribute it’s likely that it’s properties will be lost.</B.BODY
><B.BODY>If you add an attribute without adding an accessor method, the APDT will set that attributes Access property to Private.</B.BODY
>As with attributes, operations may be deleted, added, re&truehy;ordered, or renamed. Renaming also causes the properties to be lost.</B.BODY
><B.BODY>You may also change method signatures by adding, removing, or re&truehy;ordering parameters, changing default values, or changing the method’s return type.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>APDT Comments</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="comments" TERM2="listing of APDT comments"></RBW-IDXTERM
>The APDT inserts comments in code it generates. These comments are used to help it keep track of what it has done when the design and code are next synchronized.</B.BODY
><RBW-PARABODY>Select the implementation files containing design changes you wish to update into the ObjectTeam model. All files of a System must be selected.</RBW-PARABODY
><RBW-PARABODY>APDT compares the classes it finds in the source files with classes in the Object Design phase. For each difference it finds, APDT proposes an action and prompts you for confirmation. For example:</RBW-PARABODY
></LN.LIST.NUM
><EM.EXAMPLE.MONO>In class “Customer”: delete attribute “Street”.</EM.EXAMPLE.MONO
> customization file specifies what actions the synchronous engineering system proposes, as well as the default answers to the questions it asks.</B.BODY
><B.BODY>Modifying the <CX5FX5FFILE.NAME>roundtrip.roundtrip</CX5FX5FFILE.NAME
> customization file is similar to modifying the <CX5FX5FFILE.NAME>lang_types.lang_types</CX5FX5FFILE.NAME
> and <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
> customization files. For more information about modifying customization files, see <RBW-XREF REFID="39536" TYPE="XREF-TEXTCOPY">Customized Data Types</RBW-XREF
>, which describes how to modify the <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
> customization file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="35835"></RBW-ANCHOR
>Example of synchronizing design to code changes</L.LABEL
><RBW-PARABODY>An ObjectTeam Execution window will appear with the synchronous engineering process running within it. In the following figure, the text asking if the new attribute “Country” should be added is highlighted:</RBW-PARABODY
><RBW-PARABODY>Each change will be update in the appropriate source file, or new source files created and added to the implementation directory.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>Below is the source code representing the implementation created by the previous example:</B.BODY
><B.BODY>After modifying the CD, we save it and verify its correctness using Check | Local Model. It’s always a good idea to verify a model before attempting to generate or re&truehy;generate code.</B.BODY
><B.BODY>With the check successfully passed, it’s time to choose the implementation that we will synchronize with these design modifications. To do this, select the Implementation phase System in the Navigation area of the ObjectTeam Browser, then select Utilities | Generate Ada | New:</B.BODY
><B.BODY>The design changes are then analyzed, with the process monitored from an ObjectTeam Execution window:</B.BODY
><B.BODY>Inspection of the new source file shows a successful update of the Fax and Phone number attributes in the corresponding Ada record type:</B.BODY
>Reverse Engineering parses Ada 83 or Ada 95 source code and builds CDs and CDMs that show the class hierarchy found in the source code.</B.BODY
><B.BODY>Reverse Engineering makes class libraries available in ObjectTeam, helps you understand the structure and function of your software, and provides information that the ObjectTeam documentation tools can use to build “As Built” software documentation.</B.BODY
><B.BODY>Reverse Engineering in the APDT does not capture all the information needed to successfully forward engineer again. Do not expect to reverse engineer and then proceed with synchronous engineering (as you can with code originally generated from with ObjectTeam.</B.BODY
><B.BODY>The APDT reverse&truehy;engineers Ada 83 and Ada 95 code. It offers two basic approaches, one assuming an object&truehy;oriented “style” of development was used, the other assuming the style is unknown or inconsistent.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="18125" TYPE="XREF-TEXTCOPY">Properties Set by Reverse Engineering&rbwtab;7–17</RBW-XREF
><RBW-TEXTFLD TYPE="text">Object Team - Ada Professional Developers Toolkit</RBW-TEXTFLD
></RBW-SYSOBJ
><RBW-ANCHOR ID="33533"></RBW-ANCHOR
>Introduction</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What is Reverse Engineering?</L.LABEL
><B.BODY>Reverse Engineering is the process of mapping Ada source code into ObjectTeam classes and class hierarchies. During reverse engineering the APDT analyzes your source code much like a compiler does, but instead of generating object code it generates CDs and CDMs in the ObjectTeam repository.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Quick Start</L.LABEL
><B.BODY>Should you wish to try reverse engineering without spending a great deal of time reading the manual, here are the basic steps:</B.BODY
><RBW-PARABODY>Select Utilities | Reverse engineer Ada. Browse and choose the files you wish to reverse&truehy;engineer. Any number of files may be chosen, and they need not be provided in compilation order (the APDT will determine it).</RBW-PARABODY
>Reverse Engineering options can be controlled through M4 variables. See later in this chapter for details.</T.TIP
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Caveat</L.LABEL
><B.BODY>The APDT will reverse engineer code that has syntax errors in it. However, you should look at the syntax and semantic errors being reported to determine if they are of the kind that would materially alter the design being represented.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Reverse Engineering Techniques</L.LABEL
><B.BODY>The APDT uses two basic algorithms for mapping Ada to ObjectTeam. The default algorithm assumes that the code being reverse engineered wasn’t done in an object&truehy;oriented fashion, or that it’s method of development is unknown. The second algorithm, called “Class Mappings” assumes the code is structured in an object&truehy;oriented form and makes decisions accordingly.</B.BODY
>Controlling Ada Reverse Engineering</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>M4 Variables </L.LABEL
><B.BODY>Various options on the Ada reverse engineering process are controlled by M4 environment variables.</B.BODY
><B.BODY>Normally, these variables can be set in a variety of ways, either at the operating system level, or within ObjectTeam (as described in earlier sections). However, with the current version of the APDT, the M4 environment variables controlling reverse engineering of Ada must be set at the operating system level.</B.BODY
><B.BODY>The M4 environment variables controlling Ada reverse engineering are M4_ada_reveng, M4_ada_classpackages, and M4_ada_tmpdir. The M4_ada_reveng variable may contain multiple commands, separated by spaces.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Comment Association</L.LABEL
><B.BODY>The reverse engineering tool can extract comments from your source code and populate appropriate properties in the CDs and CDMs it creates. This information is useful for understanding and also can be used in documentation creation.</B.BODY
><B.BODY>The M4_ada_reveng variable passes options to the reverse engineering tool More than one option may be placed in the M4 variable.</B.BODY
><EM.EXAMPLE.MONO>&truehy;associate_comments on | off</EM.EXAMPLE.MONO
><B.BODY>Controls whether comments found in the source code are extracted to appropriate properties in the created ObjectTeam class definition matrices The default is “on”. </B.BODY
><EM.EXAMPLE.MONO>&truehy;libunit_defs before | after | both | none</EM.EXAMPLE.MONO
><B.BODY>Indicates where to extract associated comments for Ada top level library units. Before means before the definition of the unit, after means after, both means grab comments before and after, and none means don’t grab any of these comments. The default is “after”.</B.BODY
><EM.EXAMPLE.MONO>&truehy;nestedunit_defs before | after | both | none</EM.EXAMPLE.MONO
><B.BODY>Similar to libunit_defs, but controls this comment extraction for nested units. Rules for before, after, both, and none are same. The default is “after”.</B.BODY
><EM.EXAMPLE.MONO>&truehy;typeobject_defs before | after | both | none</EM.EXAMPLE.MONO
><B.BODY>Controls comment extraction for types and objects. Default is “after”.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Setting the Reverse Engineering Method</L.LABEL
><B.BODY>The Ada reverse engineering tool uses two methods of reverse engineering. The default requires no option. If you wish to use the class mapping method (see <RBW-XREF REFID="29910" TYPE="XREF-TEXTCOPY">Class Mapping Object Oriented Ada 95 Code</RBW-XREF
> and <RBW-XREF REFID="32896" TYPE="XREF-TEXTCOPY">Class Mapping Object Oriented Ada 83 Code</RBW-XREF
>) then set the M4_ada_classpackages variable to “On”. The default is “Off””. </B.BODY
>Controlling Placement of Temporary Files</L.LABEL
><B.BODY>Running the Ada reverse engineering tool causes the creation of a large database containing the semantic information from the processed source files. A minimum of 10MB of free disk space is needed for Ada95, 5Mb for Ada83. Processing large amounts of source requires additional space. </B.BODY
><B.BODY>By default, the temporary file is placed in the /var/tmp directory. If this directory is not on a filesystem with sufficient available disk space, the user may set the M4_ada_tmpdir variable to another directory name.</B.BODY
>Reverse Engineering Ada 95 &truehy; Default Mapping</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Packages To Classes</L.LABEL
><B.BODY>The default mapping maps each package specification to an ObjectTeam class. The name of the ObjectTeam class is the full name of the package.</B.BODY
><B.BODY>Variables declared in the package specification either become class based attributes (prefixed by a $), or associations to other classes, depending on the type of the variable.</B.BODY
><B.BODY>Subprograms declared in the package specification that do not operate on any record type or operate on more than one record type become methods of the class. These methods may be class based methods (their names prefixed by a $), or accessor methods. Accessor methods are not added to the CDM for the class and so do not appear on CDs.</B.BODY
><B.BODY><RBWAUTO-0007>Note</RBWAUTO-0007
>: If a subprogram operates on a single record type, it appears as a method for the class created for the record type.</B.BODY
><B.BODY><RBWAUTO-0007>Note</RBWAUTO-0007
>: The heuristics used to classify variables as attributes or associations, and subprograms as normal methods or accessor methods are discussed in <RBW-XREF REFID="36917" TYPE="XREF-TEXTCOPY">Reverse Engineering Associations and Accessor Methods</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Record Types to Classes</L.LABEL
><B.BODY>An ObjectTeam class is created for each record type in a package specification. The name of the ObjectTeam class is the full name of the Ada type from which it was generated.</B.BODY
><B.BODY>Components of the record become either attributes of the class. or associations to other classes, depending on the type of the component.</B.BODY
><B.BODY>Subprograms declared in the same package specification as the record type and which operate on the record type become normal or accessor methods of the class. Accessor methods are not added to the CDM for the class and so do not appear on CDs.</B.BODY
><B.BODY><RBWAUTO-0007>Note</RBWAUTO-0007
>: The heuristics used to classify components as attributes or </B.BODY
><B.BODY>associations, and subprograms as normal methods or accessor methods are discussed in Reverse Engineering Associations and Accessor Methods on page 7–15.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Enumeration Types to Classes</L.LABEL
><B.BODY>An ObjectTeam class is created for each enumeration type in a package specification. The name of the ObjectTeam class is the full name of the Ada type from which it was generated. Enumeration literals become class based attributes of the class. No methods are placed in the class.</B.BODY
><B.BODY>This mapping is consistent with the mapping used for creating enumeration type declarations with the Ada95 code generator.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Subtypes to Classes</L.LABEL
><B.BODY>An ObjectTeam class is created for each subtype in a package specification. The name of the class is the full name of the Ada type from which it was generated. A single attribute, “x”, is created for the class.The type text for the attribute is the parent type name. The “Subtype Text” property is set to the subtype constraint.</B.BODY
><B.BODY>The mapping is consistent with the mapping used for creating subtype declarations with the Ada95 code generator.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Library level subprograms</L.LABEL
><B.BODY>For each library level subprogram, a single ObjectTeam class is created. Any nested subprogram becomes a class&truehy;based method (prefixed by a “$”). Any variables become class&truehy;based attributes. The name of the class is the name of the library level subprogram.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Tasks</L.LABEL
><B.BODY>A single ObjectTeam class is created for each task, using the name of the task for the name of the class. The class has no attributes. Any task entries become class based methods (prefixed by a “$”).</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class Hierarchy</L.LABEL
><B.BODY>Ada 95 supports inheritance via its tagged type feature. Each type derivation where the parent type is a tagged type yields an ObjectTeam generalization.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Sample code</SL.SUBLABEL
><B.BODY>Here is a simple Ada 95 source file:</B.BODY
>Class Mapping Object Oriented Ada 95 Code</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>In some situations your Ada 95 code may be structured in a way quite suitable for representation in ObjectTeam. </B.BODY
><B.BODY>Setting the M4_ada_classpackages variable to “On” sets in place a second algorithm that takes advantage of object oriented structured code.</B.BODY
><B.BODY>In this algorithm, the code is expected to be object&truehy;oriented Ada code in which each “class” is a separate package and the package name is meant to be the name of the class.</B.BODY
><B.BODY>When “Class Mapping” is used, each package that has a single tagged type in it is mapped to an ObjectTeam class. The class name is the name of the package. As with the default mapping (<RBW-XREF REFID="32299" TYPE="XREF-TEXTCOPY">Reverse Engineering Ada 95 &truehy; Default Mapping</RBW-XREF
>), components of the tagged type and variables declared in the package specification become either attributes of the class or associations to other classes. Subprograms in the package become normal methods or accessor methods of the class. Methods that do not operate on the record type become class&truehy;based methods (prefixed by “$”).</B.BODY
><B.BODY>All other library units (packages with more than one tagged type, packages with no tagged types, tasks, and library level subprograms), are mapped as in the default algorithm.</B.BODY
><B.BODY>The class hierarchy is built in the same way as the default mapping, with each tagged type extension becoming a generalization.</B.BODY
><B.BODY><RBWAUTO-0007>Note</RBWAUTO-0007
>: The heuristics used to classify variables as attributes or associations and subprograms as normal methods or accessor methods are discussed in <RBW-XREF REFID="36917" TYPE="XREF-TEXTCOPY">Reverse Engineering Associations and Accessor Methods</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example Ada 95 Code structured appropriate for Class Mapping</L.LABEL
><E.EXAMPLE>package Alert is</E.EXAMPLE
><E.EXAMPLE> type Device is (Teletype, Console, Big_Screen);</E.EXAMPLE
><E.EXAMPLE> type Instance is tagged record</E.EXAMPLE
>Reverse Engineering Ada 83 &truehy; Default Mappings</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>The Ada 83 reverse&truehy;engineering tool creates Class Diagrams with classes, their attributes, their methods, and their associations to other classes. It does not presently create class hierarchies. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Packages to Classes</L.LABEL
><B.BODY>The default mapping maps each package specification to an ObjectTeam class. The name of the class is the full name of the package.</B.BODY
><B.BODY>Variables declared in the package specification either become class based attributes (prefixed by a $), or associations to other classes, depending on the type of the variable.</B.BODY
><B.BODY>Subprograms declared in the package specification that do not </B.BODY
><B.BODY>operate on any record type or operate on more than one record type </B.BODY
><B.BODY>become methods of the class. These methods may be class based </B.BODY
><B.BODY>methods (their names prefixed by a $), or accessor methods. </B.BODY
><B.BODY>Accessor methods are not added to the CDM for the class and so do </B.BODY
><B.BODY>not appear on CDs.</B.BODY
><B.BODY><RBWAUTO-0007>Note</RBWAUTO-0007
>: If a subprogram operates on a single record type, it appears as </B.BODY
><B.BODY>a method for the class created for the record type (see below).</B.BODY
><B.BODY><RBWAUTO-0007>Note</RBWAUTO-0007
>: The heuristics used to classify variables as attributes or </B.BODY
><B.BODY>associations, and subprograms as normal methods or accessor </B.BODY
><B.BODY>methods are discussed in Reverse Engineering Associations and </B.BODY
><B.BODY>Accessor Methods on page 7–15.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Record Types to Classes</L.LABEL
><B.BODY>An ObjectTeam class is created for each record type in a package specification. The name of the class is the full name of the Ada type from which it was generated.</B.BODY
><B.BODY>Components of the record become either attributes of the class. or associations to other classes, depending on the type of the component.</B.BODY
><B.BODY>Subprograms declared in the same package specification as the record type and which operate on the record type become normal or accessor methods of the class. Accessor methods are not added to the CDM for the class and so do not appear on CDs.</B.BODY
><B.BODY><RBWAUTO-0007>Note</RBWAUTO-0007
>: The heuristics used to classify components as attributes or </B.BODY
><B.BODY>associations, and subprograms as normal methods or accessor methods are discussed in Reverse Engineering Associations and Accessor Methods on page 7–15.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Enumeration Types to Classes</L.LABEL
><B.BODY>An ObjectTeam class is created for each enumeration type in a package specification. The name of the class is the full name of the Ada type from which it was generated. Enumeration literals become class based attributes of the class. No methods are placed in the class.</B.BODY
><B.BODY>This mapping is consistent with the mapping used for creating enumeration type declarations with the Ada code generator.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Subtypes to Classes</L.LABEL
><B.BODY>An ObjectTeam class is created for each subtype in a package specification. The name of the class is the full name of the Ada type from which it was generated. A single attribute, “x”, is created for the class.The type text for the attribute is the parent type name. The “Subtype Text” property is set to the subtype constraint.</B.BODY
><B.BODY>The mapping is consistent with the mapping used for creating subtype declarations with the Ada code generator.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Library level Sub&truehy;Programs</L.LABEL
><B.BODY>For each library level subprogram, a single ObjectTeam class is created. Any nested subprogram becomes a class&truehy;based method (prefixed by a “$”). Any variables become class&truehy;based attributes. The name of the class is the name of the library level subprogram.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Tasks</L.LABEL
><B.BODY>A single ObjectTeam class is created for each task, using the name of the task for the name of the class. The class has no attributes. Any task entries become class&truehy;based methods (prefixed by a “$”).</B.BODY
>Class Mapping Object Oriented Ada 83 Code</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>In some situations your Ada 83 code may be structured in a way quite suitable for representation in ObjectTeam. </B.BODY
><B.BODY>Setting the M4_ada_classpackages variable to “On” sets in place a second algorithm that takes advantage of object oriented structured code.</B.BODY
><B.BODY>In this algorithm, the code is expected to be object&truehy;oriented Ada code in which each “class” is a separate package and the package name is meant to be the name of the class.</B.BODY
><B.BODY>When “Class Mapping” is used, each package that has a single record type in it is mapped to an ObjectTeam class. The class name is the name of the package. As with the default mapping (<RBW-XREF REFID="32299" TYPE="XREF-TEXTCOPY">Reverse Engineering Ada 95 &truehy; Default Mapping</RBW-XREF
>), components of the record type and variables declared in the package specification become either attributes of the class or associations to other classes. Subprograms in the package become normal methods or accessor methods of the class. Methods that do not operate on the record type become class&truehy;based methods (prefixed by “$”).</B.BODY
><B.BODY>All other library units (packages with more than one record type, packages with no tagged types, tasks, and library level subprograms), are mapped as in the default algorithm.</B.BODY
><B.BODY>Class hierarchies are not created for Ada83.</B.BODY
><B.BODY><RBWAUTO-0007>Note</RBWAUTO-0007
>: The heuristics used to classify variables as attributes or associations and subprograms as normal methods or accessor methods are discussed in <RBW-XREF REFID="36917" TYPE="XREF-TEXTCOPY">Reverse Engineering Associations and Accessor Methods</RBW-XREF
>Reverse Engineering Associations and Accessor Methods</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>The Ada reverse engineering tool uses some simple heuristics to determine which attributes are actually associations and which are true attributes, and to determine which methods are accessor methods and which are normal methods.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Association Recognition</L.LABEL
><B.BODY>A record component or variable whose type is an enumeration, integer, or floating point type becomes an attribute.</B.BODY
><B.BODY>A component or variable whose type maps to a class, or accesses a class, or which is an array with a component type that maps to or accesses a class, becomes an association to the class.</B.BODY
><B.BODY>Other components and variables become attributes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Accessor Method Recognition</L.LABEL
><B.BODY>A method is identified as an accessor method if its name begins with “set”, “get”, “remove”, or “add” and the rest of the name matches one of the attributes in the class. Accessor methods are not added to the CDM created for the class.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Disabling Association and Accessor Method Recognition</L.LABEL
><B.BODY>Reverse engineering of associations and the recognition of accessor methods may be disabled with the “Reverse Engineer Associations” toggle on the reverse engineering dialog box.</B.BODY
><B.BODY>When reverse engineering of associations and accessor methods is disabled, components and variables become attributes, regardless of their types, and all methods become normal methods.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing Association and Accessor Method Recognition</L.LABEL
><B.BODY>Recognition of associations and accessor methods is controlled by the Tcl file “rev_assoc.tcl” in the directory <CX5FX5FTERM>M4_home</CX5FX5FTERM
>/modules/ada95/tcl, for Ada95 or <CX5FX5FTERM>M4_home</CX5FX5FTERM
>/modules/ada83/tcl for Ada83.</B.BODY
><B.BODY>Users experienced with Tcl, and with the ObjectTeam Repository Interface may wish to rewrite this Tcl file to change the heuristics used.</B.BODY
><B.BODY>The new version of the rev_assoc.tcl file should be stored as a customization file in the ObjectTeam repository. The level in which you store the customization file determines the extent to which the Tcl file will be used in reverse engineering. A customization file stored on System level for instance, won’t affect reverse engineering for another system in the same Configuration. However, a customization file stored on Phase level will.</B.BODY
><RBW-PARABODY>Enter the required code. You might want to include the contents of the default “rev_assoc.tcl” file first and then make the desired changes.</RBW-PARABODY
>Properties Set by Reverse Engineering</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>The Ada 95 or Ada 83 reverse engineering process sets properties for each class, attribute, method, and parameter created.</B.BODY
><B.BODY>These properties can be useful for helping understand the code that has been reverse engineered. The properties can also be used by ObjectTeam documentation tools to build “As Built” documentation.</B.BODY
>Unless otherwise noted, these properties are set by both Ada 83 and Ada 95 reverse engineering.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class Properties</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class Visibility</SL.SUBLABEL
><B.BODY>The Class Visibility property is set to “public” if the record type causing creation of a class is in the visible part of a package specification. It is set to “private” if the record is declared as “private” and to “limited” if the record is declared as “limited private”. The Class Visibility property is set to “Opaque” if the record is declared in a package body with an access type referencing the record in the corresponding package specification. For library level subprograms the property is set to “public”.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>External With Clause</SL.SUBLABEL
><B.BODY>The External With Clause property is set to a comma separated list of names of program units withed by the package in which the record was declared.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Free Text</SL.SUBLABEL
><B.BODY>The Free Text property is set in “&truehy;&truehy;” comments found following the declaration of the record causing the creation of a class. Optionally, the M4_ada_reveng environment variable may be used to configure the reverse engineering tool to extract comments before, after, both, or not at all. See <RBW-XREF REFID="42144" TYPE="XREF-TEXTCOPY">Controlling Ada Reverse Engineering</RBW-XREF
> for details on the use of the M4 variable.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Control</SL.SUBLABEL
><B.BODY><CX5FX5FTERM>Ada 95 only</CX5FX5FTERM
>. The Control property is set to “Controlled” if the class was created from a tagged type with a base type of Ada.Finalization.Controlled. It is set to “Limited Controlled” if the base type is Ada.Finalization.Limited_Controlled. In all other cases it is set to “Not controlled”.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Child Syntax</SL.SUBLABEL
><B.BODY><CX5FX5FTERM>Ada 95 only</CX5FX5FTERM
>. The Child Syntax property is set to “TRUE” if the program unit from which the class originated was a child package. It is set to “FALSE” otherwise.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attribute Properties</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Free Text</SL.SUBLABEL
><B.BODY>The Free Text Property is set to text in the“&truehy;&truehy;” comments following the record component declaration. Optionally, the M4_ada_reveng environment variable may be used to configure the reverse engineering tool to extract comments before, after, both, or not at all. See <RBW-XREF REFID="42144" TYPE="XREF-TEXTCOPY">Controlling Ada Reverse Engineering</RBW-XREF
> for details on the use of the M4 variable.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Method Properties</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Method Access</SL.SUBLABEL
><B.BODY>The Method Access property is set to “Private” for subprograms declared within the private part of a package specification and to “Public” for others.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Classwide Type</SL.SUBLABEL
><B.BODY><CX5FX5FTERM>Ada 95 only</CX5FX5FTERM
>. The Classwide Type property is set to TRUE for methods mapped from functions returning the class type. For all other methods it is set to “FALSE”.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Method Free Text</SL.SUBLABEL
><B.BODY>The Method Free Text property is set to the text in a “&truehy;&truehy;” comments following the Ada subprogram or method declaration. Optionally, the M4_ada_reveng environment variable may be used to configure the reverse engineering tool to extract comments before, after, both, or not at all. See <RBW-XREF REFID="42144" TYPE="XREF-TEXTCOPY">Controlling Ada Reverse Engineering</RBW-XREF
> for details on the use of the M4 variable.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Parameter Properties</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Parameter Data Flow Mode</SL.SUBLABEL
><B.BODY>The Parameter Data Flow Mode property is set to “in” for Ada “in” parameters, “out” for Ada “out” parameters, and “in out” for Ada “in out” parameters.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Parameter Default Value</SL.SUBLABEL
><B.BODY>The Parameter Default Value property is set to the default value given in the parameter declaration. If no default value is given, the property is not set.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Classwide Property</SL.SUBLABEL
><B.BODY><CX5FX5FTERM>Ada 95 only</CX5FX5FTERM
>. The Classwide property is set to TRUE if the parameter type is a “class” type and to FALSE for all other cases.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Parameter Free Text</SL.SUBLABEL
><B.BODY>The Free Text Property is set to text in the “&truehy;&truehy;” comments following the record component declaration. Optionally, the M4_ada_reveng environment variable may be used to configure the reverse engineering tool to extract comments before, after, both, or not at all. See <RBW-XREF REFID="42144" TYPE="XREF-TEXTCOPY">Controlling Ada Reverse Engineering</RBW-XREF
> for details on the use of the M4 variable.</B.BODY
><B.BODY>An entire session of reverse engineering an Ada file is shown below. Although this session just does one file (for simplicity), many files can be done at once if desired.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Before you begin</L.LABEL
><B.BODY>Before you reverse engineer, make sure all the M4 variables controlling reverse engineering are set and in effect. See <RBW-XREF REFID="42144" TYPE="XREF-TEXTCOPY">Controlling Ada Reverse Engineering</RBW-XREF
>, <RBW-XREF REFID="29910" TYPE="XREF-TEXTCOPY">Class Mapping Object Oriented Ada 95 Code</RBW-XREF
>, and <RBW-XREF REFID="32896" TYPE="XREF-TEXTCOPY">Class Mapping Object Oriented Ada 83 Code</RBW-XREF
> for information on M4 variables that control the reverse engineering process.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Step 1: Create an Object Design Phase and System</L.LABEL
><B.BODY>Reverse engineering populates a System in the Object Design phase of a Project. So, you will need to create an Object Design phase and System in the project you wish to store the reverse engineering into. Select a project version in the Navigation area of the ObjectTeam Browser, and then select File | New Phase Versions.</B.BODY
><B.BODY>Next, create a system version in the Object Design Phase. Select the ObjectDesign phase in the Navigation area of the ObjectTeam Browser. Then, select File | New System Version and enter the name of the new system.</B.BODY
>Step 2: Launch the Reverse Engineering Tool</L.LABEL
><B.BODY>After creating the Object Design Phase and System, select the System on the left side of the Browser, and invoke the reverse engineering tool by selecting Utilities | Reverse Engineer Ada<CX5FX5FTERM>XX</CX5FX5FTERM
>.</B.BODY
><B.BODY><RBWAUTO-0007>A Reverse Engineer Ada Dialog box appears prompting you to select the files to be reverse engineered.</RBWAUTO-0007
><B.BODY>Use the filter to limit the list of files displayed. Reverse engineering creates CDs and CDMs based on the files that you select. Therefore, you generally want to reverse engineer all files in a system at the same time. Select the desired files and click ok.</B.BODY
><B.BODY>A Reverse Engineer Ada dialog box for appears, prompting you to select the options that you want to use.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>If selected, reverse engineering creates a separate reference CD for each class that exceeds the maximum size. The class is folded in all diagrams other than the reference diagram.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Max Class Width & Height</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a class. When a class exceeds this size, it is folded.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Max Tree Width & Height</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a class tree. When a class hierarchy exceeds this size, it is split.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a diagram. When a diagram exceeds this size, it is split.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>If selected, reverse engineering examines the attributes and accessor methods defined on each class to determine the associations among classes. It then creates CDs that show those associations.</CELLBODY
><CELLBODY>If this option is not specified it will default to the settings of the M4_reveng_filter variable. If the M4_reveng_filter is not set, no input filter will be used.</CELLBODY
> Reverse engineering ignores all preprocessor directives, such as #ifdef and #define. Use this field to specify a preprocessor that can resolve these directives before ObjectTeam reverse engineers the file.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>File containing a list of identifiers to be ignored by reverse engineering. The file must be an ASCII file that contains the identifiers; separate the identifiers using white space.</CELLBODY
>If you want to retain the specification of this file for repeated use, set the M4_reveng_skipfile variable in your Meta4userenv file. For example:</CELLBODY
><CELLBODY>This value will be displayed in this field. Note that if you change the value in this field, it is not written to the Meta4UserEnv file.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
><B.BODY></B.BODY
><B.BODY>Select the desired options, then select OK.</B.BODY
><B.BODY>An ObjectTeam execution window now appears with the reverse engineering process running within it:</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Step 3 Review the results</L.LABEL
><BI.BODY.INTRO>The reverse engineering process creates a variety of CDs and CDMs in the Object Design phase of your project.</BI.BODY.INTRO
><RBW-TEXTFLD TYPE="text">Object Team - Ada Professional Developers Toolkit</RBW-TEXTFLD
></RBW-SYSOBJ
></C.CHAPTER.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This chapter explains the standard way to control various options of the APDT Code Generators. </B.BODY
><B.BODY>To control certain aspects of the working environment, ObjectTeam maintains a set of environment variables. They are referred to as <RBWAUTO-0007>M4 variables</RBWAUTO-0007
> because they all begin with the string <RBWAUTO-0007>M4_</RBWAUTO-0007
>.</B.BODY
><B.BODY>You can specify the values of the M4 variables in an m4env file. ObjectTeam maintains a copy of the m4env file at the Corporate level. By creating an m4env customization file at Project, Configuration, Phase, or System level (or a MetaUserEnv file in your home directory), you can override the Corporate&truehy;level values of M4 variables.</B.BODY
><B.BODY>System environment variables in (Unix or Windows NT) may also be used to specify target languages, however these settings will only take effect for ObjectTeam sessions begun after the variables are set</B.BODY
><B.BODY>For more information: See the <RBWAUTO-0007>ObjectTeam Customization Guide</RBWAUTO-0007
> for more information about M4 variables and m4env and Meta4UserEnv files.</B.BODY
><B.BODY>The APDT adapts its behavior based on the settings of several M4 variables. Most of these variables are common to Ada 83 and Ada 95, but some are language specific. Variables are used to configure code generation, synchronous engineering, and reverse&truehy;engineering. This section describes only those controlling code generation.</B.BODY
><B.BODY>After changing any of these variables you must exit and reopen the level (e.g. Corporate, Project, Version, Phase) that you set the variable. The new settings will then be used.</B.BODY
><B.BODY>This chapter contains the following sections:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Possible values are On or Off. The default is Off. When set to On the APDT code generator will generate separate files for each procedure generated from a class.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Used as the name of the primary type of which a class implementing package is built around. May be set to a text string building a valid Ada 83/95 type name. The default value is “Instance”. </CELLBODY
><CELLBODY><CX5FX5FTERM>Tip</CX5FX5FTERM
>: Changing this variable (and other M4 variables controlling names in code generation) could break previously generated code (which used prior settings of the variable).</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Used as the name of type created to provide an access type to a major class type. May be set to any valid Ada 83/95 type name. The default is “Link”.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Used as the name of the type hidden in the private section of an Ada package when the class attributes are set to Private. May be set to any valid Ada 83/95 type name. The default is “Data”.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the postfix of the component name used to implement Inheritance. May be set to any value building a valid Ada 83/95 variable name. The default value is “_Inh”.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Holds the name of the generic Ada package that will be instantiated to provide Unordered access to a class record. May be set to any valid Ada package name. The default is “Generic_Unordered_Set”. Used when the code generator is mapping Associations to Ada code.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Used as the name of the type implementing unordered sets. May be set to any valid Ada type name. The default is “Unordered_Set”. Used when the code generator is mapping Associations to Ada code.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the name of the generic Ada package implementing ordered set access. May be set to any valid Ada package name. The default is “Generic_Ordered_Set”. Used when the code generator is mapping Associations to Ada code.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Used as the name of the type implementing ordered set access to a class record. May be set to any valid Ada type name. The default is “Ordered_Set”. Used when the code generator is mapping Associations to Ada code.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The name of the package used to provide qualfied assocation capabilities for the code generator. May be set to any valid Ada package name. The default is “Generic_Dictionary”.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Holds the type name used by the code generator when creating code for qualified associations. May contain any valid Ada type name. The default name is “Dictionary”.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Used as the postfix to a class name when generating associations with link attributes. May be set to any text building a valid Ada package name. The default is “_Alt”.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Defines where temporary files are placed during APDT operation. The default for Unix is /var/tmp. </CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
><RBW-ICONIZE></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Ada 83 Only Code Generation Variables</L.LABEL
><BI.BODY.INTRO>The following table lists M4 variables for Ada 83 only:</BI.BODY.INTRO
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Possible values are On or Off. The default is Off. When set to On the Ada 83 code generator will generate code providing polymorphism.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Any text string building a valid Ada 83 package name may be set. This string is appended to generated package’s name as a way to implement polymorphism in Ada 83. The default value is “Any_”. Has no effect if M4_Ada83_Generate Polymorphism is set to “Off”.</CELLBODY
><B.BODY>It’s quite common and desirable to customize your ObjectTeam design environment to reflect the kinds of types your application will be using, or that are used throughout your organization.</B.BODY
><B.BODY>To do this you create a stand_types.stand_types customization file. This file makes the new types available in the ObectTeam design model.</B.BODY
><B.BODY>The second step is to create a lang_types.lang_types customization file. This file tells the code generator how to map the standard types from the stand_types.stand_types file onto Ada83 or Ada95 types.</B.BODY
><B.BODY>The default stand_types.stand_types and lang_types.lang_types files are stored in the etc directory of the <RBWAUTO-0007>Ada83 </RBWAUTO-0007
>or<RBWAUTO-0007> Ada95</RBWAUTO-0007
> module. You can add new standard types or override existing ones.</B.BODY
><B.BODY>All customization files of this type are read incrementally, which means that you only have to include the standard types that you want to add to the current set of standard types and the ones you want to override.</B.BODY
><B.BODY>You can store your stand_types.stand_types and lang_types.lang_types files in the following locations:</B.BODY
> for details on user&truehy;defined modules.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="13216"></RBW-ANCHOR
>Format of the standard types file</L.LABEL
><B.BODY>Here is an example of the Ada 95 default stand_types.stand_types file as shipped with the APDT.</B.BODY
><B.BODY>The columns Min 1, Max 1, and Min 2, and Max 2 may be used to specify constraints on array size or format values of the standard types.</B.BODY
><B.BODY>The lang_types.lang_types file is used to tell the code generator how to map your new type into its target language.</B.BODY
><B.BODY>Below is the standard lang_types file, as shipped with this version of the APDT. The Standard Type column maps to the name of the type in the stand_types file. The Ada Type column is the type name to use when generating Ada code. The Range column is an optional modifier you can place on the type definition. It follows the Ada range syntax.</B.BODY
><B.BODY>In this example, we will add a new standard type “Atomic_Time” and make it available first for ObjectTeam design use and and then for Ada code generation.</B.BODY
><RBW-PARABODY>Add the new type “Atomic_Time” using the format described in <RBW-XREF REFID="13216" TYPE="XREF-TEXTCOPY">Format of the standard types file</RBW-XREF
><B.BODY>After exiting, you should change Browser level and re&truehy;enter. If you created the new stand_types file on Corporate level, then restart your ObjectTeam Browser.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Making the new type available for Code Generation</L.LABEL
><B.BODY>In order to make this new “Atomic_Time” type available to the code generator you have to perform a similar procedure, but on the <CX5FX5FFILE.NAME>lang_types.lang_types</CX5FX5FFILE.NAME
> file.</B.BODY
><B.BODY>All procedures are the same, except you specify a new <CX5FX5FFILE.NAME>lang_types.lang_types</CX5FX5FFILE.NAME
> file when creating a new Customization File Version. In the file, insert this line:</B.BODY
>Where Code Generator Files are Stored</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>The APDT code generators can create quite a few Ada source files. </B.BODY
><B.BODY>The names of the source files generated are based on the Class and Attribute names used in the Object Design. You can however control the file extensions used. You may also specify what directory the resulting files are stored in.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changing output file extensions</L.LABEL
><B.BODY>You can change the default extensions of the specification, body, and subunit files by editing the <CX5FX5FFILE.NAME>objtype.objtype</CX5FX5FFILE.NAME
> customization file. As with adding a new type, you do this at the level you wish this change to apply to.</B.BODY
>Only change extensions immediately after selecting your Ada target language, or after deleting all generated files (in a System Implementation).</N.NOTE
><RBW-PARABODY>To activate your customization, move up a level in the Browser and back to the level on which you created the customization file. If you edited the file at the Corporate level, restart the Browser.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Setting the Output Directory</L.LABEL
><B.BODY>The default output directory is in your home directory under the corporate directory (by default <CX5FX5FFILE.NAME>repos</CX5FX5FFILE.NAME
>; the corporate directory in your installation may be named differently). A tree is then generated under this:</B.BODY
><RBW-PARABODY>Click OK to save your changes, then change the level or restart the Browser.</RBW-PARABODY
></LN.LIST.NUM
><B.BODY>Future generated code will use a tree beginning in the path specified. For example, using the example in the figure above, generated Ada code would be output to a tree such as /usr/OrderFulfillment/main_system/CD.ads.</B.BODY
><CHAPTERNONUM><CN.CHAPTER.NOX23>About This Manual<RBW-SYSOBJ TYPE="MIFmarker"><RBW-DATAFLD TYPE="number">0</RBW-DATAFLD
><RBW-TEXTFLD TYPE="text">Code Generation Guide for C++</RBW-TEXTFLD
></RBW-SYSOBJ
></CN.CHAPTER.NOX23
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>About this manual</L.LABEL
><B.BODY>ObjectTeam provides code generation tools that enable you to generate object&truehy;oriented code for a range of object&truehy;oriented programming languages. This guide focuses on C++ as target language. </B.BODY
><B.BODY>This manual explains the following things:</B.BODY
><RBW-PARABODY>How you can customize the default code generation process</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisites</L.LABEL
><B.BODY>This book assumes a basic knowledge of ObjectTeam, including familiarity with the information provided in the <CX5FX5FTITLE><CX5FX5FTITLE>ObjectTeam Getting Started</CX5FX5FTITLE
></CX5FX5FTITLE
> and <CX5FX5FTITLE><CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
></CX5FX5FTITLE
>. </B.BODY
><B.BODY>Furthermore, knowledge of C++ is necessary to understand the C++ constructions generated from the CD. You also need this knowledge to complete the generated source files.</B.BODY
><B.BODY>If you plan to customize the default code generation process, you should be familiar with Tcl and the object&truehy;oriented extensions to Tcl supplied with ObjectTeam. For details on Object Tcl, refer to the <CX5FX5FTITLE><CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
> provides the menu items, the properties and the Tcl code required to use the C++ Code Generator. Therefore, before moving to the Object Design phase, make sure this module is active.</B.BODY
><B.BODY>You can check if a module is active on a particular Browser level by selecting Utilities | Show Active Modules on that level.</B.BODY
> requires one module of type DevelEnv, and one or more of type CppClasslib. You select these modules from a dialog box, after you select the module <CX5FX5FEMPHASIS>C++ Code Generation</CX5FX5FEMPHASIS
>.</B.BODY
><B.BODY>These are the modules required to run C++ Code generation.</B.BODY
>Compatibility with previous releases</SL.SUBLABEL
><B.BODY>The current release of the C++ code generator is not compatible with previous releases. If you used a previous release of the C++ code generator, refer to <RBW-XREF REFID="15646" TYPE="XREF-TEXTCOPY">Appendix C, Compatibility With Previous Releases</RBW-XREF
>, for more information.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Object Design and Implementation</L.LABEL
><B.BODY>This chapter describes the tasks of the Object Design phase. <RBW-XREF REFID="16183" TYPE="XREF-TEXTCOPY">Chapter 2, Building a C++ Application</RBW-XREF
>, describes the tasks of the Implementation phase. You work iteratively in these two phases to generate code and complete your application.</B.BODY
><B.BODY>See <RBW-XREF REFID="11059" TYPE="XREF-TEXTCOPY">Appendix B, Example Application</RBW-XREF
> for a complete example application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose of object design</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="Object Design" TERM2="activities in this phase"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Object Design" TERM2="development phase in ObjectTeam project"></RBW-IDXTERM
>In ObjectTeam, the CDs (and the objects defined in the CDs) provide all the source data needed for code generation. The goal of object design is to add to the CDs all the data required for successful code generation. For example, you add properties (such as the Attribute Access property, which establishes read/write access to an attribute) and incorporate language&truehy;specific syntax (such as data type specifications for attributes and the arguments of operations).</B.BODY
><B.BODY>You might also add data to diagrams other than CDs. The code generator does not use oter diagrams, but they are useful for describing the behavior of classes, their attributes and operations.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="23234" TYPE="XREF-TEXTCOPY">Refining the Class Diagrams&rbwtab;1–4</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="11510" TYPE="XREF-TEXTCOPY">Hints and Tips for Effective Code Generation&rbwtab;1–7</RBW-XREF
>Introduction<RBW-IDXTERM TERM1="Class Association Diagram"></RBW-IDXTERM
></L.LABEL
><B.BODY>The CDs and the objects defined in the CDs provide all the source data needed for code generation. <RBW-IDXTERM TERM1="Class Association Model"></RBW-IDXTERM
>These diagrams distinguish the classes in a system and describe their identities and their features. In the Object Design phase, you must add to the CDs sufficient detail for successful code generation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using data from diagrams other than CDs</L.LABEL
><B.BODY>Diagrams other than the CDs are not used as input for code generation. However, they contain valuable information that can help you to complete and verify the CDs. The following table summarizes how you can use these other diagrams to help you find important objects that are not yet in the CDs.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>STD state names (enumerated list as an attribute value)</CELLBODY
><CELLBODY>STD condition on an event</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Classes</L.LABEL
><B.BODY>When you work on CDs, you focus on the implementation of classes. The CD must include all classes and the associations (and inheritance) between classes. In the Object Design phase, you may introduce new classes to ease implementation and improve performance.</B.BODY
><B.BODY>You must include all attributes and operations for each class. The attributes of a class map to the attributes of the class type. The operations of the class map to functions and procedures of the class type. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>External classes</L.LABEL
><B.BODY>A class must have at least one attribute or one operation to generate code. Classes that have no attributes or operations are translated as external classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Associations</L.LABEL
><B.BODY>You must define the associations between all classes, including any constraints.</B.BODY
><B.BODY>Role names must also be defined. Every association needs at least one role name. Every mandatory association must have a role name. Without a role name, you cannot use the association.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role names in Analysis and System Design</SL.SUBLABEL
><B.BODY>In the Analysis and System Design phases, role names distinguish a class by showing the role the class is playing in a relationship with another class. Each role name defines the role of the class within the context of a single association. It also indicates the use and direction of the association toward the class that plays a role. For example, a manager can be both the boss of a coworker and an employee of a company.</B.BODY
>Role names in Object Design and Implementation</SL.SUBLABEL
><BI.BODY.INTRO>In the Object Design and Implementation phases, the use of role names is extended. The code generator creates access methods (such as pointers) for an association if the class at the far end has a role name for the association. In the previous example, the code generated for Coworker includes access methods for Manager; the code generated for Manager does not include access methods for Coworker.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attributes</L.LABEL
><B.BODY>You must specify each attribute completely, including its data type. (See <RBW-XREF REFID="11407" TYPE="XREF-TEXTCOPY">Mapping Attributes</RBW-XREF
> for attribute syntax.) The way to specify a data type for an attribute is to include the type in the class symbol, for example:</B.BODY
><B.BODY>Data types of attributes and arguments can be standard ObjectTeam types, standard types for your target language, or class types and derived types. Types are abstracted from the data types recognized by the database system and the OOPL environment. The code generator translates the standard types to the target types. </B.BODY
><B.BODY>Take care when customizing the files that define standard types. Any additions you make must conform to the target language or the generated code may not be usable.</B.BODY
><B.BODY>For details on customizing the standard types, see <RBW-XREF REFID="28522" TYPE="XREF-TEXTCOPY">Customizing Types</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Operations</L.LABEL
><BI.BODY.INTRO>You must specify each operation completely. (See <RBW-XREF REFID="29516" TYPE="XREF-TEXTCOPY">Mapping Methods</RBW-XREF
> for operation syntax.) This includes specifying such aspects as:</BI.BODY.INTRO
><RBW-PARABODY>Any parameters, as well as their data types</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Properties</L.LABEL
><BI.BODY.INTRO><RBW-IDXTERM TERM1="property" TERM2="using - to specify implementation details"></RBW-IDXTERM
>In the Object Design phase, a variety of properties allow you to specify many implementation details. <RBW-IDXTERM TERM1="property" TERM2="using - to specify implementation details"></RBW-IDXTERM
>These details are incorporated in the final code.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Checking</L.LABEL
><B.BODY>The last activity in object design is to use Check | Global Model to check the CDs. The CDs must be error&truehy;free before they can be used for code generation. See the <CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for more information about the Check utility.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</L.LABEL
><B.BODY><RBW-XREF REFID="22643" TYPE="XREF-TEXTCOPY">Chapter 3, Mapping Modeling Data to C++</RBW-XREF
> describes how the ObjectTeam model is translated into code. You can use this information to help you complete the CDs in the Object Design phase.</B.BODY
>Hints and Tips for Effective Code Generation</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Following are a few tips for effective code generation. It may be helpful to be aware of these items as you prepare for code generation, and then again as you generate and regenerate your source files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Understanding the translations</L.LABEL
><B.BODY>Before generating code, read through this guide. It contains detailed information about the data that you must include in your CDs for successful code generation. It also explains how the code generator translates the ObjectTeam model into source code files, what changes you can make to the source code files, and how to regenerate them without losing your changes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Naming conventions</L.LABEL
><B.BODY>Agree upon and follow a naming convention for projects, configurations, systems, classes, special characters, and so on. In addition, bear in mind that spaces between words (in class names, for instance) are deleted by ObjectTeam code generators.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing code generation</L.LABEL
><B.BODY>The code generators execute Tcl scripts that translate a model into source code. You can modify these scripts or create your own., as described in <RBW-XREF REFID="36160" TYPE="XREF-TEXTCOPY">Chapter 5, Customizing Code Generation</RBW-XREF
>. Always use caution when customizing or creating scripts; such scripts are not supported.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using multiple languages in a single application</L.LABEL
><B.BODY>Each ObjectTeam code generator is designed to generate code for one language. You can create an application that uses multiple languages by using different code generators to generate code for different systems; however, the generated code is not integrated across systems. </B.BODY
><B.BODY>The ObjectTeam code generators are not designed to provide language integration. To build an application that uses multiple languages, you must do the following: </B.BODY
>When you create a separate ObjectTeam system for each language&truehy;specific subsystem, be sure to define your classes in the appropriate system. When ObjectTeam generates code for the current system, it generates code for the classes that are defined in that system. It does not generate code for classes referenced, but not defined in, the current system; such classes are treated as external classes.</N.NOTE
>Typically, the ultimate goal of modeling an application is to produce code that implements the application. In ObjectTeam, you can generate a significant portion of the code automatically, then complete the code by adding the details not specified in the model.</B.BODY
><RBW-PARABODY>Only the CDs (and the objects defined in the CDs) are used for code generation. Therefore, before code generation, it is critical that the CDs be fully defined, as described in <RBW-XREF REFID="19089" TYPE="XREF-TEXTCOPY">Chapter 1, Preparing Your ObjectTeam Model for Code Generation</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Steps in code generation</L.LABEL
><B.BODY>The following table provides an overview of the code generation process. This chapter describes each step in greater detail.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Configure the C++ environment, ensuring proper installation of the C++ environment (makefile template and class library source files, if applicable).</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Generate code for your systems in the Implementation phase. During this step, ObjectTeam runs the Tcl scripts that generate the application source code files.</CELLBODY
> System level in the Implementation phase is fundamentally different than System level in other phases. The System files in the Implementation phase are source files, not diagram files.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Edit the source files. ObjectTeam generates a large portion of your application code, but not all of it. In this stage, you finish writing the application code.</CELLBODY
><CELLBODY>Changes you make to the source files are not lost. When you regenerate the source files, the code generator recognizes your changes and transfers them to the newly generated files.<RBWAUTO-0004><RBW-IDXTERM TERM1="code regeneration"></RBW-IDXTERM
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Generate a makefile. The makefile compiles and links the target object (an executable or library).</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Build the executable or library. Execute the makefile to compile and link the target object. If you built an executable, you can now run it.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Test the executable or library. If necessary: correct the source files, the model, or both; regenerate the files; and return to step 6.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Illustration of code generation</L.LABEL
><BI.BODY.INTRO>The following illustration shows how ObjectTeam generates code. The CDs and CDMs shown at the top are in the Object Design phase.</BI.BODY.INTRO
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="16880" TYPE="XREF-TEXTCOPY">Components of Code Generation&rbwtab;2–5</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="40480" TYPE="XREF-TEXTCOPY">Configuring Your C++ Environment&rbwtab;2–6</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="34047" TYPE="XREF-TEXTCOPY">Generating C++ Code&rbwtab;2–9</RBW-XREF
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="15358" TYPE="XREF-TEXTCOPY">Generating a Makefile&rbwtab;2–17</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="13254" TYPE="XREF-TEXTCOPY">Building the Executable or Library&rbwtab;2–19</RBW-XREF
><B.BODY>The scripts written for code generation retrieve information from the code generation models, format this information and write the results to source code files. Code generation models are built from the CDs in the Object Design phase.</B.BODY
><B.BODY>The default <RBW-IDXTERM TERM1="Tcl" TERM2="script files used for code generation"></RBW-IDXTERM
>Tcl scripts used by otsh to generate C++ source code can be found under the <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
>\<CX5FX5FFILE.NAME>modules</CX5FX5FFILE.NAME
>\<CX5FX5FFILE.NAME>cplusplus</CX5FX5FFILE.NAME
>\<CX5FX5FFILE.NAME>tcl</CX5FX5FFILE.NAME
> directory tree. For more information, see <RBW-XREF REFID="21823" TYPE="XREF-TEXTCOPY">How C++ Code is Generated</RBW-XREF
><RBW-PARABODY>Changes that you make to the generated files are preserved when you regenerate the files.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>For more information, see <RBW-XREF REFID="18109" TYPE="XREF-TEXTCOPY">Regenerating Code</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-IDXTERM TERM1="class library" TERM2="including in code generation"></RBW-IDXTERM
><RBW-ANCHOR ID="35964"></RBW-ANCHOR
>Class library integration</L.LABEL
><B.BODY>You can include external class libraries in your design. Such an external class library is automatically included during the code generation. In addition, ObjectTeam helps you to understand and reuse existing class libraries through reverse engineering.</B.BODY
><B.BODY>For more information, see <RBW-XREF REFID="26044" TYPE="XREF-TEXTCOPY">Reverse Engineering</RBW-XREF
><B.BODY>You can have ObjectTeam create a makefile automatically for the C++ compiler that you are using.</B.BODY
><B.BODY>For more information, see <RBW-XREF REFID="15358" TYPE="XREF-TEXTCOPY">Generating a Makefile</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Configuration</L.LABEL
><B.BODY>The code that ObjectTeam generates could be any object&truehy;oriented programming language, but this guide focuses on C++. Before generating C++ code, you must configure your C++ environment. </B.BODY
><B.BODY>For more information, see <RBW-XREF REFID="40480" TYPE="XREF-TEXTCOPY">Configuring Your C++ Environment</RBW-XREF
> is created in the repository on Configuration level. This template file is expanded when you generate a makefile using Target | Generate Makefile</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Cayenne class library</SL.SUBLABEL
><B.BODY>If you are using the Cayenne class library (if <CX5FX5FOBJECT.NAME>cpp&truehy;libcayn</CX5FX5FOBJECT.NAME
> is part of your set of current modules), the following tasks are also carried out:</B.BODY
><RBW-PARABODY>The required header files are copied from the <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
> directory to the <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
>\<CX5FX5FFILE.NAME>include</CX5FX5FFILE.NAME
> directory. </RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>These source and include files must be compiled into a library file before the Cayenne class library can be used (see <RBW-XREF REFID="24041" TYPE="XREF-TEXTCOPY">How to compile the Cayenne class library</RBW-XREF
> is inserted on Configuration level, and, if applicable, class library source files are copied to your user environment.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="24041"></RBW-ANCHOR
>How to compile the Cayenne class library</L.LABEL
><B.BODY>If you are using the Cayenne class library (see <RBW-XREF REFID="19089" TYPE="XREF-TEXTCOPY">Chapter 1, Preparing Your ObjectTeam Model for Code Generation</RBW-XREF
>) you must compile the source files that were copied during the configuration of your C++ environment.</B.BODY
><LR.LIST.RESULT>The Cayenne class library is now compiled. If your environment has been set up properly, the compiled class library is stored in the directory <CX5FX5FFILE.NAME>user_environment</CX5FX5FFILE.NAME
>\<CX5FX5FFILE.NAME>lib</CX5FX5FFILE.NAME
>.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Adding new options</L.LABEL
><B.BODY>Integrations of class libraries with ObjectTeam are entirely written in Object Tcl, which allows you to customize them to a large extent. You can add new configuration options, for example, by creating a new module with certain customization files, as described in <RBW-XREF REFID="32178" TYPE="XREF-TEXTCOPY">Customizing Class Libraries</RBW-XREF
><B.BODY>When you generate source files, the code generator uses the CDs and CDMs that are in the Object Design phase to create C++ source files in the Implementation phase. At System level of the Implementation phase, you can then refine the source code and complete the application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Implementation Phase is different</L.LABEL
><B.BODY>The System level of the Implementation phase is fundamentally different from System level of any other phase. In the Implementation phase, the System files are C++ files. In other phases, the System files are ObjectTeam diagrams.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generate code on Phase or System level</L.LABEL
><B.BODY>You can generate code on the Implementation Phase level or on the System level of the Implementation phase.</B.BODY
><RBW-PARABODY>On the <CX5FX5FBULLET.EMPHASIS>Implementation Phase level</CX5FX5FBULLET.EMPHASIS
>, you can generate code for one or more systems. This creates a matching system in the Implementation Phase that contains the generated source files. To regenerate code for an existing system, use System level.</RBW-PARABODY
><RBW-PARABODY>On the <CX5FX5FBULLET.EMPHASIS>System level of the Implementation phase</CX5FX5FBULLET.EMPHASIS
>, you can (re)generate code for the entire system, or regenerate selected source files.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>Typically, you use Implementation Phase level to generate code for a system initially and System level to regenerate code subsequently.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to generate code on Implementation Phase level</L.LABEL
> to generate code for one or more systems in the Object Design phase. You can select only systems that do not yet exist in the Implementation phase.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>ObjectTeam opens a Monitor window for displaying log messages, then generates the source files.</LR.LIST.RESULT
> to (re)generate code for all classes that are defined in this system.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>ObjectTeam opens a Monitor window for displaying log messages, then generates the files. The following illustration shows the Monitor window after generating code for a system.</LR.LIST.RESULT
><BI.BODY.INTRO>Source files are stored in the repository as external files. They are also written to the <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
> directory, where <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
> is the file path for your generated files. For more information on the user environment, see the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>. The following illustrations show how the source files appear in the Browser. </BI.BODY.INTRO
><B.BODY>The code generator generates code for all classes defined in the current system. It does not generate code in the following situations:</B.BODY
><RBW-PARABODY>If a CD in the current system contains a class that is defined in another system, the code generator does not generate code for that class.</RBW-PARABODY
><B.BODY>The OOPL Model, which is generated from the CDs in the Object Design phase, contains information used to generate code. The objects in this model are organized in such a way that code can be generated easily.</B.BODY
> provides a detailed description of the classes in the OOPL Model. <RBW-XREF REFID="21823" TYPE="XREF-TEXTCOPY">How C++ Code is Generated</RBW-XREF
> discusses the OOPL model in the code generation process.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated code</L.LABEL
><B.BODY>The C++ code generator generates the following files for every class in the CDs of the Object Design phase:<RBW-IDXTERM TERM1="C++ header file" TERM2="generating"></RBW-IDXTERM
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>C++ file containing internal details of a class</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See <RBW-XREF REFID="22643" TYPE="XREF-TEXTCOPY">Chapter 3, Mapping Modeling Data to C++</RBW-XREF
>, for more details.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><BI.BODY.INTRO>The following example shows a class from the CD and the matching C++ and H++ files that would be generated. Notice that the function <CX5FX5FTITLE>PrintAmount</CX5FX5FTITLE
><B.BODY>After the code has been generated, you can relate each generated H++ and C++ file to a specific class in a CD of the Object Design phase.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>H++ header files</L.LABEL
><B.BODY>The generated header files contain all the necessary include statements and do not need editing.</B.BODY
><B.BODY>If, however, you choose to edit an H++ file, you can use the round&truehy;trip engineering task to move your changes back into your model so that they are not lost when you regenerate code. See <RBW-XREF REFID="29914" TYPE="XREF-TEXTCOPY">Round&truehy;Trip Engineering</RBW-XREF
> for more information.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>C++ source files</L.LABEL
><B.BODY>The generated C++ files serve as framework files. They contain a signature for each method (generated from the methods of the classes in the CDs), but the method bodies are empty. You need to fill in the following:</B.BODY
>The bodies of the methods that are defined in the classes. No function is generated for the method. Instead, the following line is generated:</RBW-PARABODY
></LB.LIST.BULLET
><EM.EXAMPLE.MONO>// !! Implement this function !!</EM.EXAMPLE.MONO
> is the name of the method. Until you specify the function, this line results in a warning from the compiler, such as the following (from SUN C++ 2.1):</LT.LIST.TEXT
><EWM.EXAMPLEW.MONO>test.cxx, line 5: warning: test_is_not_yet_implemented not used</EWM.EXAMPLEW.MONO
><RBW-PARABODY>In the Information area, double&truehy;click on the source file that you want to edit, or select the source file and then select File | Edit.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The default Text Editor starts up with the corresponding file in the user environment.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Update diagrams</L.LABEL
><B.BODY>Depending on the type of additions you have made to the source files, you may need to edit the CDs to reflect your changes. If you do so, be sure to use Check | Global Model to check the updated diagrams before regenerating the source files.</B.BODY
><B.BODY>The compiling and linking of an application or library is based on the specifications in the makefile. A makefile, based on the makefile template, can be created automatically by ObjectTeam.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Input for makefile generation</L.LABEL
><B.BODY>The makefile generation process takes the following elements as input:</B.BODY
><LT.LIST.TEXT>This is a (C++ compiler&truehy;specific) customization file that is inserted by ObjectTeam during the configuration of your C++ environment (see <RBW-XREF REFID="40480" TYPE="XREF-TEXTCOPY">Configuring Your C++ Environment</RBW-XREF
><RBW-PARABODY>The name of the target object (executable or library object)</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Implicit makefile generation</L.LABEL
><B.BODY>ObjectTeam automatically creates a makefile if you generate code for entire systems (on Phase level) or new files (on System level) from the Object Design Phase. </B.BODY
><B.BODY>However, as long as there is no target object present in a system, this automatically generated makefile is not usable for compilation. Therefore, this automatic makefile creation is only useful in the following situation:</B.BODY
><RBW-PARABODY>Utilities | Generate C++ | New is selected on Implementation System level</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>The ObjectTeam code generator is now able to determine the name of the target object, the source files (including their dependency), and is therefore able to generate a complete makefile.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Explicit makefile generation</L.LABEL
><B.BODY>You can always explicitly generate (or update) the makefile on Implementation System level using Target | Generate Makefile.</B.BODY
>If you have generated code for a system, ObjectTeam automatically generates a makefile. However, since the name of the target object is not known when code is generated for a system, the makefile has to be (re)generated after you have created a target object.</T.TIP
><RBW-PARABODY>All procedural code in the source files must be completely defined for the implementation of methods resulting from messages sent to a class (such as those that change attribute values, perform computations, or send messages to other classes); see <RBW-XREF REFID="26759" TYPE="XREF-TEXTCOPY">Editing (Generated) Source Files</RBW-XREF
><RBW-PARABODY>The environment properly configured for your chosen language; see <RBW-XREF REFID="40480" TYPE="XREF-TEXTCOPY">Configuring Your C++ Environment</RBW-XREF
><RBW-PARABODY>The selected target object (executable or library) must be the current, writable version; that is, its status must be <CX5FX5FOBJECT.NAME>working</CX5FX5FOBJECT.NAME
><RBW-PARABODY>Select Target | Run from the menu bar.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Conduct a final check for errors</L.LABEL
><B.BODY>As always, before you distribute anything, conduct a quality check of your work. If necessary, fix the source files, fix the ObjectTeam model, regenerate the code, and retest the executable.</B.BODY
>Regenerating Code<RBW-IDXTERM TERM1="code regeneration" TERM2="edited C++ source file"></RBW-IDXTERM
></S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Design changes and code changes</L.LABEL
><B.BODY>ObjectTeam supports incremental development. You can generate code from your models, edit that code, and regenerate the code without losing your changes. You can work with models during design and with code during implementation, shifting your focus between the two as necessary.</B.BODY
><B.BODY>It is, however, important that you make changes where appropriate.</B.BODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Change the code</CX5FX5FBULLET.EMPHASIS
> when you are adding code that is not generated by ObjectTeam (for example, adding method bodies), or when you are making local changes to the code (for example, adding a missing attribute or operation to a class).</RBW-PARABODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Change the model</CX5FX5FBULLET.EMPHASIS
> when you are changing the structure of the model (for example, if you are changing the class hierarchy or class associations), or when you are making global changes to the code (for example, if you are changing the name of a class, attribute, or operation).</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing generated files</L.LABEL
><B.BODY>The generated C++ files are framework files that need some additions before they can be turned into an executable or library. Comments in the file indicate where you should add code, as described in <RBW-XREF REFID="26759" TYPE="XREF-TEXTCOPY">Editing (Generated) Source Files</RBW-XREF
>. When you regenerate a C++ file, the code generator transfers the user&truehy;edited sections from the old file to the newly generated file. </B.BODY
>The code generator preserves only the comment&truehy;delimited areas of the generated C++ file. Changes you make to other areas of the generated C++ file are lost when you regenerate the file.</W.WARNING
><B.BODY>If you modify the ObjectTeam model, you typically regenerate the H++ and C++ source files. As described above, regenerating the H++ file and regenerating the C++ file preserve your changes to the original files.</B.BODY
><B.BODY>If, in the model, you rename, delete, or change the signature of an operation, the matching function in the generated C++ file is no longer correct. ObjectTeam preserves the original function, however, you must edit the generated file to correct the code. </B.BODY
><RBW-PARABODY>When you rename or delete an operation, the function in the generated C++ file is marked as <CX5FX5FBULLET.EMPHASIS>OBSOLETE_CODE</CX5FX5FBULLET.EMPHASIS
>. In this way, the code generator preserves the function in case you want to rename it or move it to another class.</RBW-PARABODY
><RBW-PARABODY>When you change the signature of an operation, the function in the generated C++ file is marked as <CX5FX5FBULLET.EMPHASIS>OLD_CODE</CX5FX5FBULLET.EMPHASIS
>. This allows you to easily find and edit the affected functions.</RBW-PARABODY
>Modeling Data <RBW-SYSOBJ TYPE="MIFmarker"><RBW-DATAFLD TYPE="number">0</RBW-DATAFLD
><RBW-TEXTFLD TYPE="text">Code Generation Guide for C++</RBW-TEXTFLD
></RBW-SYSOBJ
>to C++</C.CHAPTER.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This chapter explains how particular parts of classes and class specifications are generated into C++ code. It provides short examples of CDs and the results produced when you generate C++ code.</B.BODY
>For a complete example application modeled, generated and completed in ObjectTeam see <RBW-XREF REFID="11059" TYPE="XREF-TEXTCOPY">Example Application</RBW-XREF
>.</T.TIP
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="40407" TYPE="XREF-TEXTCOPY">Handling Special ObjectTeam Classes&rbwtab;3–113</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="23714" TYPE="XREF-TEXTCOPY">What is Not Supported by the C++ Code Generator&rbwtab;3–122</RBW-XREF
><B.BODY>In ObjectTeam, a class in a Class Diagram is generated into a header file and a source file, unless the ObjectTeam class is used to model a special C++ construction. The interface of a class is stored in the header file (<RBWAUTO-0017>className</RBWAUTO-0017
>.h), the source code in a C++ source code file (<RBWAUTO-0017>className</RBWAUTO-0017
>In this chapter, the extensions <CX5FX5FFILE.NAME>.h</CX5FX5FFILE.NAME
> and .<CX5FX5FFILE.NAME>cpp</CX5FX5FFILE.NAME
> are used. These are the extensions for generated C++ files on Windows platforms. On UNIX&truehy;based platforms, the extensions are <CX5FX5FFILE.NAME>.hxx</CX5FX5FFILE.NAME
> and <CX5FX5FFILE.NAME>.cxx</CX5FX5FFILE.NAME
> respectively.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Special C++ constructions</L.LABEL
><B.BODY>Besides for modeling C++ classes, you can use ObjectTeam classes for modeling the special C++ constructions (generic) <CX5FX5FINPUT>typedef</CX5FX5FINPUT
>ObjectTeam does not generate code for classes that have the class property External Class Source specified (see <RBW-XREF REFID="41268" TYPE="XREF-TEXTCOPY">Editing Class Properties</RBW-XREF
>).</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="41268"></RBW-ANCHOR
>Editing Class Properties</L.LABEL
><B.BODY>In the Object Design phase, you can define class properties that control the class’s implementation and access level within C++. The code generated for a class is, among other things, based on its property values. </B.BODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>(in external classes): the header file(s) that must be included if the external class is used</CELLBODY
><B.BODY>You can attach notes to your classes using the class property Free Text. What you specify as free text appears as comment lines in the generated header file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>In the following example, free text has been specified for the class <CX5FX5FEMPHASIS>Person</CX5FX5FEMPHASIS
><B.BODY>You must specify the data type of each attribute.</B.BODY
><B.BODY>See <RBW-XREF REFID="19914" TYPE="XREF-TEXTCOPY">Specifying Attribute Data Types</RBW-XREF
> for more information. <RBW-IDXTERM TERM1="attribute" TERM2="default value"></RBW-IDXTERM
><RBW-IDXTERM TERM1="default value, for attribute"></RBW-IDXTERM
><RBW-IDXTERM TERM1="initial value, for attribute"></RBW-IDXTERM
>You can also specify a default value for attributes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="29362"></RBW-ANCHOR
>Editing Attribute Properties</L.LABEL
><B.BODY>In the Object Design phase, you define properties of data attributes. These properties define the access level of the attribute, as well as whether or not the attribute is mandatory (non&truehy;nullable).</B.BODY
><B.BODY>The code generated for a data attribute is based on its properties.To edit attribute properties:</B.BODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>The section in which the attribute’s generated accessor methods must be stored: Public, Protected or Private</CELLBODY
><B.BODY>The standard data types are defined in the customization file <CX5FX5FFILE.NAME><RBW-IDXTERM TERM1="stand_types customization file"></RBW-IDXTERM
>stand_types</CX5FX5FFILE.NAME
>.<CX5FX5FFILE.NAME>stand_types</CX5FX5FFILE.NAME
>. These are the data types that are valid in the Object Design phase.</B.BODY
><B.BODY>The translation between standard data types and C++ data types is defined by the <CX5FX5FFILE.NAME><RBW-IDXTERM TERM1="lang_types customization file"></RBW-IDXTERM
><B.BODY>You can add additional data types to the list of standard types by editing the <CX5FX5FFILE.NAME>stand_types</CX5FX5FFILE.NAME
> customization file. If you add additional standard types, you must also provide translations for those data types by editing the <CX5FX5FFILE.NAME>lang_types</CX5FX5FFILE.NAME
>The class Time could also have been an external class, a class that is defined in another system in the same phase. For more details on external classes, see <RBW-XREF REFID="29909" TYPE="XREF-TEXTCOPY">Handling External Classes</RBW-XREF
><B.BODY>A non&truehy;nullable attribute is an attribute that must have a value. In C++, attributes are added to the <RBW-IDXTERM TERM1="constructor" TERM2="not nullable attribute"></RBW-IDXTERM
>parameter list of the constructor if they are non&truehy;nullable. </B.BODY
>Non&truehy;key attributes are <CX5FX5FOBJECT.NAME>nullable</CX5FX5FOBJECT.NAME
> by default.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="37907"></RBW-ANCHOR
>Key attributes</L.LABEL
><B.BODY>Alternatively, you could make an attribute a key attribute if you want it to be non&truehy;nullable. </B.BODY
><B.BODY>Key attributes are data attributes in an ObjectTeam class with a leading asterisk (*). The generated code for non&truehy;nullable attributes and key attributes is identical but key attributes are immediately visible in a CD, whereas an attribute’s state of being non&truehy;nullable is “hidden” behind a property.</B.BODY
> is a special type of method that gets (reads) and sets (writes) an attribute’s value. By default, the access level of these accessor methods is Public.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Read and Write accessor methods</L.LABEL
><B.BODY>The setting specified in the Read field affects the access level of the attribute accessor method <CX5FX5FINPUT>get</CX5FX5FINPUT
><RBWAUTO-0014>attributeName</RBWAUTO-0014
>; the setting specified in the Write field the attribute accessor method <CX5FX5FINPUT>set</CX5FX5FINPUT
><B.BODY>In C++, the need for unsafe global variables can be minimized by declaring a shared member <CX5FX5FEMPHASIS>static</CX5FX5FEMPHASIS
>. In ObjectTeam, you indicate a data attribute as being static by using a leading dollar sign ($). The attribute itself and its accessor methods will then be made static.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to specify a static attribute</L.LABEL
><B.BODY>You specify a static (class) attribute by adding a leading dollar sign ($) to the attribute name.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>In the example class depicted below, the data attribute <CX5FX5FEMPHASIS>totalCounters </CX5FX5FEMPHASIS
>is a static attribute. The default value of this attribute is 42.</B.BODY
><B.BODY>In C++, methods consist of a method definition in the header file and the C++ source code that is executed when the method is called in the source file. The ObjectTeam C++ code generator generates the method definition and everything else that can be determined from the ObjectTeam model. You have to provide the method implementation code yourself. </B.BODY
><B.BODY>The following generated lines in the source file remind you of this:</B.BODY
><EM.EXAMPLE.MONO>// !! Implement this method !!</EM.EXAMPLE.MONO
><B.BODY>A user&truehy;defined method defined for an ObjectTeam class is generated in a C++ method. Additionally, the C++ code generator generates the following special methods automatically. You do not have to specify them in an ObjectTeam class:</B.BODY
><RBW-PARABODY>Association access methods, as described in <RBW-XREF REFID="10004" TYPE="XREF-TEXTCOPY">Mapping Unidirectional and Bidirectional Associations</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Method syntax</L.LABEL
><B.BODY>In ObjectTeam, you use the following syntax to specify user&truehy;defined methods in a class:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>the name of the method</CELLBODY
></ENTRY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Some special characters are not allowed in operator names. See <RBW-XREF REFID="35965" TYPE="XREF-TEXTCOPY">Overloading Operators</RBW-XREF
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>a pure virtual function</CELLBODY
></ENTRY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>See <RBW-XREF REFID="29156" TYPE="XREF-TEXTCOPY">Specifying Pure Virtual Methods</RBW-XREF
></CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="34259"></RBW-ANCHOR
>Editing method properties</L.LABEL
><B.BODY>You use method properties to provide input to the code generator, such as the access level of method and whether it must be generated as a constant function, a virtual function or an inline function. </B.BODY
><B.BODY>The code generated for a method is partly based on its properties.</B.BODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>The type modifier of the method </CELLBODY
></ENTRY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>This works similar to parameter type modifiers (see <RBW-XREF REFID="40884" TYPE="XREF-TEXTCOPY">Modifying Parameter Types</RBW-XREF
>. A private method can only be accessed by the other methods of its class and by <CX5FX5FEMPHASIS>friends</CX5FX5FEMPHASIS
> of its class.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="31329"></RBW-ANCHOR
>Visibility</L.LABEL
><B.BODY>You can display the access level of methods in your diagram by checking Options | Show Visibility in the Class Diagram Editor. Method names will then be displayed with the following leading characters indicating the method’s access level:</B.BODY
><B.BODY>These special characters can also be used to <CX5FX5FEMPHASIS>set</CX5FX5FEMPHASIS
> the access level of methods. Typing a hatch sign (#) before a method name will set the access level of the method to Protected, for example. </B.BODY
>The special characters only work if the menu entry Options | Show Visibility in the Class Diagram Editor has been checked. Otherwise, the special characters will just be regarded as part of the method name.</W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to specify the access level</L.LABEL
><B.BODY>There are two ways of specifying a method’s access level type:</B.BODY
><B.BODY>An abstract class is a class that can be used only as a base class of some other class. A class is abstract if it has at least one pure virtual function. </B.BODY
><B.BODY>A pure virtual function must not be implemented in the abstract class but in a subclass derived from the abstract class. Therefore, no method body is generated for a pure virtual function.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to specify a pure virtual method</L.LABEL
><B.BODY>You specify a pure virtual method (function) by adding the following trailing keyword to the method name:</B.BODY
><EM.EXAMPLE.MONO>{abstract}</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The first method is abstract, the second is not.</B.BODY
><B.BODY>You can overload operators in ObjectTeam by specifying the operator’s name as method. In some cases, you can use the C++ operators’ syntax; in other cases, you must use specific ObjectTeam operator syntax. The ObjectTeam operator syntax is translated into C++ operators by the code generator.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Operator types</L.LABEL
><B.BODY>The following table lists the operators that you can use:</B.BODY
><B.BODY>Parameters can optionally be added to methods. </B.BODY
><B.BODY>Method parameters are used by the caller of the method to provide input values to the method, to hold output values from the method or both. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Parameter Syntax</L.LABEL
><B.BODY>The parameters in the parameter list are separated by commas. Every parameter needs to have a type, which can either be a standard type or a (user&truehy;defined) class:</B.BODY
>If the type modifier Default is chosen, the code generator determines if a pointer or a type by value is generated.</N.NOTE
><B.BODY>The property Type Modifier can also be used to modify the type of a method.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Location of include statement</L.LABEL
><B.BODY>The <CX5FX5FINPUT>include</CX5FX5FINPUT
> statement for a type is usually placed in the generated <CX5FX5FEMPHASIS>source</CX5FX5FEMPHASIS
> file, and a forward declaration is placed in the generated header file. However, if the type modifier Value has been selected, the include statement is placed in the <CX5FX5FEMPHASIS>header</CX5FX5FEMPHASIS
> file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>User&truehy;defined Type Modifier</L.LABEL
><B.BODY>Instead of selecting a type modifier from the list, you can also enter a user&truehy;defined one using the parameter property Type Modifier. You can enter any string in combination with the variable <CX5FX5FINPUT>~$name</CX5FX5FINPUT
>, which indicates the type’s name:</B.BODY
><B.BODY>For the following user&truehy;defined type modifier, for example, the same code as for the type modifier Pointer will be generated:</B.BODY
>Specifying a Parameter’s Default Value</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Default value</L.LABEL
><B.BODY>In a call to a method, valid values for the method’s parameters <CX5FX5FEMPHASIS>must</CX5FX5FEMPHASIS
> be supplied, unless a default value has been specified. If a parameter has a default value, the parameter value <CX5FX5FEMPHASIS>can</CX5FX5FEMPHASIS
> be specified in the call, overriding the default value. </B.BODY
><B.BODY>Parameters with a default value are usually referred to as optional parameters; parameters without a default value as required parameters.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to specify a default value</L.LABEL
><B.BODY>You specify a parameter’s default value through the following parameter property:</B.BODY
>You must add the <CX5FX5FINPUT>$create</CX5FX5FINPUT
> method for classes with only one attribute, otherwise the C++ code generator will generate a typedef construction for these classes (see <RBW-XREF REFID="24618" TYPE="XREF-TEXTCOPY">Mapping Typedef Classes</RBW-XREF
>).</N.NOTE
><B.BODY>The C++ code generator regards classes without any attributes or methods as external classes, unless a <CX5FX5FINPUT>$create</CX5FX5FINPUT
> method is specified.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>$create with non&truehy;nullable attributes</L.LABEL
><B.BODY>The C++ code generator adds non&truehy;nullable attributes (see <RBW-XREF REFID="35790" TYPE="XREF-TEXTCOPY">Specifying Mandatory Attributes</RBW-XREF
>) to the parameter list of the constructor:</B.BODY
>The generalization from Employee into HourlyEmployee and VestedEmployee must be overlapping (see <RBW-XREF REFID="29888" TYPE="XREF-TEXTCOPY">Specifying Virtual Inheritance</RBW-XREF
><B.BODY>A class can have multiple base classes: multiple inheritance is allowed in C++. However, the same base class is allowed to occur only once in the class hierarchy, unless virtual inheritance is used.</B.BODY
><B.BODY>You can specify a particular inheritance to be virtual by using the Overlapping Generalization symbol.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example </L.LABEL
><B.BODY>In the following example, the classes HourlyEmployee and VestedEmployee are both derived from the base class Employee.</B.BODY
><B.BODY>The class VestedHourlyEmployee is, in turn, derived from the class HourlyEmployee and VestedEmployee. This implies that in the class hierarchy of the class VestedHourlyEmployee, the class Employee occurs twice, which is not allowed in C++.</B.BODY
><B.BODY>Now if the generalization of Employee is made <CX5FX5FEMPHASIS>overlapping</CX5FX5FEMPHASIS
> &truehy; the inheritance is specified as <CX5FX5FEMPHASIS>virtual</CX5FX5FEMPHASIS
> &truehy; the classes HourlyEmployee and VestedEmployee only <CX5FX5FEMPHASIS>refer</CX5FX5FEMPHASIS
> to the class Employee, which is allowed in C++.</B.BODY
>Set the Generalization property Inheritance Access to indicate whether the access level of the methods inherited from the base class must be Public (default), Protected or Private.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example </L.LABEL
><B.BODY>In the following example, the Inheritance Access of the generalization has been set to Protected:</B.BODY
><B.BODY>The C++ code generator does not distinguish between associations and aggregations; for both constructions identical code is generated. This section uses the term <CX5FX5FEMPHASIS>association</CX5FX5FEMPHASIS
> to indicate associations and aggregations.</B.BODY
><B.BODY>N&truehy;ary associations are ignored by the C++ code generator. Code is generated for the classes involved, but not for the associations.</B.BODY
>The ObjectTeam documentation use the term <CX5FX5FTERM>association attribute</CX5FX5FTERM
> to refer to attributes that are generated to support ObjectTeam associations (as opposed to data attributes generated from ObjectTeam attributes). </B.BODY
><B.BODY>The role name at the appropriate end of the association is used as a base for generating association attributes.</B.BODY
>The access level of generated association attributes is always <CX5FX5FEMPHASIS>private</CX5FX5FEMPHASIS
>. The type of the association attribute depends on the multiplicity at the other end of the association and the class library that is used to implement the association.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Implementation strategies</L.LABEL
><B.BODY>The implementation strategy that is used for a particular association end depends on the association’s multiplicity. Which strategy is used is expressed in the association attribute’s type. This type depends on the current class library.</B.BODY
>In some class libraries, there is more than one implementation strategy available for a particular type of association. There is always a default strategy defined, but you can select another implementation strategy using the association attribute property Implementation Strategy (see <RBW-XREF REFID="19988" TYPE="XREF-TEXTCOPY">Specifying an Implementation Strategy</RBW-XREF
>).</T.TIP
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Association accessor methods</L.LABEL
><B.BODY>The C++ code generator generates accessor methods for association attributes, similar to accessor methods generated for user&truehy;defined attributes. Association accessor methods maintain associations between classes.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>For the following example association, an association attribute and corresponding accessor methods are generated.</B.BODY
>By default, the access level of generated association accessor methods is <CX5FX5FEMPHASIS>public</CX5FX5FEMPHASIS
>. Edit the role name’s properties to change the access level of a <CX5FX5FEMPHASIS>get</CX5FX5FEMPHASIS
> (=Read) or <CX5FX5FEMPHASIS>set</CX5FX5FEMPHASIS
> (=Write) accessor method to <CX5FX5FEMPHASIS>protected</CX5FX5FEMPHASIS
> or <CX5FX5FEMPHASIS>private</CX5FX5FEMPHASIS
>. See <RBW-XREF REFID="34414" TYPE="XREF-TEXTCOPY">Specifying Association Accessor Method Access</RBW-XREF
>.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="32778"></RBW-ANCHOR
>Editing association attribute properties</L.LABEL
><B.BODY>You can effect the way association accessor methods are generated by editing the properties of the corresponding role name in ObjectTeam.</B.BODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>The implementation strategy from the selected class library that must be used to implement the association</CELLBODY
></ENTRY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="31321" TYPE="XREF-TEXTCOPY">Specifying a Class Library</RBW-XREF
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Optional association attribute comments</CELLBODY
></ENTRY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>See <RBW-XREF REFID="25709" TYPE="XREF-TEXTCOPY">Specifying Free Text for an Association Attribute</RBW-XREF
><RBW-PARABODY>Change the property values of your choice and click OK.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>In the remaining part of this section examples of associations with different combinations of multiplicity are discussed, including the implied consequences for updating the association.</B.BODY
><B.BODY>These consequences are reflected in the get, set, add and remove method implementations generated for the classes in these associations. </B.BODY
><B.BODY>This section contains the following topics:</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="40782" TYPE="XREF-TEXTCOPY">Mapping an Optional &truehy; Many Association&rbwtab;3–66</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="30073" TYPE="XREF-TEXTCOPY">Mapping a Mandatory &truehy; Many Association&rbwtab;3–68</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="24577" TYPE="XREF-TEXTCOPY">Mapping Many &truehy; Many Association&rbwtab;3–69</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="14505" TYPE="XREF-TEXTCOPY">Using an Association with a Multiplicity of Many&rbwtab;3–71</RBW-XREF
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="38957" TYPE="XREF-TEXTCOPY">Mapping Association Classes&rbwtab;3–76</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="34414" TYPE="XREF-TEXTCOPY">Specifying Association Accessor Method Access&rbwtab;3–79</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="31321" TYPE="XREF-TEXTCOPY">Specifying a Class Library&rbwtab;3–80</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="19988" TYPE="XREF-TEXTCOPY">Specifying an Implementation Strategy&rbwtab;3–82</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="25709" TYPE="XREF-TEXTCOPY">Specifying Free Text for an Association Attribute&rbwtab;3–85</RBW-XREF
>The C++ code generator implements a unidirectional association by adding an <CX5FX5FEMPHASIS>association attribute</CX5FX5FEMPHASIS
> and a set of <CX5FX5FEMPHASIS>association accessor methods</CX5FX5FEMPHASIS
> to the code generated for the class at the near end of the association. </B.BODY
><B.BODY>This allows the class at the near of the association (Customer) to access the class at the far end (Book). Since no association accessor methods are generated for the class at the far end, the class at the far end cannot access the class at the near end.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="21654"></RBW-ANCHOR
>Mapping a bidirectional association</L.LABEL
><B.BODY>The C++ code generator implements a bidirectional association by adding an <CX5FX5FEMPHASIS>association attribute</CX5FX5FEMPHASIS
> and a set of <CX5FX5FEMPHASIS>association accessor methods </CX5FX5FEMPHASIS
>to the code generated for both classes. Moreover, both classes are specified as <CX5FX5FEMPHASIS>friend</CX5FX5FEMPHASIS
> classes.</B.BODY
><B.BODY>This allows each class to access the other. To ensure integrity of a bidirectional association, the update method for a bidirectional association maintains the association in both directions.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>Following is an excerpt from the code generated for the Book class in the bidirectional association. Because this is a bidirectional association, the Book class and the Customer class contain similar code to implement the association in the other direction.</B.BODY
><B.BODY>When an object B is constructed, a pointer to an object A must be set, since the association is mandatory at A’s end. This pointer is set in the constructor of class B.</B.BODY
><B.BODY><CX5FX5FFILE.NAME>B.h</CX5FX5FFILE.NAME
> (generated file)</B.BODY
><EM.EXAMPLE.MONO>...</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>class B {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> friend class A;</EM.EXAMPLE.MONO
><B.BODY>If an object A is associated with an object B in a mandatory &truehy; optional association, it cannot be associated with a different B because that would leave the old B unattached. </B.BODY
><B.BODY>The only way to update the association is to attach an object B to an object A that was previously unattached. This leaves the old object A unattached and the pointer to the object B must therefore be set to 0.</B.BODY
><B.BODY>In a mandatory &truehy; mandatory association, each object must have a pointer to an object of the other class. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Not supported</L.LABEL
><B.BODY>An association having a mandatory multiplicity at both ends is not supported by the ObjectTeam C++ code generator. </B.BODY
><B.BODY>The reason is that it is logically impossible to construct objects of either class, since in a mandatory&truehy;mandatory association, both classes need a constructed object at the other end in order to construct objects.</B.BODY
><B.BODY>When an optional &truehy; optional association is updated, the old association must first be removed on both sides before the new association can be created.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The following picture shows a situation where an object A (Ax) is associated with an object B (Bx), and another object A (Ay) is associated with another object B (By). </B.BODY
><B.BODY>In an optional &truehy; many association, objects at the optional end (A) have a set of pointers to objects at the many end (B). Objects at the many end (B) have a pointer to an object at the optional end (A).</B.BODY
><B.BODY>When a pointer to an object B is added to the pointer set of an object A, the pointer must first be removed from the pointer set of the old object A (if the object B was already associated).</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The following picture shows two objects A: Ax and Ay. The pointer set of Ax contains, among other things, a pointer to Bz.</B.BODY
><B.BODY>In a mandatory &truehy; many association, objects at the mandatory end (A) have a set of pointers to objects at the many end (B). Objects at the many end (B) have a pointer to an object at the optional end (A).</B.BODY
><B.BODY>Updating a mandatory &truehy; many association is similar to updating an optional &truehy; many association (see <RBW-XREF REFID="40782" TYPE="XREF-TEXTCOPY">Mapping an Optional &truehy; Many Association</RBW-XREF
>). However, in a mandatory association, unattached objects A are not allowed.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Removing an association</L.LABEL
><B.BODY>It is impossible to remove a pointer to an object B from an object A without adding it to another object A, since that would leave the object B unattached. Unattached B objects are not allowed because the multiplicity at the other end of B is mandatory.</B.BODY
><B.BODY>Therefore, no remove method is generated for mandatory &truehy; many associations. A warning message in the Monitoring Window will inform you about this when code is being generated.</B.BODY
><B.BODY>In a many &truehy; many association, objects at the first many end (A) have a set of pointers to objects at the second many end (B). Objects at the second many end (B) have a set of pointer to objects at the first many end (A) too.</B.BODY
><B.BODY>When a pointer to an object B is removed from an object A’s pointer set, (e.g. the pointer to Bx is removed from Ax’s pointer set), the corresponding pointer to object A must also be removed from object B.</B.BODY
><RBW-PARABODY><RBW-XREF REFID="24577" TYPE="XREF-TEXTCOPY">Mapping Many &truehy; Many Association</RBW-XREF
></RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><BI.BODY.INTRO>The following picture shows an example of a mandatory &truehy; many association. The class at the <CX5FX5FEMPHASIS>mandatory</CX5FX5FEMPHASIS
> end acts as master (<CX5FX5FINPUT>classA</CX5FX5FINPUT
>), the class at the <CX5FX5FEMPHASIS>many</CX5FX5FEMPHASIS
> end as detail (<CX5FX5FINPUT>classB</CX5FX5FINPUT
><B.BODY>In our example, the name of this <CX5FX5FINPUT>get</CX5FX5FINPUT
> method is: <CX5FX5FINPUT>getDetailSet</CX5FX5FINPUT
>. </B.BODY
><B.BODY>The type of the method <CX5FX5FINPUT>getDetailSet</CX5FX5FINPUT
> is <CX5FX5FINPUT><RBW-IDXTERM TERM1="PtrSet"></RBW-IDXTERM
>PtrSet</CX5FX5FINPUT
>. <CX5FX5FINPUT>PtrSet</CX5FX5FINPUT
> is one of the storage structure classes that is included in the Cayenne class library (see <RBW-XREF REFID="40480" TYPE="XREF-TEXTCOPY">Configuring Your C++ Environment on page 2–7</RBW-XREF
>). It is used for <RBW-IDXTERM TERM1="pointer set"></RBW-IDXTERM
>pointer sets. </B.BODY
><B.BODY>Typical member functions of the class <CX5FX5FINPUT>PtrSet</CX5FX5FINPUT
><B.BODY>These functions return the pointers to the detail objects that participate in the association.</B.BODY
><B.BODY>Before you are able to retrieve (<CX5FX5FINPUT>get</CX5FX5FINPUT
>) objects from a PtrSet class, these objects first have to be added to the association. The master class contains methods which allow adding (and removing) detail objects. </B.BODY
><B.BODY>This section assumes that you are familiar with the section <RBW-XREF REFID="14505" TYPE="XREF-TEXTCOPY">Using an Association with a Multiplicity of Many</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Ordered association</L.LABEL
><B.BODY>Here is an example of an ordered association. </B.BODY
>The mapping of an ordered association is similar to that of an association with an unordered multiplicity of many; however, the implementation strategy that is used is slightly different.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Cayenne class library</SL.SUBLABEL
><B.BODY>If you are using the Cayenne class library, the class OPtrSet is used to implement ordered associations, whereas PtrSet is used to implement unordered associations in an optional &truehy; many association. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example code</L.LABEL
><B.BODY>Following is an excerpt from the code generated for the Customer class shown above.</B.BODY
><B.BODY>This section assumes that you are familiar with the mapping of various types of associations, as described in the previous sections.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Association class</L.LABEL
><B.BODY>ObjectTeam allows you to specify information about an association by an association class. The class Purchase in the following diagram is an association class.</B.BODY
><B.BODY>The C++ code generation converts a construction with an association class into a construction where the association class is associated with both the other classes by normal associations. The role names are converted into <CX5FX5FVARIABLE>linkClassName</CX5FX5FVARIABLE
>Of<CX5FX5FEMPHASIS>roleName</CX5FX5FEMPHASIS
></B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The code generated for the CD shown above is actually based on the following CD:</B.BODY
><B.BODY>As with all associations, role names are required. If a role name is omitted, the association attributes and corresponding accessor methods that would map to that role name are not generated.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Qualified association class</L.LABEL
><B.BODY>Qualified associations with association classes are treated similarly by the C++ code generator; the association is converted into a construction where the association class is associated with the other classes by a normal associations.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><BI.BODY.INTRO>Following is the code generated for the classes from the CD shown above.</BI.BODY.INTRO
>Specifying Association Accessor Method Access</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>The C++ code generator generates accessor methods for every class: in an association that has a role name specified at the other end of the association (see <RBW-XREF REFID="21654" TYPE="XREF-TEXTCOPY">Mapping a bidirectional association</RBW-XREF
><B.BODY>You can specify the access level of these methods, that is, you can instruct the code generator in which section (Public, Protected, Private) these methods must be generated.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Read and Write accessor methods</L.LABEL
><B.BODY>The setting specified in the Read field affects the attribute accessor method <CX5FX5FINPUT>get</CX5FX5FINPUT
><RBWAUTO-0014>roleName</RBWAUTO-0014
>; the setting specified in the Write field the attribute accessor method <CX5FX5FINPUT>set</CX5FX5FINPUT
><RBWAUTO-0018>roleName</RBWAUTO-0018
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Access level types</L.LABEL
><B.BODY>The following types of access level can be selected for association accessor methods (Read and Write):</B.BODY
><B.BODY>The C++ code generator uses the information from a class library to implement various types of (qualified) associations. </B.BODY
><B.BODY>Integrations of ObjectTeam with class libraries is controlled by modules. Which class library can be used for the implementation of an association therefore depends on the modules that are currently active.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>If you are using the Cayenne class library, for example, the generated type for the association attribute at the Customer end in the following example will be a PtrSet. This information is retrieved from the Cayenne class library, just like the information needed to generate the implementations of the corresponding accessor methods.</B.BODY
><B.BODY>If another class library is used, the type of the association attribute may be different, just like the implementation of the accessor methods may be different. The names of the accessor methods, however, remain the same across different class libraries. Their implementation may still vary.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Available class libraries</L.LABEL
><B.BODY>Besides the Cayenne class library, the C++ code generator is also integrated with other class libraries to implement associations:</B.BODY
><B.BODY>You can have multiple active class library modules in ObjectTeam, but there is only one default class library. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Default class library</L.LABEL
><B.BODY>If you have multiple class library modules active, there is only one default class library: the last one in the list of active class library modules.</B.BODY
>In this example, the Rogue Wave class library is the default.</T.TIP
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Overruling the default class library</L.LABEL
><B.BODY>For every individual end of an association with a role name you can instruct the C++ code generator to use an (active) class library other than the default.</B.BODY
><B.BODY>You can do that using the association attribute property Class Library, which can be found in the Edit Properties dialog box on the Class Lib page.</B.BODY
>Specifying an Implementation Strategy</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Available strategies</L.LABEL
><B.BODY>In some class libraries (see <RBW-XREF REFID="40480" TYPE="XREF-TEXTCOPY">Configuring Your C++ Environment</RBW-XREF
>), multiple implementation strategies or storage structures have been made available for a particular association with a certain multiplicity. </B.BODY
><B.BODY>In the Rogue Wave class library, for example, you have a choice between the following implementation strategies for associations ends having a multiplicity of <CX5FX5FEMPHASIS>many</CX5FX5FEMPHASIS
> at the opposite side. (see the role name <CX5FX5FEMPHASIS>customer</CX5FX5FEMPHASIS
><B.BODY>This file can be found in the <CX5FX5FFILE.NAME>tcl</CX5FX5FFILE.NAME
> directory of every class library module. It contains a mapping of association type indications (Ptr, Set, Dict, etc.) to implementation strategy indications to Tcl class names. </B.BODY
><B.BODY>For Rogue Wave, for example, this mapping table looks like this:</B.BODY
><B.BODY>The Tcl classes contain the information required by the C++ code generator to generate the type of the association attribute and the bodies of the corresponding accessor methods.</B.BODY
><B.BODY>The association type indications must be read as follows:</B.BODY
>For more information on customizing class libraries</SL.SUBLABEL
><B.BODY>See <RBW-XREF REFID="32178" TYPE="XREF-TEXTCOPY">Customizing Class Libraries</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Overruling the default implementation strategy</L.LABEL
><B.BODY>Depending on what has been defined in the <CX5FX5FFILE.NAME>cppclprop.tcl</CX5FX5FFILE.NAME
> file of the selected class library, you can select various implementation strategies for the implementation of a particular association end.</B.BODY
><B.BODY>You can choose a strategy other than the default using the association attribute property Implementation Strategy, which can be found in the Edit Properties dialog box on the Class Lib page.</B.BODY
>Specifying Free Text for an Association Attribute</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Free Text</L.LABEL
><B.BODY>Free text entered for role names in an association are inserted as C++ comments near the corresponding association attribute definition in the generated header file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>In the following example, free text has been specified for the role name <CX5FX5FEMPHASIS>customer</CX5FX5FEMPHASIS
>. The definition of the corresponding association attribute is stored in the generated header file of the class at the opposite end: Book.</B.BODY
> describes the mapping of non&truehy;qualified associations with various multiplicity types. This section assumes that you are familiar with that information.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This section describes the general concepts behind the code that is generated for qualified associations with various multiplicity types:</B.BODY
><B.BODY>This is an example of a qualified association:</B.BODY
><B.BODY>You can use qualified associations to model dictionaries of pointers to certain objects. The qualifier acts as the key to the dictionary.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Association attribute</L.LABEL
><B.BODY>The attributes that are generated to support ObjectTeam associations are referred to as association attributes. The role name at the appropriate end of the qualified association is used as a base for generating association attributes.</B.BODY
><B.BODY>The type of the association attribute reflects the strategy that is used to implement the association at the qualifier end. This strategy depends on:the multiplicity at the other end and on the active class library.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Implementation strategies</L.LABEL
><B.BODY>The implementation strategy used to implement a qualified association at the qualifier end (Customer, for example) is a <CX5FX5FEMPHASIS>dictionary of pointers</CX5FX5FEMPHASIS
>. This strategy is reflected in the type of the association attribute. Which dictionary type is used depends on:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>pointer set dictionary</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
><B.BODY>In such a pointer (set) dictionary, the qualifier name is the dictionary key, and the data type of the qualifier is the key type. The data in the dictionary is:</B.BODY
><RBW-PARABODY>a set of pointers to objects at the other end (Book) for a pointer <CX5FX5FEMPHASIS>set</CX5FX5FEMPHASIS
> dictionary</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Cayenne class library</SL.SUBLABEL
><B.BODY>If you are using the Cayenne class library, the following association attribute types are used for implementing these qualified associations:</B.BODY
>In some class libraries, there is more than one implementation strategy available for a particular type of association. There is always a default strategy defined, but you can select another implementation strategy using the association attribute property Implementation Strategy (see <RBW-XREF REFID="19988" TYPE="XREF-TEXTCOPY">Specifying an Implementation Strategy</RBW-XREF
>).</T.TIP
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Association accessor methods</L.LABEL
><B.BODY>Depending on the data structure of the association attribute type (pointer dictionary or pointer set dictionary), the following accessor methods are generated for a class at the qualifier end.</B.BODY
>The remove method is not generated if the multiplicity at the qualifier end is mandatory</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="27543"></RBW-ANCHOR
>Data type of the qualifier</L.LABEL
><B.BODY>Qualifiers in qualified associations must have a data type, which can be specified through the qualifier property Data Type. Valid data types are standard types or class types. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Cayenne class library</SL.SUBLABEL
><B.BODY>If the Cayenne class library is part of your C++ environment (see <RBW-XREF REFID="40480" TYPE="XREF-TEXTCOPY">Configuring Your C++ Environment on page 2–7</RBW-XREF
>), data types of qualifiers must be <RBW-IDXTERM TERM1="data type" TERM2="hashable"></RBW-IDXTERM
><RBW-IDXTERM TERM1="hashable data type"></RBW-IDXTERM
>hashable data types. The following classes from the Cayenne class library support hashable data types:</B.BODY
>Hashable, which is also part of the Cayenne class library, is the superclass of the classes IntHash and StringHash. You can specify any class as data type for a qualifier, as long as its superclass is the class Hashable. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Bidirectional qualified associations </L.LABEL
><B.BODY>In the example depicted above, every Book object keeps track of the Customer object it is associated with, or, if the multiplicity at the qualifier side is many, the <CX5FX5FEMPHASIS>set</CX5FX5FEMPHASIS
> of associated Customer objects. Hence, the associated Customer object(s) can always be retrieved from a Book object.</B.BODY
><B.BODY>Bear in mind, however, that if you make the association bidirectional by putting a role name at the side of the qualifier, Book objects do not keep track of the qualifier, or the set of qualifiers used to establish the association with Customer object(s). The attribute <CX5FX5FVARIABLE>roleName</CX5FX5FVARIABLE
> (or, in the case of a many association <CX5FX5FVARIABLE>roleNameSet</CX5FX5FVARIABLE
>) that is generated for Book will not contain the qualifier, and will return the same as in a non&truehy;qualified association.</B.BODY
><RBW-PARABODY>Change the property values of your choice and click OK.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>Following is an excerpt from the header file for the Customer class shown above. The data type of the qualifier bookID is IntHash, which is a hashable data type from the Cayenne class library. The IntHash class must be defined in another system as external class.</B.BODY
><B.BODY>The following association accessor methods are generated:</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="26001" TYPE="XREF-TEXTCOPY">Mapping an Optional &truehy; Many Qualified Association&rbwtab;3–96</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="40669" TYPE="XREF-TEXTCOPY">Mapping a Many &truehy; Optional Qualified Association&rbwtab;3–99</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="37998" TYPE="XREF-TEXTCOPY">Mapping a Many &truehy; Mandatory Qualified Association&rbwtab;3–102</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="33442" TYPE="XREF-TEXTCOPY">Mapping a Many &truehy; Many Qualified Association&rbwtab;3–103</RBW-XREF
><B.BODY>In a mandatory &truehy; {mandatory | optional | many} association, objects at the qualifier end (A) have a pointer dictionary to objects at the other end (B). Objects at the other end (B) have a pointer to an object at the qualifier end (A).</B.BODY
><B.BODY>The C++ code generator does not generate any methods for updating an association with a multiplicity of mandatory at the qualifier end. It does not generate the required constructor parameters for both classes either (see <RBW-XREF REFID="22663" TYPE="XREF-TEXTCOPY">Constructors</RBW-XREF
><B.BODY>In an optional &truehy; optional association, objects at the qualifier end (A) have a pointer dictionary to objects at the other end (B). Objects at the other end (B) have a pointer to an object at the qualifier end (A).</B.BODY
><B.BODY>When an optional &truehy; optional association is updated, the old association must first be removed before the new association can be created.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The following picture shows a situation where an object A (Ax) is associated with two B objects:</B.BODY
><B.BODY>The update consequences for optional &truehy; mandatory associations are similar to those of optional &truehy; optional associations (see <RBW-XREF REFID="13331" TYPE="XREF-TEXTCOPY">Mapping a Optional &truehy; Optional Qualified Association</RBW-XREF
>).</B.BODY
><B.BODY>The additional restriction for optional &truehy; mandatory associations is that a pointer to a B object can never be zero.</B.BODY
><B.BODY>In an optional &truehy; many association, objects at the qualifier end (A) have a dictionary of pointers to objects at the other end (B). Objects at the other end (B) have a set of pointers to A objects.</B.BODY
><B.BODY>When an optional &truehy; many association is updated, and the new object B already has an association with an object A, this association must be removed first. The object A must delete the old object B from its dictionary and the old object B must set its pointer to 0.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The following picture shows a situation where an object A (Ax) is associated with two B objects:</B.BODY
><B.BODY>In a many &truehy; optional association, objects at the qualifier end (A) have a dictionary of pointers to objects at the other end (B). Objects at the other end (B) have a set of pointers to A objects.</B.BODY
><B.BODY>When a new object B is added, and the current qualifier already has an object B attached to it, this association should be removed first. The pointer to the A object must also be removed from object B’s pointer set.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The following picture shows a situation where an object A (Ax) is associated with two B objects:</B.BODY
><B.BODY>The update consequences for many &truehy; mandatory associations are similar to those for many &truehy; optional associations (see <RBW-XREF REFID="40669" TYPE="XREF-TEXTCOPY">Mapping a Many &truehy; Optional Qualified Association</RBW-XREF
>).</B.BODY
><B.BODY>The additional restriction for many &truehy; mandatory associations is that a pointer to a B object can never be zero.</B.BODY
><B.BODY>In a many &truehy; many association, objects at the qualifier end (A) have a dictionary of pointers to objects at the other end (B). Objects at the other end (B) have a set of pointers to A objects.</B.BODY
>The mapping of an ordered qualified association is similar to that of a qualified association with an unordered multiplicity of many; however, the implementation strategy that is used is slightly different.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Cayenne class library</SL.SUBLABEL
><B.BODY>If you are using the Cayenne class library, the class OPtrDict implements ordered qualified associations, whereas PtrDict implements unordered associations with a multiplicity of many at the other end. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example code</L.LABEL
><B.BODY>Following is an excerpt from the code generated for the Customer class shown above. The data type of the qualifier BookID is IntHash, a class from the Cayenne class library.</B.BODY
><B.BODY>An external class is a class that is defined in another system in the same phase.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class as type</L.LABEL
><B.BODY>You can use a standard type or a class name (class type) to indicate the type of an attribute, parameter or method. This class can be defined in the same system or in another system in the same phase. If it is defined in another system, it is referred to as an <CX5FX5FEMPHASIS>external class</CX5FX5FEMPHASIS
>.</B.BODY
><B.BODY>The header file that belongs to the external class is included in the file that is generated for the class in which the external class type is used</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example class</SL.SUBLABEL
><B.BODY>The class Date is defined in another system in the same phase.</B.BODY
> in the makefile indicates the (relative) directory paths searched for include files during compilation and linking. By default, these are the user environment directories of all systems within the same phase.</B.BODY
>You can change the default INCS variable specification by customizing the makefile template file <CX5FX5FFILE.NAME>maketmpl.maketmpl</CX5FX5FFILE.NAME
>If a header file cannot be found, an error message is issued and no code will be generated.</W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>External classes and the Cayenne class library</L.LABEL
><B.BODY>If you are using the Cayenne class library, the <CX5FX5FFILE.NAME>include</CX5FX5FFILE.NAME
> directory in your user environment (where the include files were copied to during the configuration of your C++ environment) is part of this set of directories as well.</B.BODY
><B.BODY>The directory in which the header files of the Cayenne class library are stored (the <CX5FX5FFILE.NAME>include</CX5FX5FFILE.NAME
> directory in your user environment, that is) is already part of the default <CX5FX5FINPUT>INCS</CX5FX5FINPUT
> variable specification in the makefile. Therefore, it will be sufficient to just create a class by the same name (e.g. String) in another system. Do not add any attributes or methods to this class. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example Class</SL.SUBLABEL
><B.BODY>The example class Person contains an attribute <CX5FX5FEMPHASIS>name</CX5FX5FEMPHASIS
>, whose data type is String. The class String is defined in another system. The header file <CX5FX5FFILE.NAME>String.h</CX5FX5FFILE.NAME
> will be included in the generated file <CX5FX5FFILE.NAME>Person.h</CX5FX5FFILE.NAME
>. As the <CX5FX5FFILE.NAME>include</CX5FX5FFILE.NAME
> directory is part of the <CX5FX5FINPUT>INCS</CX5FX5FINPUT
> variable specification in the makefile, the linker will be able to locate this file.</B.BODY
><B.BODY>The initial scope of a class is Phase, so if an external class is used to indicate the type of an attribute, for example, the class is known to that system. However, if the scope of the external class was pushed down to system level, its definition would be obscured, and the other system would not be able to find the external class.</B.BODY
><B.BODY>You can use external classes to have a particular header file (or multiple header files) included in a generated file. You specify external header files through the class property External Include List.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example Class</L.LABEL
><B.BODY>This example class contains a data attribute with the type Date. This is the name of a class that is defined in another system. The class Date does not have any attributes or methods but it does have the header file <CX5FX5FFILE.NAME>datefmt.h</CX5FX5FFILE.NAME
><B.BODY>It can be useful to model classes for which source files and header files are already available; for example, when you are using an external GUI builder.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>External header file</L.LABEL
><B.BODY>With the property External Class Source, you can specify the name of the header file whose contents must be used instead of the header file that would normally have been generated for the class.</B.BODY
><B.BODY>During code generation, the contents of the specified header file are copied over to the file <RBWAUTO-0017>className</RBWAUTO-0017
>.h.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>External header and source file</L.LABEL
><B.BODY>You can also specify the name of a header file <CX5FX5FEMPHASIS>and</CX5FX5FEMPHASIS
> a source file as value of the External Class Source property. The contents of the first file is copied over to the file <RBWAUTO-0017>className</RBWAUTO-0017
>.h, that of the second to the file <RBWAUTO-0017>className</RBWAUTO-0017
> mechanism in C++ allows you to introduce synonyms for existing predefined, derived, and user&truehy;defined data types. The syntax for a typedef is:</B.BODY
><RBW-PARABODY>has no associations with a link attribute or an association as class (see <RBW-XREF REFID="38957" TYPE="XREF-TEXTCOPY">Mapping Association Classes</RBW-XREF
>)</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>The typedef class name is generated into the typedef <CX5FX5FVARIABLE>identifier</CX5FX5FVARIABLE
>, the attribute type into the typedef <CX5FX5FVARIABLE>dataType</CX5FX5FVARIABLE
><B.BODY>For every class that has only one data attribute and no methods, the C++ code generator generates a typedef construction.</B.BODY
><B.BODY>However, you may have such classes in your model for which you do not want to generate a typedef. The way of getting around this is to add the following method to the class:</B.BODY
><EM.EXAMPLE.MONO>$create</EM.EXAMPLE.MONO
><B.BODY>This method signals the C++ generator to handle the class as a regular class.</B.BODY
><RBW-PARABODY>Pointer set dictionary</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>In ObjectTeam, you model a generic typedef by associating a typedef class with the class you want to specify the typedef for. Which C++ construction is used in the typedef is determined by the following two factors:</B.BODY
><RBW-PARABODY>Draw an association between the typedef class you have just drawn (class A) and the class for which you want to generate the generic typedef (class B).</RBW-PARABODY
><B.BODY>The class name is not important. </B.BODY
><B.BODY>The attributes of an Enum class are generated into enumerators. Default values can be specified for these attributes, but are not required.</B.BODY
>What is Not Supported by the C++ Code Generator</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>ObjectTeam allows you to draw certain constructions or to use certain diagram objects in a CD that are ignored by the C++ code generator, for example:</B.BODY
>A ternary association can often be represented differently, for instance by introducing a fourth class that manages the association’s constraints.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Multiplicity constraints</L.LABEL
><B.BODY>Multiplicity constraints other than <CX5FX5FEMPHASIS>1+</CX5FX5FEMPHASIS
> are ignored by the C++ code generator. Multiplicity constraints are specified by a multiplicity specification string.</B.BODY
><B.BODY>Multiple associations can be drawn between two classes. With the Constraint symbol you can specify a subset constraint between two associations. Subset constraints have no meaning for the C++ code generator.</B.BODY
><B.BODY>In an association between two classes, you can indicate the propagation of an operation using the Propagation symbol. Propagations have no meaning for the C++ code generator.</B.BODY
><RBW-TEXTFLD TYPE="text">Code Generation Guide for C++</RBW-TEXTFLD
></RBW-SYSOBJ
></C.CHAPTER.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="project" TERM2="using data from other sources"></RBW-IDXTERM
>This chapter describes how to use reverse engineering and round&truehy;trip engineering with the C++ code generator.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Reverse engineering</L.LABEL
><B.BODY>One of the benefits of an object&truehy;oriented design methodology is its support for the reuse of software components. <CX5FX5FEMPHASIS>Reverse engineering</CX5FX5FEMPHASIS
> facilitates this by allowing you to use existing C++ code in your project. This code may come from other projects or from third&truehy;parties, such as class library vendors or public domain software sites.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Round&truehy;trip engineering</L.LABEL
><B.BODY>The C++ code generator generates header files and source files.</B.BODY
> are complete when they are generated and do not normally need to be edited. However, if you do edit them, you can often use <CX5FX5FEMPHASIS>round&truehy;trip engineering</CX5FX5FEMPHASIS
> to move your changes back into the CDMs of the Object Design phase. This ensures that your changes are preserved when you regenerate the header files.</RBW-PARABODY
>, which must be edited, include comments that indicate where you should add code. If you add code only in the places indicated, when you regenerate the source file, ObjectTeam copies your changes to the new source files.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
>Reverse engineering parses C++ header files and builds CDs and CDMs that show the class hierarchy defined in the header files. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose </L.LABEL
><B.BODY>Use reverse engineering to capture and display the class hierarchy of a class library so that you can reuse the classes in the library. Reverse engineering:</B.BODY
><RBW-PARABODY>Helps you to understand the structure and functionality of class libraries.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Not an import utility</SL.SUBLABEL
><B.BODY>Reverse engineering is not designed to capture all the information in a header file. Therefore, do not use reverse engineering to import classes <CX5FX5FEMPHASIS>in order to maintain them in ObjectTeam</CX5FX5FEMPHASIS
><CX5FX5FEMPHASIS></CX5FX5FEMPHASIS
>. If you generate header files from the CDs and CDMs created by reverse engineering, the generated header files are <CX5FX5FEMPHASIS>not</CX5FX5FEMPHASIS
><RBW-PARABODY>Nested type definitions are recognized, but processed as if they are not nested. This can result in duplicate definitions.</RBW-PARABODY
><RBW-PARABODY>References to nested type definitions are transformed into references to type definitions that are not nested. For example, <CX5FX5FINPUT>nested::type</CX5FX5FINPUT
><RBW-PARABODY>Definitions of templates are ignored; references to instances of the template are mapped to a reasonable name. For example, <CX5FX5FINPUT>List<Thing*></CX5FX5FINPUT
><RBW-PARABODY>It detects associations according to a heuristic process. The associations can be transformed either into graphical associations or into attributes and methods.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Preprocessing directives</SL.SUBLABEL
><B.BODY>The parser ignores all preprocessor symbols, such as #ifdef and #define. However, you can specify a preprocessor to be run before reverse engineering, as described in <RBW-XREF REFID="23867" TYPE="XREF-TEXTCOPY">Running Reverse Engineering</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Mapping the elements<RBW-IDXTERM TERM1="C++" TERM2="reverse engineering"></RBW-IDXTERM
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>ObjectTeam inheritance structure that has the <CX5FX5FOBJECT.NAME>inher_access</CX5FX5FOBJECT.NAME
> property set</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Name of an instance of a template</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Reasonable name; for example, CList<X> becomes Clist_X</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Name in which @ replaces ::</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
><B.BODY>Implicit C++ constructions referring to associations can also be mapped to ObjectTeam elements, however, it will not be possible to map every construction. </B.BODY
> file in the cplusplus module defines the reverse engineering rules used to detect associations and attribute accessors. You can modify reverse engineering by editing this customization file, as described in <RBW-XREF REFID="36160" TYPE="XREF-TEXTCOPY">Chapter 5, Customizing Code Generation</RBW-XREF
><BI.BODY.INTRO>After mapping the C++ constructs to ObjectTeam elements, reverse engineering creates the CDs and CDMs that define the ObjectTeam elements. It creates the following CDs:</BI.BODY.INTRO
><RBW-PARABODY>One or more CDs to show the associations among the classes</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Naming conventions for CDs</SL.SUBLABEL
><B.BODY>Each CD is named for the primary class in the CD; for example, Class1. The word Tree is appended to the name of each CD that defines part of the class hierarchy; for example, TestClass1Tree.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How many diagrams are created</L.LABEL
><B.BODY>The number and complexity of the CDs created by reverse engineering depend largely on the following:</B.BODY
><RBW-PARABODY>The files that you select for reverse engineering, particularly the number and complexity of classes defined in the files.</RBW-PARABODY
><RBW-PARABODY>The reverse engineering options that you select, particularly whether you choose to reverse engineer associations.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="11053"></RBW-ANCHOR
>Options for reverse engineering</L.LABEL
><BI.BODY.INTRO>During reverse engineering, ObjectTeam displays the following dialog box prompting you to select the options that you want to use:</BI.BODY.INTRO
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>If selected, reverse engineering creates a separate reference CD for each class that exceeds the maximum size. The class is folded in all diagrams other than the reference diagram.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Max Class Width & Height</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a class. When a class exceeds this size, it is folded.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Max Tree Width & Height</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a class tree. When a class hierarchy exceeds this size, it is split.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a diagram. When a diagram exceeds this size, it is split.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>If selected, reverse engineering examines the attributes and accessor methods defined on each class to determine the associations among classes. It then creates CDs that show those associations.</CELLBODY
><CELLBODY>If this option is not specified it will default to the settings of the M4_reveng_filter variable. If the M4_reveng_filter is not set, no input filter will be used.</CELLBODY
> Reverse engineering ignores all preprocessor directives, such as #ifdef and #define. Use this field to specify a preprocessor that can resolve these directives before ObjectTeam reverse engineers the file.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>File containing a list of identifiers to be ignored by reverse engineering. The file must be an ASCII file that contains the identifiers; separate the identifiers using white space.</CELLBODY
>If you want to retain the specification of this file for repeated use, set the M4_reveng_skipfile variable in your Meta4userenv file. For example:</CELLBODY
><CELLBODY>This value will be displayed in this field. Note that if you change the value in this field, it is not written to the Meta4UserEnv file.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>CDs that show the class hierarchy</L.LABEL
><B.BODY>Following are the guidelines used to draw the CDs that show the class hierarchy:</B.BODY
><RBW-PARABODY>Reverse engineering creates a CD for each top&truehy;level parent class. The CD contains the parent class and all subclasses.</RBW-PARABODY
><RBW-PARABODY>If a class has multiple parent classes, reverse engineering creates a CD for each parent. The CD for the first parent class contains the parent class, the child class, and all subclasses of the child class. The CD for each of the other parent classes contains only the parent class and the child class; in these diagrams, the child class is folded.</RBW-PARABODY
><B.BODY>If you select the Reverse Engineer Associations option in the Reverse Engineer dialog box, reverse engineering creates CDs that show the associations. How it creates these CDs depends on which Placement Algorithm option you selected in the Reverse Engineer dialog box. Both algorithms are described below.</B.BODY
><B.BODY>If you do not select the Reverse Engineer Associations option, reverse engineering shows associations only as attributes and accessor methods in the appropriate classes.</B.BODY
>Bidirectional associations are reverse engineered as two unidirectional associations.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Simple algorithm</L.LABEL
><B.BODY>If you select Simple in the Placement Algorithm field of the Reverse Engineer dialog box, reverse engineering draws the CDs as follows:</B.BODY
><RBW-PARABODY>Unfolds the main class in each CD and folds all associated classes.</RBW-PARABODY
></LN.LIST.NUM
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><BI.BODY.INTRO>The examples for the simple and grid algorithms are created by reverse engineering the same files. The following example shows the CDs created using the simple algorithm.</BI.BODY.INTRO
><RBW-PARABODY>Divides all classes into groups of <CX5FX5FEMPHASIS>n</CX5FX5FEMPHASIS
>, where <CX5FX5FEMPHASIS>n</CX5FX5FEMPHASIS
> is the number specified by the Number of Classes per CD field of the Reverse Engineer dialog box. The algorithm attempts to group associated classes.</RBW-PARABODY
><RBW-PARABODY>For each group of classes, creates a CD and adds the classes (unfolded) to the CD. To position the classes, reverse engineering uses a uniform grid whose squares are the size of the largest class in the group and its longest association.</RBW-PARABODY
><RBW-PARABODY>For each class in each CD, draws all associations from the class to all associated classes. If an associated class is not in the CD, reverse engineering adds it (folded) to the CD.</RBW-PARABODY
></LN.LIST.NUM
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The examples for the simple and grid algorithms are created by reverse engineering the same files. The following example shows the CD created using the grid algorithm. (The diagram layout has been modified to fit on the page.)</B.BODY
>Typically, you reverse engineer into an empty system. This prevents name conflicts with existing classes. Classes are reverse engineered with scope ‘Phase’ by default, and, therefore, sometimes an empty phase may be needed.</N2.NOTE.2
><RBW-PARABODY>Select the options, then select OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam reverse engineers the selected file, reporting the results in a Monitoring window.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="14652"></RBW-ANCHOR
>Files for reverse engineering</L.LABEL
><B.BODY>During reverse engineering, ObjectTeam prompts you to select the files that you want to reverse engineer. In most cases, you select C++ header files. </B.BODY
>Reverse engineering creates CDs and CDMs based on the files that you select. Therefore, you generally want to reverse engineer all files in a library at the same time.</T.TIP
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Windows</SL.SUBLABEL
><BI.BODY.INTRO>The following illustration shows the Windows dialog box. Use the File Name and Files of Type fields to filter the list of files displayed. </BI.BODY.INTRO
><BI.BODY.INTRO>The following illustration shows the UNIX dialog box. Use the Filter field and Filter button to filter the list of files displayed.</BI.BODY.INTRO
><B.BODY>Round&truehy;trip engineering updates the ObjectTeam model based on the changes you have made to the generated C++ header files. Use round&truehy;trip engineering to update the ObjectTeam model <CX5FX5FEMPHASIS>before</CX5FX5FEMPHASIS
>Round&truehy;trip engineering is not necessary, and does not work with, C++ source files. It is only needed for the C++ header files.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose</L.LABEL
><B.BODY>The code generator generates code based on the ObjectTeam model. If you do not update the ObjectTeam model before regenerating the header files, the new header files do not include your changes. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>You generate C++ header files. You then add a new method to a generated file. If you do not update the ObjectTeam model, the model does not contain the operation that corresponds to the method. When you regenerate the header file, the code generator assumes that you <CX5FX5FEMPHASIS>deleted</CX5FX5FEMPHASIS
> the operation from ObjectTeam and, therefore, does not include the <CX5FX5FEMPHASIS>obsolete</CX5FX5FEMPHASIS
> method in the newly generated file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes captured by round&truehy;trip engineering</L.LABEL
><B.BODY>If you have made the following types of changes to the generated header file, round&truehy;trip engineering updates the ObjectTeam model based on those changes:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>You select the generated (edited) header files that you are interested in and start round&truehy;trip engineering.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>ObjectTeam parses the selected files and compares the information in the files with the information in the ObjectTeam model.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>For each difference it finds, ObjectTeam proposes an action and prompts you for confirmation. For example:</CELLBODY
><CELLBODY><CX5FX5FINPUT>In class “Account”: delete attribute “Address”?</CX5FX5FINPUT
><B.BODY>This section describes which changes to the generated C++ header files are captured by round&truehy;trip engineering. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes to attributes</L.LABEL
><B.BODY>In a header file generated by ObjectTeam, the section that defines attributes (Private section only) is indicated by the following comment:</B.BODY
><B.BODY>Within this section, you can make the following types of changes and round&truehy;trip engineering can move them back into the CDMs of the Object Design phase:</B.BODY
>If you change a default value, be sure to change it in the comment as well as in the code; round&truehy;trip engineering reads the value from the comment.</N2.NOTE.2
>If you rename an attribute, round&truehy;trip engineering removes and adds the attribute; therefore, its properties are lost.</N.NOTE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Default constructor/destructor</SL.SUBLABEL
><B.BODY>If you add or delete an attribute, you can also change the signature of the default constructor for the class. This is the only change to the default constructor/destructor that round&truehy;trip engineering moves back to the CDMs.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attribute accessor methods</SL.SUBLABEL
><B.BODY>If you add or delete an attribute, you can also add or delete its accessor methods. This is the only change to the attribute accessor methods that round&truehy;trip engineering moves back to the CDMs. </B.BODY
>If you add an attribute without adding its accessor method, round&truehy;trip engineering sets the attribute access to read&truehy;only; that is, in the Attribute Access property of the attribute, both the Read and Write fields are set to None.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes to operations</L.LABEL
><B.BODY>In a header file generated by ObjectTeam, the sections that define operations (Public, Protected, and Private sections) are indicated by the following comment:</B.BODY
><B.BODY>Within these sections, you can make the following types of changes and round&truehy;trip engineering can move them back into the CDMs of the Object Design phase:</B.BODY
><RBW-PARABODY>Change method signatures by adding, removing, or reordering parameters, changing default values, or changing the return type. </RBW-PARABODY
>If you have multiple methods with the same name, do not delete one and change the signature of another at the same time. Delete one, run round&truehy;trip engineering, change the signature of the other, and run round&truehy;trip engineering. This approach prevents potential errors in round&truehy;trip engineering.</T.TIP
> in the <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
>/etc directory controls what actions round&truehy;trip engineering proposes, as well as the default answers it supplies. To examine or modify the current behavior of round&truehy;trip engineering, examine or modify the customization file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to run round&truehy;trip engineering</L.LABEL
><LR.LIST.RESULT>ObjectTeam opens the Roundtrip Selected Files dialog box, compares the classes in the generated files to the classes in the Object Design phase, and then begins proposing actions and prompting you for confirmation.</LR.LIST.RESULT
><RBW-TEXTFLD TYPE="text">Code Generation Guide for C++</RBW-TEXTFLD
></RBW-SYSOBJ
></C.CHAPTER.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This chapter contains an introduction to the code generation process in ObjectTeam and an overview of the areas that can be customized and configured.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="21823" TYPE="XREF-TEXTCOPY">How C++ Code is Generated&rbwtab;5–2</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="29462" TYPE="XREF-TEXTCOPY">How to Customize the Code Generation&rbwtab;5–13</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="32178" TYPE="XREF-TEXTCOPY">Customizing Class Libraries&rbwtab;5–25</RBW-XREF
><RBW-PARABODY>Write the generated code to the file system</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Classes used in the code generation process</L.LABEL
><B.BODY>Code generators in ObjectTeam consist of a set of Object Tcl classes, whose definitions are stored in Tcl files. Object Tcl is an object&truehy;oriented extension to standard Tcl developed by Cayenne.</B.BODY
><B.BODY>The following types of classes can be distinguished in the code generation process:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Language&truehy;independent and language&truehy;dependent Importer classes handle the import of (new or selected) classes from the Object Design Phase into the Implementation phase</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Language dependent FileHandler classes handle the mapping of class names to file names and vice versa.</CELLBODY
><CELLBODY>Importer classes use these classes to map file names to class names and class names with file types to file names.</CELLBODY
><CELLBODY>Regenerator classes use these classes to open a file using the class name and the file type.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Language dependent Regenerator classes read existing code and filters out parts that can be reused</CELLBODY
><B.BODY>These classes are not further discussed in this section. The focus is on the actual code generation, which is based on the OOPL model.</B.BODY
><B.BODY>The OOPL model is a target language independent data model based on the Cayenne repository. It can be accessed through a Tcl interface, consisting of a class hierarchy that is built&truehy;in in the Tcl interpreter ObjectTeam Shell (otsh).</B.BODY
><B.BODY>A complete description of all the classes in the OOPL model and how they relate to one another can be found in <CX5FX5FTITLE>ObjectTeam Repository Interface Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>. In this section, only the classes most important for C++ code generation are listed. The three main superclasses are:</B.BODY
><B.BODY>The OOPL model is built up during code generation and can be traversed using Object Tcl. The result of traversing the OOPL model is used by the code generator to generate target language specific code files.</B.BODY
><B.BODY>If you want to customize any aspect of the code generation, you must be familiar with the structure of the (language&truehy;independent) OOPL model and the way it is used to generate language&truehy;specific code. This process is explained in the remaining part of this section.</B.BODY
><B.BODY>Since the OOPL model is a data&truehy;only model, which lacks functionality to generate anything, an extra model based on the OOPL model is needed: the derived OOPL model. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Classes</L.LABEL
><B.BODY>Every class from the OOPL model that is meaningful for the generation of the particular programming language has a Tcl counterpart in the derived OOPL model.</B.BODY
><B.BODY>The names of these Tcl classes resemble their counterparts; instead of the prefix OP they have a prefix indicating the target language (e.g. CppG).</B.BODY
><B.BODY>The derived model contains a class hierarchy similar to that of the OOPL model; the Tcl class CppGLinkClass, for example, is derived from CppGClass, just like OPLinkClass is derived from OPClass.</B.BODY
><B.BODY>The classes in the derived OOPL model are Tcl classes. Their definition (including attributes and methods) are stored in the Tcl file <CX5FX5FFILE.NAME>cppgclasses.tcl</CX5FX5FFILE.NAME
>, which can be found in the <CX5FX5FFILE.NAME>tcl</CX5FX5FFILE.NAME
> directory of the <CX5FX5FFILE.NAME>cplusplus</CX5FX5FFILE.NAME
> module. </B.BODY
><B.BODY>The classes in the OOPL model, on the other hand, are compiled C++ classes, which have been made available to Tcl. The classes in the OOPL model are referred to as OP classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>OP and Tcl classes</L.LABEL
><B.BODY>A Tcl class can be derived from both an OP class and a Tcl class, but the inheritance tree is invalid if the Tcl base class, in turn, has also been derived from an OP class.</B.BODY
><B.BODY>The Tcl class CppGLinkClass, for example, must be derived from its OP counterpart OPLinkClass. At the same time it must be derived from the Tcl class CppGClass, just like OPLinkClass is derived from OPClass. CppGClass, however, also has an OP class in its hierarchy (OPClass, that is). This renders the hierarchy for CppGLinkClass invalid.</B.BODY
><B.BODY>The hierarchy in the following model is invalid.</B.BODY
><B.BODY>The restriction on the classes from which a Tcl class can be derived is circumvented in the derived OOPL model by pushing in a so&truehy;called mix&truehy;in class. </B.BODY
><B.BODY>This concept is best explained in a picture. In the following picture, the class CppGLinkClassD is the mix&truehy;in class.</B.BODY
><B.BODY>Using mix&truehy;in classes allows inheriting data from the OOPL tree and functionality from the derived OOPL model consecutively.</B.BODY
><B.BODY>The name of a mix&truehy;in class resembles the name of the Tcl class it is derived from; only a capital D is added at the end. However, this name is not important.</B.BODY
><B.BODY>Mix&truehy;in classes do not contain any attributes or methods of their own, they inherit all functionality from their base classes. The mix&truehy;in class CppGLinkClassD, for example, is defined as follows:</B.BODY
>In the derived OOPL model, a mix&truehy;in class is created for every Tcl class, even if it is not strictly necessary.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Self promotion</L.LABEL
><B.BODY>The self promoter is a special method that can be added to a derived class. It is called just after an object is created of the class from which the derived class is derived. Self promotion can thus be used to promote an object to an object of a derived class. Promote here, means extending a class’s functionality without having to redefine any methods.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Syntax:</SL.SUBLABEL
><B.BODY>The syntax of a self promotion is as follows:</B.BODY
><EM.EXAMPLE.MONO># find out the type of the object</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>$obj objType</EM.EXAMPLE.MONO
><B.BODY>This will return the following:</B.BODY
><EM.EXAMPLE.MONO>Chimp</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Self promotion and the derived OOPL model</L.LABEL
><B.BODY>The self promotion mechanism is used in the derived OOPL model to add a <CX5FX5FINPUT>generate</CX5FX5FINPUT
> method to the OOPL model. By providing a derived OOPL model for every target language the same OOPL model can be used to generate code for different target languages.</B.BODY
><B.BODY>Since mix&truehy;in classes have been created for every Tcl class in the derived OOPL model, every OP class that has a counterpart in the derived model will be promoted to the corresponding mixed&truehy;in class.</B.BODY
><B.BODY>Now if a new object of the class OpLinkClass is created, the type of this object will be CppGLinkClassD. The class CppGLinkClassD has a <CX5FX5FINPUT>generate</CX5FX5FINPUT
> method in its inheritance tree, unlike OPLinkClass.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Checking and code generation</L.LABEL
><B.BODY>The derived OOPL model is not only used for code generation, but also for (target language dependent) diagram checking. If it is used for checking, the mix&truehy;in classes must not be derived from OP classes, but from CM classes. CM classes are special classes used for checking.</B.BODY
><B.BODY>An <CX5FX5FINPUT>if</CX5FX5FINPUT
> statement is used in the Tcl code to handle this twofold functionality in the derived OOPL model. In the case of the mix&truehy;in class CppGLinkClassD, for example, the following piece of Object Tcl code can be found:</B.BODY
><RBW-PARABODY>convert this information into target language compliant ASCII text.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The target language model stores a method’s name and parameters and puts the keyword <CX5FX5FINPUT>method</CX5FX5FINPUT
>, the class’s name and two colons before writing out the method’s name.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Why a target language model is required</L.LABEL
><B.BODY>The classes in the derived OOPL model extend the classes in the OOPL method with generate methods. These generate methods build up the target language model. </B.BODY
><B.BODY>The classes in the target language model, in turn, contain generate methods themselves. After the target language model has been built up, these generate methods are called by the CppGenerator class, thus generating the code in text sections.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="36289"></RBW-ANCHOR
>Class hierarchy</L.LABEL
><B.BODY>The most important classes of the Target Language Model are:</B.BODY
><RBW-TABLE><TGROUP COLS="2"><COLSPEC COLNAME="1" COLWIDTH="225p"><COLSPEC COLNAME="2" COLWIDTH="225p"><THEAD><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLHEADING>Target Language Model Class</CELLHEADING
><B.BODY>If you want to customize the way C++ code is generated, you have to introduce one or more user&truehy;defined classes based on classes from the OOPL model.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="42227"></RBW-ANCHOR
>Class hierarchy</L.LABEL
><B.BODY>User&truehy;defined classes required for customization must, in fact, be derived from:</B.BODY
><B.BODY>However, user&truehy;defined Tcl classes can also be derived from existing user&truehy;defined Tcl classes. This situation is depicted in the following picture.</B.BODY
>How to Customize the Code Generation</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>The code generation in ObjectTeam is all Tcl based. Tcl code is interpreted rather than compiled, which makes the code generation process highly customizable. </B.BODY
><B.BODY>Moreover, the use of the object&truehy;oriented extension made to Tcl (Object Tcl) allows you to make changes to the code generation process and reuse default functionality where necessary.</B.BODY
><B.BODY>The use of ObjectTeam modules, in conclusion, facilitates managing customizations.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section discusses two ways of customizing the code generation process:</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="31773" TYPE="XREF-TEXTCOPY">Using Modules to Store Customizations&rbwtab;5–17</RBW-XREF
><B.BODY>Simple customizations are customizations that can be implemented quickly and easily in a single customization file, without having to create separate modules. Bear in mind, though, that simple customizations are much harder to maintain than customizations that are stored in separate modules.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How is code generation started</L.LABEL
><B.BODY>When a user of ObjectTeam activates the code generation by selecting Utilities | Generate C++ on system level in the Implementation phase, the Object Tcl interpreter <CX5FX5FFILE.NAME>otsh</CX5FX5FFILE.NAME
>The first line that is sent to the Monitoring Window shows the exact <CX5FX5FFILE.NAME>otsh</CX5FX5FFILE.NAME
> command.</T.TIP
><B.BODY>The file name behind the argument <CX5FX5FINPUT>&truehy;f </CX5FX5FINPUT
>specifies the Tcl file that is intepreted first: <CX5FX5FFILE.NAME>import.tcl</CX5FX5FFILE.NAME
> in this case. This file activates other (language&truehy;dependent and language&truehy;independent) Tcl files, which, in turn, activate other Tcl files, and so on.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing the code generation</L.LABEL
><B.BODY>The language&truehy;dependent Tcl files used during code generation are stored in the <CX5FX5FFILE.NAME>tcl</CX5FX5FFILE.NAME
> directory of the corresponding module (<CX5FX5FOBJECT.NAME>cplusplus</CX5FX5FOBJECT.NAME
> for example). These files are interpreted at some point by otsh. </B.BODY
><B.BODY>If you know which method of which class you want to change or add, you can include the new or changed method implementation in the following customization file:</B.BODY
>Most of the functionality regarding the lay&truehy;out of code can be found in the Tcl file that contains the target language model, <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
>The new method will only be called for newly generated classes or classes that have changed since the last time code was generated. Existing source files whose corresponding classes have not changed will not be regenerated.</W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The method CppMethod::genRegenCode adds, among other things, a standard comment line to the (empty) body of a user&truehy;defined method. For example:</B.BODY
><B.BODY>If you want to change the exclamation marks in the comment line into something else, hatch signs (#), for example, you must copy the default method implementation CppMethod::genRegenCode from <CX5FX5FFILE.NAME>cppgrammar.tcl</CX5FX5FFILE.NAME
> to a <CX5FX5FFILE.NAME>u_import.tcl </CX5FX5FFILE.NAME
>Using Modules to Store Customizations</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Advanced code generation customizations are best stored in separate user&truehy;defined ObjectTeam modules. The Object Tcl code needed to extend or redefine the default code generation is then stored in such a module, which can be turned on or off on demand.</B.BODY
><RBW-PARABODY>Create a new module directory.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>This directory can be created anywhere in the file system, as long as if it is accessible to ObjectTeam. The directory name is not important.</LT.LIST.TEXT
><LT.LIST.TEXT>With these customization files you can extend the customization files residing at a higher level in the repository. As they are read incrementally, you only have to include new entries in these files.</LT.LIST.TEXT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Activating a module</L.LABEL
><B.BODY>To activate a user&truehy;defined module, add it to the customization file <CX5FX5FFILE.NAME>modules.modules</CX5FX5FFILE.NAME
> on the appropriate customization level and turn it on. You can do this using the Module Customization Editor.</B.BODY
><B.BODY>Before testing the new module, move the Browser to Corporate level. The new module will be read if you move down to the appropriate level.</B.BODY
><B.BODY>In the following customization example, a new class property Singleton Class is introduced. Classes for which this property is turned on will be generated into singleton classes. </B.BODY
><B.BODY>A singleton class is a class that can only have one instance. A global point of access is provided to singleton classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Result</L.LABEL
><B.BODY>A singleton class differs from a regular class in that:</B.BODY
><B.BODY>These files exist on Corporate level and can be extended on every lower repository level. As these files are read incrementally, you only have to include new definition and location lines in the module files.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>propdefs.propdefs</SL.SUBLABEL
><B.BODY>Include the following line:</B.BODY
><EWM.EXAMPLEW.MONO># Prop Name | Long Name | GUI Class | attributes</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>singletonClass | Singleton Class | CheckButton | &truehy;state 0</EWM.EXAMPLEW.MONO
><B.BODY>This line defines the property <CX5FX5FEMPHASIS>singletonClass</CX5FX5FEMPHASIS
> as a check button which is turned off by default. The name of the property in the dialog box is <CX5FX5FEMPHASIS>Singleton Class</CX5FX5FEMPHASIS
><B.BODY>These lines specify the property <CX5FX5FOBJECT.NAME>singletonClass</CX5FX5FOBJECT.NAME
> as item property for classes and container classes in CDs for the phases Analysis, System Design and Object Design.</B.BODY
><B.BODY>If the module containing these customization files is active, the Edit Properties dialog box for classes will have an extra property Singleton Class.</B.BODY
><B.BODY>The name of the user&truehy;defined class in this example is Singleton Cust. This class is derived from the OOPL model class OPClass and contains only one method: generate. </B.BODY
><B.BODY>The class OPClass is promoted to the user&truehy;defined SingletonCust using self promotion.</B.BODY
><B.BODY>If this module is active, a singleton class construction will be generated for all the classes that have the property Singleton Class turned on.</B.BODY
><B.BODY>Class libraries are used in ObjectTeam to implement associations between classes. As the integration of any class library with ObjectTeam is entirely written in Object Tcl, virtually any class library can be integrated.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What does a class library integration do</L.LABEL
><B.BODY>The integration of a class library with ObjectTeam determines and generates the following:</B.BODY
><RBW-PARABODY>the multiplicity at the other end (one, many)</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="35581"></RBW-ANCHOR
>How is an integration implemented</L.LABEL
><B.BODY>The functionality to generate associations in C++ is implemented by Tcl classes and their methods. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class library integration module</L.LABEL
><B.BODY>Class library integrations, the ones supplied by Cayenne, as well as user&truehy;defined ones, are stored in ObjectTeam modules. A user can activate a class library integration by activating the corresponding module.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Overview of Tasks</L.LABEL
><B.BODY>The following tasks must be carried out when a user&truehy;defined class library is created:</B.BODY
><B.BODY>Every module directory in ObjectTeam contains a properties file. It contains information to identify the module, such as its (long) name, its type, and so on.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Cayenne class library</L.LABEL
><B.BODY>In the Cayenne class library module (cpp&truehy;libcayn), this file looks as follows:</B.BODY
><B.BODY>The user&truehy;defined Tcl classes you define to implement the integration must all be (indirectly) derived from one of the following class library independent Tcl base classes:</B.BODY
> for an overview of these classes and a description of their methods. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>User&truehy;defined classes</L.LABEL
><B.BODY>At least four user&truehy;defined classes must be created, one for every combination of association type &truehy; multiplicity. The methods of the base classes must be redefined, where necessary, in the user&truehy;defined classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Module file</L.LABEL
><B.BODY>User&truehy;defined Tcl classes and their methods must be defined and implemented in the following module file:</B.BODY
>Mapping User&truehy;defined Classes to Association Implementations</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>After you have defined and implemented the user&truehy;defined Tcl classes and their methods, you have to specify which Tcl class must be used to implement which type of association. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Module file</L.LABEL
><B.BODY>The mapping of association types to user&truehy;defined Tcl classes is stored in the following module file:</B.BODY
><B.BODY>Bear in mind that the association implementation type does not always coincide with the generated association attribute type; the exact type is determined by the method getTypeAttr of the user&truehy;defined Tcl class mentioned in the third column.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Second column</L.LABEL
><B.BODY>This column indicates the implementation strategy. For every association implementation type, at least a <CX5FX5FEMPHASIS>default</CX5FX5FEMPHASIS
> strategy must be defined. </B.BODY
><B.BODY>If you want to give the user of the integration the choice between different implementation strategies for a particular association implementation type, you have to add a new line with the same association implementation type in the first column, an implementation strategy indication other than <CX5FX5FEMPHASIS>default</CX5FX5FEMPHASIS
> in the second column, and the appropriate user&truehy;defined Tcl class in the third.</B.BODY
><B.BODY>The user can select an implementation strategy other than <CX5FX5FEMPHASIS>default</CX5FX5FEMPHASIS
> through the association property Implementation Strategy.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Third column</L.LABEL
><B.BODY>This column indicates the user&truehy;defined Tcl class that must be used to implement the corresponding association.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Cayenne class library</L.LABEL
><B.BODY>This is the <CX5FX5FFILE.NAME>cppclprop.tcl</CX5FX5FFILE.NAME
>Multiple implementation strategies have been specified (default, hash) here, but all use the same user&truehy;defined Tcl class as the default. </N.NOTE
><B.BODY>To append class library dependent information to one of these lines, include the appropriate Tcl code in the body of the procedure <CX5FX5FEMPHASIS>classLibrary</CX5FX5FEMPHASIS
><CX5FX5FVARIABLE>Name</CX5FX5FVARIABLE
>MakeFileTemplate. </B.BODY
><B.BODY>To add the word <CX5FX5FEMPHASIS>whatever</CX5FX5FEMPHASIS
>Automating Class Library Source Files Copying</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class Library Source Files</L.LABEL
><B.BODY>When a user of ObjectTeam selects Utilities | Configure C++ environment and the user’s active class library is the Cayenne class library, the source files and the header files of the Cayenne class library are copied over from the <CX5FX5FFILE.NAME>include</CX5FX5FFILE.NAME
> and <CX5FX5FFILE.NAME>src</CX5FX5FFILE.NAME
> directories in the cpp&truehy;libcayn module to the user environment.</B.BODY
><B.BODY>The user is then supposed to compile the source files into a class library whose classes are linked in when the application is compiled.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Module file</L.LABEL
><B.BODY>Tcl code to copy class library source and header files to the user environment can be stored in the following file:</B.BODY
><B.BODY>The user&truehy;defined Tcl classes you have to create to integrate a class library with ObjectTeam need to be derived from one of the following class library independent Tcl classes:</B.BODY
><LT.LIST.TEXT>Iterate over all the values in the association set and execute the loop expression on each value. The <CX5FX5FOBJECT.NAME>$loopVar</CX5FX5FOBJECT.NAME
> is replaced by the actual value. The code for the iterator should be added to the TextSection.</LT.LIST.TEXT
><E.EXAMPLE>genCtor( ): String</E.EXAMPLE
><LT.LIST.TEXT>Returns code to initialize the association in the default constructor.</LT.LIST.TEXT
><E.EXAMPLE>genDtor( ): String</E.EXAMPLE
><LT.LIST.TEXT>Returns code to free the association in the destructor.</LT.LIST.TEXT
><LT.LIST.TEXT>Iterate over all the values in the association dictionary and execute the loop expression on each value. The <CX5FX5FOBJECT.NAME>$loopVar</CX5FX5FOBJECT.NAME
> is replaced by the actual value. The code for the iterator should be added to the TextSection.</LT.LIST.TEXT
><E.EXAMPLE>genCtor( ): String</E.EXAMPLE
><LT.LIST.TEXT>Returns code to initialize the association in the default constructor.</LT.LIST.TEXT
><E.EXAMPLE>genDtor( ): String</E.EXAMPLE
><LT.LIST.TEXT>Returns code to free the association in the destructor.</LT.LIST.TEXT
><LT.LIST.TEXT>Iterate over all the values in the association dictionary and execute the loop expression on each value. The <CX5FX5FOBJECT.NAME>$loopVar</CX5FX5FOBJECT.NAME
> is replaced by the actual value. The code for the iterator should be added to the TextSection.</LT.LIST.TEXT
><E.EXAMPLE>genCtor( ): String</E.EXAMPLE
><LT.LIST.TEXT>Returns code to initialize the association in the default constructor.</LT.LIST.TEXT
><E.EXAMPLE>genDtor( ): String</E.EXAMPLE
><LT.LIST.TEXT>Returns code to free the association in the destructor.</LT.LIST.TEXT
><B.BODY>In the Object Design phase you can use standard types to define data types of data attributes and parameters. All the valid standard types are stored in the following file:</B.BODY
><B.BODY>This file also contains minimum and maximum values for the standard types.</B.BODY
><B.BODY>Whenever you generate code or check a diagram’s contents, the data types used in the diagram are checked against the data types in the standard types file.</B.BODY
><B.BODY>During code generation, the standard types are mapped to C++ types (see <RBW-XREF REFID="37444" TYPE="XREF-TEXTCOPY">C++ Types</RBW-XREF
>)</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What does the stand_types file look like?</L.LABEL
><B.BODY>Here is an example of a <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
> file. The columns <CX5FX5FPROCEDURE.NAME>Min 1</CX5FX5FPROCEDURE.NAME
> file is stored in the <CX5FX5FFILE.NAME>etc</CX5FX5FFILE.NAME
> directory of the <CX5FX5FEMPHASIS>cplusplus</CX5FX5FEMPHASIS
> module. You can add new standard types or override existing ones by creating your own <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
> file. </B.BODY
><B.BODY>All customization files of this type are read incrementally, which means that you only have to include the standard types that you want to add to the current set of standard types and the ones you want to override. </B.BODY
>What does the lang_types file look like?</L.LABEL
><B.BODY>Here is an example of a <CX5FX5FFILE.NAME>lang_types.lang_types</CX5FX5FFILE.NAME
> file for the Sun C++ compiler.</B.BODY
><B.BODY>The first column in this file lists the standard types. These must be consistent with the types in the <CX5FX5FFILE.NAME>lang_types.lang_types</CX5FX5FFILE.NAME
> file. The second column lists the C types the standard types must be mapped upon. In the column <CX5FX5FINPUT>range</CX5FX5FINPUT
> the type of brackets used in the target language is indicated.</B.BODY
><B.BODY>You can change the default extension into something else, like <CX5FX5FFILE.NAME>.c</CX5FX5FFILE.NAME
> or <CX5FX5FFILE.NAME>.C</CX5FX5FFILE.NAME
> using the customization file <CX5FX5FFILE.NAME>objtype.objtype</CX5FX5FFILE.NAME
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customization file in repository or module</L.LABEL
><B.BODY>To change the default extension, you have to create an ObjectTeam customization file in which the default settings are redefined. You can create this customization file on different repository levels, or you can create an ObjectTeam module and store it in the <CX5FX5FFILE.NAME>etc</CX5FX5FFILE.NAME
> directory of that module. </B.BODY
><B.BODY>The advantage of storing the file in the repository is that you can use a user&truehy;friendly Customization Editor to edit the file, whereas storing the file in a module offers you better control over whether and where the customized file must be used.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing the <CX5FX5FFILE.NAME>objtype.objtype</CX5FX5FFILE.NAME
> file is stored in the <CX5FX5FFILE.NAME>etc</CX5FX5FFILE.NAME
> directory of the module that handles the integration of your C++ compiler with ObjectTeam (cpp&truehy;cc&truehy;sun, cpp&truehy;bc&truehy;45, and so on).</B.BODY
><B.BODY>You can redefine default file extensions by creating your own <CX5FX5FFILE.NAME>objtype.objtype</CX5FX5FFILE.NAME
> file. </B.BODY
><B.BODY>All customization files of this type are read incrementally, which means that you only have to include the standard types that you want to add to the current set of standard types and the ones you want to override. </B.BODY
>for details on user&truehy;defined modules.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to change the default extension</L.LABEL
><B.BODY>In the steps mentioned below it is assumed that the customization file used to change the default extension is stored in the repository.</B.BODY
><RBW-PARABODY>Create a customization file <CX5FX5FFILE.NAME>objtype.objtype</CX5FX5FFILE.NAME
> </RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>You do this by opening the pseudo object <customization files> on an appropriate Browser level, select File | New and select <CX5FX5FFILE.NAME>objtype.objtype</CX5FX5FFILE.NAME
><RBW-PARABODY>To change the extension for C++ files, for example, select the row containing the Repository Type <CX5FX5FOBJECT.NAME>External File Version</CX5FX5FOBJECT.NAME
> and the Browser Type <CX5FX5FOBJECT.NAME>c++</CX5FX5FOBJECT.NAME
><RBW-PARABODY>To make sure the new customization file is read by ObjectTeam, go to Corporate Level in the Browser and go back to Implementation System level.</RBW-PARABODY
><RBW-PARABODY>The text editor that is now started up should show the file name with the new extension.</RBW-PARABODY
></LN.LIST.NUM
><B.BODY>Newly generated files will have the new extension in your user environment. However, the column Type in the information area of the Browser on Implementation System level still reads c++.</B.BODY
>Delete files that were generated before you created the customization file. When you generate them again, they will have the new file extension.</T.TIP
>Customizing the Location of Generated Files</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Default file extensions</L.LABEL
><B.BODY>Generated source files and header files are stored in the user environment. By default, both file types are stored in the same directory. </B.BODY
><B.BODY>You can customize the code generator in such a way that header files are stored in one directory, and source file in another. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to customize the location of generated files</L.LABEL
><B.BODY>The following global Tcl variables are used in the template files to generate file names, project names, configuration names, and so on:</B.BODY
><RBW-PARABODY>To make sure the new customization file is read by ObjectTeam, go to Corporate Level in the Browser and go back to Implementation System level.</RBW-PARABODY
><RBW-PARABODY>To test if your customization takes effect, generate code for a class for which no code was generated yet and edit the header file, source file or makefile.</RBW-PARABODY
>Only newly generated files will have the new header. Files that were generated before you created the customization file will not change, unless you regenerate them.</N.NOTE
><RBW-TEXTFLD TYPE="text">Code Generation Guide for C++</RBW-TEXTFLD
></RBW-SYSOBJ
></A.APPENDIX.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>C++ code generation properties</L.LABEL
><B.BODY>The following table lists all the properties that effect C++ code generation. They are available in the CD in the Object Design phase.</B.BODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="25709" TYPE="XREF-TEXTCOPY">Specifying Free Text for an Association Attribute</RBW-XREF
><RBW-TEXTFLD TYPE="text">Code Generation Guide for C++</RBW-TEXTFLD
></RBW-SYSOBJ
><RBW-ANCHOR ID="11059"></RBW-ANCHOR
>Example Application</A.APPENDIX.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This section contains an example of a Class Diagram and user&truehy;defined code with which a simple C++ application can be created. The application administrates songs on an audio medium (a compact disc, for example).</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What does the example application do?</L.LABEL
><B.BODY>The example application does the following:</B.BODY
><RBW-PARABODY>It prints the title and the total play time of the audio medium. The total play time is calculated by the application.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>The example <CX5FX5FINPUT>main</CX5FX5FINPUT
> file in this section calls the appropriate functions from the code that was generated by ObjectTeam and later completed with user&truehy;defined code.</B.BODY
><B.BODY>In the Object Design Phase, the model of the application is further refined. The Class Diagram is completed and (C++ dependent) properties are set, where desired.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class Diagram</L.LABEL
><B.BODY>The following Class Diagram is the model for the example application:</B.BODY
><B.BODY>For most of the classes, attributes, methods, parameters and associations in the model, the default property values are used. The following property values in the class Time, however, are explicitly set to a non&truehy;default value:</B.BODY
><B.BODY>In the Implementation Phase, C++ code is generated from the model as defined in the Object Design phase. This code needs to be completed with implementations of user&truehy;defined methods before it can be compiled. This section provides example code for these method bodies.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Implemented Functions</L.LABEL
><B.BODY>The table below lists all the methods of all the classes in the example application. Some methods are implemented automatically by the code generator, others are implemented through user&truehy;defined code. Some methods are not implemented at all.</B.BODY
>The user&truehy;defined code that was added later to the generated files is printed in bold.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Time.hxx</L.LABEL
><B.BODY>Unlike other functions, the implementations of inline functions are stored in the header file. The methods <CX5FX5FINPUT>operator&truehy;</CX5FX5FINPUT
><B.BODY>The following main file is an illustration of how the generated (and completed) code from the example can be used in a simple C++ application.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Sets a value (an object of the external class String) for the attribute <CX5FX5FINPUT>title</CX5FX5FINPUT
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Prints the object’s title and its total playing time (see <RBW-XREF REFID="33295" TYPE="XREF-TEXTCOPY">The Class AudioMedia</RBW-XREF
>)</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Functions called on the Song objects</L.LABEL
><B.BODY>The following functions are called on the objects <CX5FX5FINPUT>song1</CX5FX5FINPUT
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Sets a value (an object of the external class String) for the attribute <CX5FX5FINPUT>title</CX5FX5FINPUT
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Sets a value (an object of the class Time) for the attribute <CX5FX5FINPUT>playTime</CX5FX5FINPUT
>.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
><RBW-ICONIZE></RBW-TABLE
><B.BODY></B.BODY
></LABEL
></SUBSECTION
><SUBSECTION><SS.SUBSEC.HEAD>How to Compile And Run the Example Application</SS.SUBSEC.HEAD
><RBW-TEXTFLD TYPE="text">Code Generation Guide for C++</RBW-TEXTFLD
></RBW-SYSOBJ
></A.APPENDIX.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>The current release of the C++ code generator is completely new. Due to customer requests, the new code generator now supports the use of multiple class libraries.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Incompatibilities</L.LABEL
><B.BODY>The new release of the code generator does not support persistent code generation. In addition, customization files designed to work with the previous release of the C++ code generator cannot be used with the new release.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Modules for backward&truehy;compatibility</L.LABEL
><B.BODY>If you rely on ObjectTeam’s persistent code generation or have a large investment in your C++ customization files, you might prefer to continue using Release 6.1.1 of the C++ code generator. To do so, activate an ObjectTeam module of type <CX5FX5FEMPHASIS>PersistentCpp</CX5FX5FEMPHASIS
>. </B.BODY
><B.BODY>Modules of type <CX5FX5FEMPHASIS>PersistentCpp</CX5FX5FEMPHASIS
> require other modules, which require other modules in turn. If possible, these required modules will be activated automatically after you select a module of type <CX5FX5FEMPHASIS>PersistentCpp</CX5FX5FEMPHASIS
>. If there is more than one module of a required type available, you select the module of your choice from a dialog box.</B.BODY
><B.BODY>These are the modules required to run persistent C++ code generation:</B.BODY
><RBW-PARABODY><RBW-XREF REFID="13285" TYPE="XREF-TEXTCOPY">Customizing Persistent C++ Code Generation</RBW-XREF
></RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>License files</L.LABEL
><B.BODY>The license for the current release of the C++ code generation is valid regardless of which set of C++ code generator modules you choose to activate.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Features exclusive to 6.1.1 users </L.LABEL
><B.BODY>The following features are available in release 6.1.1. of ObjectTeam, but not in release 7.1.1:</B.BODY
><B.BODY>The class property Dynamic Destructor can be used to specify in which situation a virtual destructor must be generated.</B.BODY
><B.BODY>See <RBW-XREF REFID="39716" TYPE="XREF-TEXTCOPY">Specifying a Virtual Destructor</RBW-XREF
> for details.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Association Implementation</SL.SUBLABEL
><B.BODY>The association property Class Library can be used to select an (active) class library for a particular role name in an association. Within a selected class library, you can select an implementation strategy through the association property Implementation Strategy.</B.BODY
><B.BODY>See See <RBW-XREF REFID="31321" TYPE="XREF-TEXTCOPY">Specifying a Class Library</RBW-XREF
> and <RBW-XREF REFID="19988" TYPE="XREF-TEXTCOPY">Specifying an Implementation Strategy</RBW-XREF
> for details.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Strict association handling</SL.SUBLABEL
><B.BODY>Associations are handled more strictly in that consistency of associations is kept.</B.BODY
><B.BODY>The code generator in release 7.1.1 has been rewritten completely. Code generation is now a completely object&truehy;oriented process. As a result, customizations written for release 6.1.1 cannot be reused in release 7.1.1.</B.BODY
><SECTION><S.SECTION.HEAD>Non&truehy;Persistent Code Generation in Release 6.1.1</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Non&truehy;persistent code generation in release 6.1.1of ObjectTeam is almost identical to non&truehy;persistent code generation in release 7.1.1. </B.BODY
><B.BODY>The property Tcl Method Implementation Procedure, however, is exclusive to users of release 6.1.1 (and lower).</B.BODY
><LT.LIST.TEXT>This procedure generates the source code for a particular method with a very general purpose such as a printOn function. </LT.LIST.TEXT
><LT.LIST.TEXT>Such a printOn function prints all the data members of a class to standard output. You can use this kind of function for any class. The contents of the function is the same for every class; only the class differs.</LT.LIST.TEXT
><LT.LIST.TEXT>Use the following syntax when creating the Tcl procedure:</LT.LIST.TEXT
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>This name has to be specified as value for the property Tcl Method Implementation Procedure</CELLBODY
><RBW-PARABODY>Specify the value of the property Tcl Method Implementation Procedure as the name that you specified for the Tcl procedure (without <CX5FX5FINPUT>operation::</CX5FX5FINPUT
>).</RBW-PARABODY
></LN.LIST.NUM
><B.BODY>Now the body of the method is automatically generated every time you generate code for the class. The ObjectTeam Shell calls this procedure and inserts the code generated by the procedure as the body of the method.</B.BODY
>A persistent class is a class whose instances persists beyond the lifetime of a single program execution. The public interface of the persistent class is similar to that of the non&truehy;persistent classes. The implementation, however, is completely different because of the storage of the data members in a relational database. </B.BODY
><B.BODY>Persistent code refers to SQL (Structured Query Language) and ESQLC++ (Embedded Structure Query Language C++). </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="23699" TYPE="XREF-TEXTCOPY">Specific Features of CA&truehy;OpenIngres (E)SQL&rbwtab;D–49</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="41103" TYPE="XREF-TEXTCOPY">Specific Features of Microsoft SQL&truehy;Server (Dynamic) SQL&rbwtab;D–54</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="42686" TYPE="XREF-TEXTCOPY">Specific Features of Oracle (E)SQL&rbwtab;D–63</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="17338" TYPE="XREF-TEXTCOPY">Specific Features of Sybase (E)SQL&rbwtab;D–71</RBW-XREF
> to select the systems from the Object Design phase for which you want to generate code. You can select only systems for which no code has yet been generated.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>ObjectTeam opens a Monitor window for displaying log messages, then imports the systems. For each system, ObjectTeam imports both the OOPL and SQL Models. (The SQL model is described later in this section.)</LR.LIST.RESULT
> to generate code for all CADs for which you have not yet generated code. The Import New dialog box appears.</RBW-PARABODY
></LB2.LIST.BULLET.2
></LABEL
></SECTION
><SECTION><S.SECTION.HEAD>How to Define a Target Database</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>If your CADs contain persistent classes, the persistent classes must be defined as database tables in a Relational Database Management System (RDBMS). That database must then be selected when you run the application code.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Oracle</SL.SUBLABEL
><B.BODY>The term for a database in Oracle is a <CX5FX5FTITLE>schema</CX5FX5FTITLE
>. What is called a database <CX5FX5FTITLE>Server</CX5FX5FTITLE
> in other RDBMSs, is called an <CX5FX5FTITLE>Oracle SID</CX5FX5FTITLE
> in Oracle.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Defining a target database</L.LABEL
><B.BODY>The steps for defining a target database depend on whether you already have the database defined:</B.BODY
><RBW-PARABODY>If you do not have a database defined, you must create the database, select it, then execute the generated SQL scripts to create the database tables. (The SQL scripts are generated when you import the SQL Model into the Implementation phase.)</RBW-PARABODY
><RBW-PARABODY>If you have a database, but it does not contain the required database tables, you must select the database and execute the generated SQL scripts to create the database tables.</RBW-PARABODY
><RBW-PARABODY>If you already have a database that contains the required database tables, just select the database.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated SQL scripts</L.LABEL
><B.BODY>When you import the SQL Model into the Implementation phase, a number of SQL scripts are generated. The SQL script to build the target database is <CX5FX5FPROCEDURE.NAME>create</CX5FX5FPROCEDURE.NAME
>. This script activates other SQL scripts containing statements to create tables, procedures and rules.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Database tables that are created</L.LABEL
><B.BODY>When you execute the SQL script <CX5FX5FPROCEDURE.NAME>create</CX5FX5FPROCEDURE.NAME
>, database tables are created for the following persistent objects:</B.BODY
><B.BODY>If the package specified is ObjectTeam&truehy;OMT/Gen, the Database menu does not appear. For more information, see the <CX5FX5FTITLE>ObjectTeam System Administrator’s Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to define a database<RBW-IDXTERM TERM1="database" TERM2="building"></RBW-IDXTERM
>If the Database | Create Database item is not available for your RDBMS, you must use the RDBMS to create the database.</N2.NOTE.2
><LR.LIST.RESULT>The ObjectTeam shell interprets the Tcl script <CX5FX5FFILE.NAME>tdbop.tcl</CX5FX5FFILE.NAME
>, which creates the new database on the specified server if the RDBMS is configured properly. When you create a database, some initial actions are executed, such as the creation of empty system tables for the database and the registration of the database in the Relational Database Management System. </LR.LIST.RESULT
><LR.LIST.RESULT>The ObjectTeam Shell executes the SQL statements of the selected SQL script.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Setting a database (server) password</L.LABEL
><B.BODY>Microsoft SQL&truehy;Server and Sybase need a password to access the database server. Oracle needs a password to access the database itself. To avoid entering the required password every time you access the database server or database, select Database | Set <RBW-IDXTERM TERM1="password" TERM2="for accessing database"></RBW-IDXTERM
>Password. Following is the Set Password dialog box for Oracle:</B.BODY
><B.BODY>The mapping of C++ classes on a relational database is carried out through the runtime system. The Data Definition Language (DDL) to create the runtime system in ObjectTeam is SQL. The SQL code that is generated during persistent code generation is generated from the Class Association Diagrams residing in the same system of the previous phase.</B.BODY
><B.BODY>In Class Association Diagrams, standard data types are used to define the data type of attributes. These types are mapped to target&truehy;dependent database types during persistent code generation. The standard data types can be found in the customization file:</B.BODY
><E.EXAMPLE><CX5FX5FTERM>M4_home</CX5FX5FTERM
>/etc/t_<CX5FX5FTERM>RDBMS</CX5FX5FTERM
>/l_<CX5FX5FTERM>lang</CX5FX5FTERM
>/stand_types</E.EXAMPLE
><B.BODY>The following customization file is used to map the standard types to database types:</B.BODY
><E.EXAMPLE><CX5FX5FTERM>M4_home</CX5FX5FTERM
>/etc/t_<CX5FX5FTERM>RDBMS</CX5FX5FTERM
>/db_types</E.EXAMPLE
><B.BODY>See <RBW-XREF REFID="14052" TYPE="XREF-TEXTCOPY">Customizing Data Types on page 6–11</RBW-XREF
> for more information on these files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated files</L.LABEL
><B.BODY>Whatever RDBMS you are using, the following SQL script files are generated during SQL generation:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Contains SQL code for procedure creation. For every database table that is defined, the database operations <CX5FX5FTITLE>delete</CX5FX5FTITLE
>, <CX5FX5FTITLE>insert</CX5FX5FTITLE
> and <CX5FX5FTITLE>update</CX5FX5FTITLE
> are generated. These procedures also handle referential integrity</CELLBODY
><B.BODY>This section describes properties that affect persistent code generation. For instructions on how to specify properties, see <RBW-XREF REFID="16804" TYPE="XREF-TEXTCOPY">How to specify properties on page 3–5</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Which properties can you specify</L.LABEL
><B.BODY>The following class properties affect persistent code generation:</B.BODY
><B.BODY>This property must be switched on to indicate that a class is persistent. Besides, at least one data attribute must be identified as a key attribute. You can do that by inserting an asterisk (*) in front of the attribute’s name.</B.BODY
><B.BODY>If the name of a persistent class or data attribute is longer than the maximum length accepted by the RDBMS, you should specify an abbreviation.</B.BODY
>The generated SQL is different for every RDBMS supported by ObjectTeam, but the underlying principles are the same. The examples in this section use the SQL for Informix.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>SQL generation for persistent classes</L.LABEL
><B.BODY>In the simplest situation one persistent class maps to one table. Operations are irrelevant to SQL generation; they are generated as C++ code.</B.BODY
><B.BODY>Each persistent class is mapped to a table, and the table rows are instances of the class. The combination of class name (table name) and instance name (user&truehy;defined primary key) is a system&truehy;wide unique identification. Prefixing an attribute in the Class Association Diagram with an asterisk (*) makes the attribute part of the primary key. </B.BODY
><B.BODY>The following <CX5FX5FINPUT>CREATE TABLE</CX5FX5FINPUT
> statements are generated for one persistent class:</B.BODY
><B.BODY>In relationships that meet the following multiplicity requirements, it does not matter which table acts as master and which as detail:</B.BODY
><RBW-PARABODY>The association has a multiplicity that is <CX5FX5FEMPHASIS>not many</CX5FX5FEMPHASIS
> at the other side.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>However, since there has to be a master and a detail, the rule is that the destination class becomes master. The destination class is the class <CX5FX5FTITLE>to</CX5FX5FTITLE
> which the association was drawn in the Class Association Diagram. The class <CX5FX5FTITLE>from</CX5FX5FTITLE
> which the association was drawn becomes the detail. </B.BODY
><B.BODY>The association in the diagram below meets the requirements. The master&truehy;detail pair is as follows:</B.BODY
>Associations with class or link attribute </L.LABEL
><B.BODY>In associations that have a class or a link attribute associated with them, the associative object acts as detail in the master&truehy;detail&truehy;pairs. In the diagrams depicted below, the master&truehy;detail pairs are as follows:</B.BODY
><EM.EXAMPLE.MONO>CREATE TABLE C (</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generalizations<RBW-IDXTERM TERM1="generalization" TERM2="example of generated C++ code"></RBW-IDXTERM
></L.LABEL
><B.BODY>In a generalization, the superclass acts as master and the subclass as detail. In the following diagram, the master&truehy;detail pairs are as follows:</B.BODY
>, which is generated for every base class, is essential in generalizations. </B.BODY
><B.BODY>The following tables show what could be the contents of database table A, B and C. The value of <CX5FX5FOBJECT.NAME>a_date</CX5FX5FOBJECT.NAME
> is the same for both Z’s that occur in the table A. Without the <CX5FX5FOBJECT.NAME>class_type</CX5FX5FOBJECT.NAME
> attribute, it would be impossible to distinguish the two Z’s, even though they are two different occurrences with the same name.</B.BODY
><B.BODY>The mapping of C++ classes to a Relational Database is carried out through a runtime system. This runtime system enables the classes to do the following: </B.BODY
><RBW-PARABODY>Carry out operations on the database such as <CX5FX5FTITLE>insert</CX5FX5FTITLE
>, <CX5FX5FTITLE>update</CX5FX5FTITLE
> and <CX5FX5FTITLE>delete</CX5FX5FTITLE
> </RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>The Data Manipulation Language (DML) for the runtime system is ESQLC++. The generated ESQLC++ is different for every RDBMS supported by ObjectTeam, but the underlying principles are the same.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section contains the following topics:</B.BODY
><B.BODY>For every runtime system a file system_name<CX5FX5FFILE.NAME>Struct.hxx</CX5FX5FFILE.NAME
> is generated. This file contains typedef structs of the table representations. This typedef structs file contains the following type def structs used in embedded SQL:</B.BODY
><B.BODY>The structure of the Tcl code for the persistent class generation is the same as for non&truehy;persistent class generation. Objects for which persistence is important are represented in the OOPL model with the prefix <CX5FX5FINPUT>db_</CX5FX5FINPUT
>. For instance, there is a Tcl procedure <CX5FX5FPROCEDURE.NAME>assoc_attrib::generate</CX5FX5FPROCEDURE.NAME
> available for non&truehy;persistent code generation. The name of the persistent counterpart is <CX5FX5FPROCEDURE.NAME>db_assoc_attrib::generate</CX5FX5FPROCEDURE.NAME
>.</B.BODY
><B.BODY>Great care is taken to keep embedded C++ code out of the header files. If the header file contained embedded code, using just one persistent class would cause all normal C++ files referring to the header to be compiled by the embedded SQL&truehy;C preprocessor.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Communicating with the database</L.LABEL
><B.BODY>Persistent classes automatically get a set of member functions and data attributes for communication with the database. No specification in a Class Association Diagram is needed. These data attributes, a struct for keeping table values in&truehy;core, and the accompanying null indicator struct are:</B.BODY
><E.EXAMPLE><CX5FX5FTERM>class_name </CX5FX5FTERM
>Row data;</E.EXAMPLE
><E.EXAMPLE><CX5FX5FTERM>class_name </CX5FX5FTERM
>Ind nullInd;</E.EXAMPLE
><B.BODY>Four member functions take care of the data transport between data struct and database. These functions are generated for every persistent class:</B.BODY
><EM.EXAMPLE.MONO>virtual int insertInDB(); // INSERT</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>virtual int readFromDB(); // SELECT</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>virtual int deleteFromDB(); // DELETE</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>virtual int updateInDB(); // UPDATE</EM.EXAMPLE.MONO
><B.BODY>These embedded SQL queries have the following structure:</B.BODY
>referential integrity. The stored procedures are generated by <CX5FX5FINPUT>gensql</CX5FX5FINPUT
>.</B.BODY
><B.BODY>Subclasses of persistent classes redefine the <CX5FX5FINPUT>insertInDB()</CX5FX5FINPUT
>, <CX5FX5FINPUT>readFromDB()</CX5FX5FINPUT
>, <CX5FX5FINPUT>deleteFromDB()</CX5FX5FINPUT
> and <CX5FX5FINPUT>updateInDB()</CX5FX5FINPUT
> member functions; these so&truehy;called <CX5FX5FTITLE>cascade</CX5FX5FTITLE
> functions handle the extra data from their level and then call the base class member of the function.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Creating new instances of a class</L.LABEL
><B.BODY>Every persistent class has a static <CX5FX5FINPUT>instantiate()</CX5FX5FINPUT
> member for making a new instance of the class and reading the data from the database. The function takes the key without class name as argument:</B.BODY
><EM.EXAMPLE.MONO> DbPerson *tmp = new DbPerson(name);</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> if (tmp&truehy;>readFromDB() < 0) {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> delete tmp;</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> return 0;</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> }</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> return tmp;</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>}</EM.EXAMPLE.MONO
><B.BODY>The caller of this function is responsible for cleaning up the used memory.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Creating new instances of subclasses</L.LABEL
><B.BODY>The member functions discussed so far are not adequate for creating an instance of the correct subclass. You need a function for creating an instance of a class with keys. For this, the base persistent class gets the following member function and data member:</B.BODY
><B.BODY>These members are added <CX5FX5FINPUT>static</CX5FX5FINPUT
> to the persistent base class, and are therefore the same for all instances of the persistent class and its subclasses. <CX5FX5FINPUT>DbPersonFindPF_NmFuncMap</CX5FX5FINPUT
> is a mapping of class name to a class instantiation function, which is initialized at startup for all classes in the application. This map contains the base class and all existing subclasses. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>findInDB()</L.LABEL
><B.BODY>This is <CX5FX5FINPUT>findInDB()</CX5FX5FINPUT
>:</B.BODY
><EM.EXAMPLE.MONO> </EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>findInDB(name, class_type); // class key,type&truehy;id</EM.EXAMPLE.MONO
><RBW-PARABODY>Embedded SQL header in the source file (see <RBW-XREF REFID="19651" TYPE="XREF-TEXTCOPY">Embedded SQL header in the source file (Informix)</RBW-XREF
><RBW-PARABODY>Two data members in the class struct; an in&truehy;core copy of table values and the accompanying null indicator struct (see <RBW-XREF REFID="12438" TYPE="XREF-TEXTCOPY">Data members in the class struct</RBW-XREF
><RBW-PARABODY>A constructor declaration and implementation (see <RBW-XREF REFID="15480" TYPE="XREF-TEXTCOPY">Constructor declaration and implementation</RBW-XREF
><RBW-PARABODY>The declaration and implementation of the following (see <RBW-XREF REFID="17450" TYPE="XREF-TEXTCOPY">Declaration and implementation of SQL operations</RBW-XREF
>):</RBW-PARABODY
></LB.LIST.BULLET
><E.EXAMPLE>insertInDB()</E.EXAMPLE
><E.EXAMPLE>readFromDB()</E.EXAMPLE
><E.EXAMPLE>deleteFromDB()</E.EXAMPLE
><E.EXAMPLE>updateInDB()</E.EXAMPLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="19651"></RBW-ANCHOR
>Embedded SQL header in the source file (Informix)</L.LABEL
><B.BODY>Instead of the normally used <CX5FX5FINPUT>$</CX5FX5FINPUT
> notation, the <CX5FX5FINPUT>EXEC SQL</CX5FX5FINPUT
> notation is used because system_name<CX5FX5FFILE.NAME>Struct.hxx</CX5FX5FFILE.NAME
> is not embedded itself. The path for <CX5FX5FFILE.NAME>../</CX5FX5FFILE.NAME
> is needed because Informix <CX5FX5FINPUT>esqlc</CX5FX5FINPUT
> does not accept include directories. Informix <CX5FX5FINPUT>esqlc</CX5FX5FINPUT
> also accepts no <CX5FX5FINPUT>#define</CX5FX5FINPUT
> statements, therefore the file protector for the system_name<CX5FX5FFILE.NAME>Struct.hxx</CX5FX5FFILE.NAME
> is placed outside the embedded section, and outside the file. The user has to provide functions like SqlPrint. This is included in the ObjectTeam class library.</B.BODY
><EM.EXAMPLE.MONO>EXEC SQL BEGIN DECLARE SECTION;</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>EXEC SQL include “../<CX5FX5FTERM>sys_name</CX5FX5FTERM
>/<CX5FX5FTERM>sys_name</CX5FX5FTERM
>Struct.hxx”;</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>EXEC SQL END DECLARE SECTION;</EM.EXAMPLE.MONO
>Constructor declaration and implementation<RBW-IDXTERM TERM1="constructor" TERM2="declaration and implementation"></RBW-IDXTERM
></L.LABEL
><B.BODY>The keys of the table are the parameters of the constructor. For a derived class the keys are imported from its base class. The initialization of base classes is done by calling <CX5FX5FPROCEDURE.NAME>db_class::init_bases</CX5FX5FPROCEDURE.NAME
>. The fields of the null indicator struct in the body are set to one of the following:</B.BODY
><B.BODY>In the Tcl function <CX5FX5FPROCEDURE.NAME>db_data_attrib::generate</CX5FX5FPROCEDURE.NAME
>, the following member functions can be generated:</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The following overview shows various data attributes you can specify in classes and the most significant part of the resulting ESQLC++ code:</B.BODY
><B.BODY><CX5FX5FPROCEDURE.NAME>Standard type class</CX5FX5FPROCEDURE.NAME
><B.BODY>Analogous to the non&truehy;persistent association generation a generic dispatch function exists. This function is <CX5FX5FINPUT>gen_for_db_assoc</CX5FX5FINPUT
>. It has the following association parts:</B.BODY
><B.BODY>The get, set/add and remove functions that are generated have the same names as their non&truehy;persistent counterparts. The parameter interface is slightly different. The functions always have an integer return value for the SQL error status. The other return values are parameters. The exception is the one&truehy;get function, which returns the pointer to the object. </B.BODY
><B.BODY>The following overview shows two associations you can model in Class Association Diagrams: the multiplicity of the first association is one&truehy;optional, for the second one it is one&truehy;mandatory.</B.BODY
><LT.LIST.TEXT>Two pointers to data structures are declared, one to the class’s own structure and one to the related structure (master and detail). The imported keys implementing the relation get a value through an embedded SQL update. Depending on the export target, the own or the related table is updated. </LT.LIST.TEXT
><LT.LIST.TEXT>This function is not generated if the other side of the relation is qualified, because the key needed to implement the function is not available.</LT.LIST.TEXT
><LT.LIST.TEXT>A pointer to the own data structure is declared and the imported key is set to NULL with an embedded SQL update. In the case of a mandatory relation, nothing is generated.</LT.LIST.TEXT
><RBW-PARABODY>The relation is qualified, and the keys are exported to a separate table</RBW-PARABODY
></LB2.LIST.BULLET.2
><LT.LIST.TEXT>In the first situation, the existence of a relation is checked by looking at the imported key field of the null indicator struct: <CX5FX5FPROCEDURE.NAME>&truehy;1</CX5FX5FPROCEDURE.NAME
> means no relation. If the relation exists, the result of a <CX5FX5FTERM>related_class</CX5FX5FTERM
><CX5FX5FINPUT>::findInDB()</CX5FX5FINPUT
> is returned. The parameters of this <CX5FX5FINPUT>findInDB()</CX5FX5FINPUT
> are the imported key fields of the data struct. </LT.LIST.TEXT
><LT.LIST.TEXT>In the second situation, the imported key fields in the data struct are not available because they reside with the related class. The fields are made available by executing embedded SQL on the table of the related class and storing them in a temporary local struct. From there, the fields are accessed by the <CX5FX5FINPUT>findInDB()</CX5FX5FINPUT
>.</LT.LIST.TEXT
><LT.LIST.TEXT>In the third situation, a qualified relation with a separate table is implemented. Then, an embedded SQL select and a <CX5FX5FINPUT>findInDB()</CX5FX5FINPUT
> are generated, as in the second situation.</LT.LIST.TEXT
><B.BODY>The following table shows two associations you can model in Class Association Diagrams. The multiplicity of the first association is <CX5FX5FTERM>many&truehy;optional</CX5FX5FTERM
>, for the second one it is <CX5FX5FTERM>many&truehy;mandatory</CX5FX5FTERM
><LT.LIST.TEXT>Two types of one&truehy;many relations exist: without an extra table and with an extra table.</LT.LIST.TEXT
><LT.LIST.TEXT>For a one&truehy;many relation without an extra table, the foreign keys of the detail table are updated with an embedded SQL table.</LT.LIST.TEXT
><LT.LIST.TEXT>For a one&truehy;many relation with an extra table, a SQL insert is executed on the extra table. This table includes the keys of both related classes. For Informix, an insert procedure is used. </LT.LIST.TEXT
><LT.LIST.TEXT>Many&truehy;remove relations also appear in two versions: without and with an extra table. In the first case, the foreign keys in the detail table are set to NULL with an embedded SQL update.</LT.LIST.TEXT
><LT.LIST.TEXT>The many&truehy;remove relation with an extra table is executed with a delete procedure (Informix) using the keys of both the related classes on the extra table.</LT.LIST.TEXT
><LT.LIST.TEXT>Like the previous relations, the many&truehy;get has two variations. In both cases a pointer set is filled with an embedded SQL cursor and a <CX5FX5FINPUT>findInDB()</CX5FX5FINPUT
>. In the case without the extra table, the cursor operates on the detail table. In the case with an extra table, the cursor operates on the extra table.</LT.LIST.TEXT
><B.BODY>Qualified associations always have an extra table generated. The code generation is similar to that of the many&truehy;many association attribute, however, the qualifier is used as extra search condition for the embedded queries. The keys of the extra table are:</B.BODY
><B.BODY>Note that the qualifier data type is a standard type. This is an important difference with the non&truehy;persistent code generation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example: one&truehy;optional</L.LABEL
><B.BODY>The following overview shows a qualified association you can model in Class Association Diagrams. The multiplicity of the qualified association is <CX5FX5FTITLE>one&truehy;optional</CX5FX5FTITLE
><LT.LIST.TEXT>This function is implemented with an embedded SQL select on the extra created table followed by a <CX5FX5FINPUT>findInDB()</CX5FX5FINPUT
> call.</LT.LIST.TEXT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example: optional&truehy;many</L.LABEL
><B.BODY>The following overview shows a qualified association you can model in Class Association Diagrams. The multiplicity of the qualified association is <CX5FX5FTITLE>optional&truehy;many</CX5FX5FTITLE
><B.BODY>For Link Attribute and Reverse Link Attribute generation, a table is created for the link. The keys of this table are:</B.BODY
><B.BODY>The keys become foreign keys of the link table.</B.BODY
><B.BODY>In each of the related classes, a get function to the link class is generated. In the link class, a get function is generated to both related classes. Because there are only get functions created, no dispatch functions are needed. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The following overview shows examples of associations with a link attribute that you can model in Class Association Diagrams. </B.BODY
><LT.LIST.TEXT>The get function is created with an embedded SQL <CX5FX5FINPUT>select</CX5FX5FINPUT
> plus a <CX5FX5FINPUT>findInDB()</CX5FX5FINPUT
> function. The select is used to retrieve the parameters from the link class table using the own keys. The parameters go into the <CX5FX5FINPUT>findInDB().</CX5FX5FINPUT
><LT.LIST.TEXT>The get function is created with an embedded SQL <CX5FX5FINPUT>select</CX5FX5FINPUT
> plus a <CX5FX5FINPUT>findInDB()</CX5FX5FINPUT
> function. The select is used to retrieve the parameters from the link class table using the own keys. The parameters go into the <CX5FX5FINPUT>findInDB().</CX5FX5FINPUT
><RBW-IDXTERM TERM1="ESQLC++" TERM2="qualified association attribute"></RBW-IDXTERM
></SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>The code generation for qualified links is, for the main part, the same as the non&truehy;qualified version. The difference is the qualifier which is added as extra condition in the embedded SQL. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The following overview shows examples of associations with a <RBW-IDXTERM TERM1="association" TERM2="qualified link attribute"></RBW-IDXTERM
><B.BODY>The following Class Association Diagram displays the relation between a Person and the Company the person works for. Both the classes, Person and Company, are persistent classes for which SQL and ESQLC++ is generated. </B.BODY
><RBW-PARABODY>All instances of the classes Person and Company are removed (removeAll)</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>This simple program does not contain any RDBMS&truehy;specific ESQLC++ code. It only contains C++ code and calls to functions that are made available in C++. These calls are printed in bold.</B.BODY
>Specific Features of <RBW-IDXTERM TERM1="CA-OpenIngres"></RBW-IDXTERM
>CA&truehy;OpenIngres (E)SQL</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>CA&truehy;OpenIngres 1.1. is one of the Relational Database Management Systems (RDBMS) supported by the persistent code generation of ObjectTeam. In this section, some special features of CA&truehy;OpenIngres SQL and ESQL are discussed.</B.BODY
><B.BODY>The SQL generator does not generate primary key and foreign key constraints. Instead, it generates a <CX5FX5FINPUT>CREATE UNIQUE INDEX</CX5FX5FINPUT
> statement for the (composed) key of a table, and a <CX5FX5FINPUT>CREATE INDEX</CX5FX5FINPUT
> statement for the (composed) foreign key(s) in a table. </B.BODY
><B.BODY>During SQL code generation, DB procedures are generated. These procedures are executed after the database operations <CX5FX5FTITLE>delete</CX5FX5FTITLE
><B.BODY>Generally speaking, these DB procedures are generated for every table definition that is generated. However, in the following circumstances, they are not:</B.BODY
><RBW-PARABODY>When all rules for the operation and the types of links of the table are set to <CX5FX5FFILE.NAME>none</CX5FX5FFILE.NAME
>. These rules can be set in the customization file <CX5FX5FFILE.NAME>sqlrules</CX5FX5FFILE.NAME
>.</RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>As this means that no conditions must be met and no actions must be taken, the procedure would be empty; therefore, no DB procedure is generated.</LT.LIST.TEXT
><RBW-PARABODY>The procedure cannot be implemented due to a conflict in rules for an operation. Such a conflict occurs, for instance, when an <CX5FX5FTITLE>insert</CX5FX5FTITLE
> into a detail table demands the existence of the foreign key in the master table and vice versa. Another example of a conflict is when a <CX5FX5FTITLE>delete</CX5FX5FTITLE
> from a detail table is rejected if the foreign key exists in the master table and vice versa. </RBW-PARABODY
><B.BODY>To enforce and maintain referential integrity in a generated CA&truehy;OpenIngres database, the code generator of ObjectTeam uses a mechanism of rules and DB procedures.</B.BODY
><B.BODY>A rule is a user&truehy;defined mechanism that invokes a specified DB procedure whenever the database changes in a specified way. Whenever the execution of a statement satisfies an existing rule condition, the rule is fired, i.e. the DB procedure associated with that rule is executed. The code generator generates <CX5FX5FINPUT>CREATE PROCEDURE</CX5FX5FINPUT
> and <CX5FX5FINPUT>CREATE RULE</CX5FX5FINPUT
> statements to implement this mechanism.</B.BODY
><B.BODY>Whenever a referential integrity check fails, the procedure raises an error and returns, which causes all the statements in the procedure which have been executed to be rolled back. The statement that fired the rule associated with the procedure is also rolled back. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Supported RI rules </L.LABEL
><B.BODY>The following table summarizes the RI rules supported for the combinations of operation and table types:</B.BODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Reject on exist expkey in detail</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Declarative referential integrity</L.LABEL
><B.BODY>Declarative referential integrity, as supported by CA&truehy;OpenIngres, is not used by ObjectTeam code generation. The main reason is that certain cascade RI policies can result in DB procedures that need to call cross&truehy;dependent procedures and that need cursor&truehy;like structures.</B.BODY
><B.BODY>Within the ObjectTeam environment, the ESQLC++ preprocessor of CA&truehy;OpenIngres is used in the makefile. You can generate a makefile by selecting -Utilities | Generate Makefile in the Implementation phase. The corresponding command is named esqlcc. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated ESQL files</L.LABEL
><B.BODY>The following files are generated in your user environment by the ESQL generator:</B.BODY
><B.BODY>Note that the DB procedures mentioned earlier in this chapter are not called directly from the generated embedded C++ files. Instead, simple SQL statements like <CX5FX5FINPUT>INSERT</CX5FX5FINPUT
><B.BODY>Microsoft SQL&truehy;Server is one of the Relational Database Management Systems (RDBMS) supported by the persistent code generation of ObjectTeam. In this section, some special features of Microsoft Transact&truehy;SQL and Microsoft DB&truehy;Library for C(++) are discussed.</B.BODY
><RBW-IDXTERM TERM1="SQL generation" TERM2="for Microsoft SQL-Server"></RBW-IDXTERM
><RBW-ANCHOR ID="32104"></RBW-ANCHOR
>SQL: Database Table Creation</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Features</L.LABEL
><B.BODY>When using Microsoft SQL&truehy;Server, you should be aware of the following notes concerning the generation of table definitions in ObjectTeam:</B.BODY
><RBW-PARABODY>No Transact&truehy;SQL code is generated to check on column and table constraints. Because the column and table constraints are included in the column and table definition, the database engine enforces these constraints. </RBW-PARABODY
><RBW-PARABODY>No Transact&truehy;SQL code is generated for referential integrity constraints that are enforced by the database engine (through <CX5FX5FINPUT>FOREIGN KEY</CX5FX5FINPUT
><RBW-PARABODY>For each table, a <CX5FX5FINPUT>CREATE TABLE</CX5FX5FINPUT
> statement is generated, containing all columns and the following constraints: <CX5FX5FINPUT>NULL</CX5FX5FINPUT
>, <CX5FX5FINPUT>NOT NULL</CX5FX5FINPUT
>, <CX5FX5FINPUT>CHECK</CX5FX5FINPUT
>, and <CX5FX5FINPUT>PRIMARY KEY</CX5FX5FINPUT
>. Foreign keys are generated using the <CX5FX5FINPUT>ALTER TABLE</CX5FX5FINPUT
> command.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Numbering <RBW-IDXTERM TERM1="key fields" TERM2="numbering - in Microsoft SQL-Server"></RBW-IDXTERM
><RBW-IDXTERM TERM1="serial" TERM2="standard type for Microsoft SQL-Server"></RBW-IDXTERM
>key fields (serial)</L.LABEL
><B.BODY>Microsoft SQL&truehy;Server supports the serial (identity) type, which can be used for the automatic generation of unique numbers for key fields. ObjectTeam offers the standard type <CX5FX5FOBJECT.NAME>serial</CX5FX5FOBJECT.NAME
> to support this feature. </B.BODY
><B.BODY>You can apply the type <CX5FX5FOBJECT.NAME>serial</CX5FX5FOBJECT.NAME
> to only one field a table. Fields to which this type is applied cannot be updated. Foreign keys referencing a serial type are translated to the type <CX5FX5FINPUT>INTEGER</CX5FX5FINPUT
><RBW-IDXTERM TERM1="procedures" TERM2="stored - in Microsoft SQL-Server"></RBW-IDXTERM
>Stored procedures</L.LABEL
><B.BODY>Microsoft SQL&truehy;Server supports stored procedures. These procedures are written in Transact&truehy;SQL and stored in the database. For every table definition that is generated, stored procedures are generated that handle the database operations <CX5FX5FTITLE>delete</CX5FX5FTITLE
>, <CX5FX5FTITLE>insert</CX5FX5FTITLE
> and <CX5FX5FTITLE>update</CX5FX5FTITLE
>.</B.BODY
><B.BODY>The names of these stored procedures are as follows:</B.BODY
><B.BODY>Transact&truehy;SQL procedures generally consist of a basic query, which can be preceded by referential integrity checks that are not enforced by the database engine. An example of a basic query is:</B.BODY
><E.EXAMPLE>DELETE</E.EXAMPLE
><E.EXAMPLE>FROM person</E.EXAMPLE
><E.EXAMPLE>WHERE p_number=number</E.EXAMPLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Referential <RBW-IDXTERM TERM1="referential integrity" TERM2="in Microsoft SQL-Server"></RBW-IDXTERM
><B.BODY>To implement referential integrity that is not enforced by the database engine, ObjectTeam generates Transact&truehy;SQL procedures. </B.BODY
><B.BODY>Referential integrity rules are obtained from the SQL Model (see the <CX5FX5FTITLE>ObjectTeam Programming Interface Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>), where they are specified by links between tables. If a rule cannot be implemented, the procedure that should contain the rule is not generated and a warning message is issued. In that case, you have to implement the procedure manually.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Supported RI rules</L.LABEL
><B.BODY>On the following pages, every referential integrity rule is briefly discussed:</B.BODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Reject on not exist expkey in detail.</CX5FX5FBULLET.EMPHASIS
> This rule cannot be implemented. Microsoft SQL&truehy;Server prohibits the occurrence of foreign keys that do not exist in the master table. </RBW-PARABODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Reject on exist impkey in master.</CX5FX5FBULLET.EMPHASIS
> This rule must be executed before the query. To check this rule, the entire row is needed. Because Microsoft SQL&truehy;Server enforces the existence of a non&truehy;NULL imported key, you only need to test if the impkey is NULL. The following code is generated: </RBW-PARABODY
></LB.LIST.BULLET
><EM.EXAMPLE.MONO>IF <impkey> IS NOT NULL</EM.EXAMPLE.MONO
><LT.LIST.TEXT>To process this rule, non&truehy;key columns in the master table must be nullable. This cannot be checked during generation, but Microsoft SQL&truehy;Server will issue a runtime error. </LT.LIST.TEXT
><LT.LIST.TEXT>Besides, this cascade&truehy;<CX5FX5FTITLE>insert</CX5FX5FTITLE
> is an operation that is subject to other referential integrity rules. The following rules are applicable for <CX5FX5FTITLE>insert</CX5FX5FTITLE
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Delete in master impkey</CX5FX5FBULLET.EMPHASIS
>. This is a special case: the rule should be executed <CX5FX5FEMPHASIS>after</CX5FX5FEMPHASIS
> the query, otherwise references from the detail to the master may still exist. For this rule, the entire tuple is needed. The following code is generated: </RBW-PARABODY
><RBW-IDXTERM TERM1="data type" TERM2="in Microsoft SQL-Server"></RBW-IDXTERM
>SQL types and C++ types</L.LABEL
><LT.LIST.TEXT>During code generation, the code generator needs to know how SQL types must be converted to C++ types and vice versa. The required information is stored in the customization file <CX5FX5FFILE.NAME>db_binding.db_binding</CX5FX5FFILE.NAME
>, which can be found in the directory <CX5FX5FTERM><RBW-IDXTERM TERM1="db_binding"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Dynamic SQL" TERM2="generated for Microsoft SQL-Server"></RBW-IDXTERM
><RBW-ANCHOR ID="19689"></RBW-ANCHOR
>Dynamic SQL Features</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>All SQL statements are processed dynamically using <CX5FX5FPROCEDURE.NAME>db...</CX5FX5FPROCEDURE.NAME
> functions from the DB&truehy;library. These functions need to connect to the database. Because only one query at a time can be done on a single connection, a second connection is needed for all functions returning a set of objects.</B.BODY
><B.BODY>When using Microsoft SQL&truehy;Server, you should be aware of the following notes regarding the generation of Dynamic SQL (ESQL) in ObjectTeam.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-IDXTERM TERM1="C++ compiler" TERM2="for Microsoft SQL-Server"></RBW-IDXTERM
>C++ compiler</L.LABEL
><B.BODY>The code generated by the code generator of ObjectTeam can only be compiled with a Microsoft Visual C++ compatible compiler.</B.BODY
><B.BODY>To execute an application that was compiled to work with a Microsoft SQL&truehy;Server database, the following environment variables must be set properly:</B.BODY
><B.BODY>A number of Tcl procedures specific to Microsoft SQL&truehy;Server are available, mainly to support dynamic SQL. The definition of these procedures can be found in the following file:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>A special line is generated for each column that matches the <CX5FX5FTITLE>selector</CX5FX5FTITLE
>.</CELLBODY
><CELLBODY>This line contains one <CX5FX5FTITLE>if</CX5FX5FTITLE
> statement checking if the column should be <CX5FX5FTITLE>NULL</CX5FX5FTITLE
>. If so, a <CX5FX5FPROCEDURE.NAME>dbcmd</CX5FX5FPROCEDURE.NAME
>(<CX5FX5FTITLE>....=NULL</CX5FX5FTITLE
>) is executed; otherwise, a <CX5FX5FPROCEDURE.NAME>dbfcmd</CX5FX5FPROCEDURE.NAME
>Specific Features of <RBW-IDXTERM TERM1="Oracle"></RBW-IDXTERM
>Oracle (E)SQL</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Oracle is one of the Relational Database Management Systems (RDBMS) supported by the persistent code generation of ObjectTeam. In this section, some special features of Oracle SQL and Oracle Embedded SQL (ESQL) are discussed.</B.BODY
><RBW-PARABODY>As column and table constraints are included in the column and table definitions respectively, no PL/SQL code is generated to check on column and table constraints. The database engine enforces these constraints.</RBW-PARABODY
><RBW-PARABODY>Similarly, no PL/SQL is generated for referential integrity constraints that are enforced by the database engine through <CX5FX5FINPUT>FOREIGN KEY</CX5FX5FINPUT
>Stored <RBW-IDXTERM TERM1="procedures" TERM2="stored - in Oracle"></RBW-IDXTERM
>procedures</L.LABEL
><B.BODY>Oracle supports stored procedures. These procedures are written in PL/SQL and stored in the database. For every table definition that is generated, stored procedures are generated that handle the database operations <CX5FX5FTITLE>delete</CX5FX5FTITLE
>, <CX5FX5FTITLE>insert</CX5FX5FTITLE
> and <CX5FX5FTITLE>update</CX5FX5FTITLE
>.</B.BODY
><B.BODY>The names of these stored procedures are:</B.BODY
><B.BODY>PL/SQL procedures generally consist of a basic query, which can be preceded by referential integrity checks that are not enforced by the database engine. An example of a basic query is:</B.BODY
><B.BODY>To implement referential integrity that is not enforced by the database engine, ObjectTeam generates PL/SQL procedures. </B.BODY
><B.BODY>Referential integrity rules are obtained from the SQL Model (see the <CX5FX5FTITLE>ObjectTeam Programming Interface Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>), where they are specified by links between tables. If a rule cannot be implemented, the procedure that should contain the rule is not generated and a warning message is issued. In that case, you have to implement the procedure manually.</B.BODY
><B.BODY>For a number of rules checked during the <CX5FX5FTITLE>delete</CX5FX5FTITLE
> operation, all fields must be available. If such a rule occurs, the following code is generated:</B.BODY
><EM.EXAMPLE.MONO><definition of extra local variables></EM.EXAMPLE.MONO
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Reject on exist impkey in master</CX5FX5FBULLET.EMPHASIS
>. This rule must be executed before the query. To check this rule, the entire row is needed. Because Oracle enforces the existence of a non&truehy;NULL imported key, you only need to test if the impkey is NULL. The following code is generated: </RBW-PARABODY
></LB.LIST.BULLET
><EM.EXAMPLE.MONO>IF <impkey> IS NOT NULL THEN</EM.EXAMPLE.MONO
><LT.LIST.TEXT>To process this rule, non&truehy;key columns in the master table must be nullable. This cannot be checked during generation, but Oracle will give a runtime error. </LT.LIST.TEXT
><LT.LIST.TEXT>Besides, this cascade&truehy;<CX5FX5FTITLE>insert</CX5FX5FTITLE
> is an operation that is subject to other referential integrity rules. The following rules are applicable for <CX5FX5FTITLE>insert</CX5FX5FTITLE
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Delete in master impkey</CX5FX5FBULLET.EMPHASIS
>. This is a special case: the rule should be executed <CX5FX5FEMPHASIS>after</CX5FX5FEMPHASIS
> the query, otherwise references from the detail to the master may still exist. For this rule, the entire tuple is needed. The following code is generated: </RBW-PARABODY
><B.BODY>The ESQL code generated for the Oracle target can only be used with Pro*C version 2.0. The generated code does not work with earlier versions. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Fields from structs</L.LABEL
><B.BODY>In Oracle ESQL, no fields from structs can be passed to queries. To solve this, the code generator generates a dummy pointer for each field in a struct it needs.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Retrieving character strings</L.LABEL
><B.BODY>When character strings are retrieved, Oracle determines the length of the destination string by calling strlen(). The destination buffer is padded with spaces if the result string has less characters than the destination buffer. To avoid this, character strings are retrieved in an Oracle <CX5FX5FINPUT>VARCHAR</CX5FX5FINPUT
> struct and then copied to the destination pointer.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-IDXTERM TERM1="database" TERM2="accessing - in Oracle"></RBW-IDXTERM
>Database password</L.LABEL
><B.BODY>Calls to stored procedures are made from within the generated Embedded SQL. The Oracle preprocessor needs to connect to the target database to check if such a call is valid. Therefore, <CX5FX5FTERM>schema_name</CX5FX5FTERM
>/<CX5FX5FTERM>password</CX5FX5FTERM
> must be passed to the Oracle preprocessor. The user can do this by passing the password to the make command, for example:</B.BODY
>Specific Features of <RBW-IDXTERM TERM1="Sybase"></RBW-IDXTERM
>Sybase (E)SQL</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Sybase 10.0 is one of the Relational Database Management Systems (RDBMS) supported by the persistent code generation of ObjectTeam. In this section, some special features of Sybase SQL and ESQL are discussed.</B.BODY
><RBW-PARABODY>No Transact&truehy;SQL code is generated to check on column and table constraints. Because the column and table constraints are included in the column and table definition, the database engine will enforce these constraints. </RBW-PARABODY
><RBW-PARABODY>No Transact&truehy;SQL code is generated for referential integrity constraints that are enforced by the database engine (through <CX5FX5FINPUT>FOREIGN KEY</CX5FX5FINPUT
> constraints).</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Numbering <RBW-IDXTERM TERM1="key fields" TERM2="numbering - in Sybase"></RBW-IDXTERM
><RBW-IDXTERM TERM1="identity" TERM2="standard type for Sybase"></RBW-IDXTERM
>key fields (identify)</L.LABEL
><B.BODY>Identity columns in Sybase can be used for the automatic generation of numbers for key fields. ObjectTeam offers the standard type <CX5FX5FOBJECT.NAME>identity</CX5FX5FOBJECT.NAME
> to support this feature.</B.BODY
><B.BODY>During code generation, the SQL generator translates the standard type <CX5FX5FOBJECT.NAME>identity</CX5FX5FOBJECT.NAME
> into <CX5FX5FINPUT>IDENTITY</CX5FX5FINPUT
> if it is applied to a column that is not imported from another table. Whenever a new tuple is inserted in the database, this identity is used to generate the value of the associated database column. </B.BODY
><B.BODY>If applied to a column that <CX5FX5FTITLE>is</CX5FX5FTITLE
> imported from another table, the standard type <CX5FX5FOBJECT.NAME>identity</CX5FX5FOBJECT.NAME
> is translated into the <CX5FX5FINPUT>NUMERIC</CX5FX5FINPUT
> type. </B.BODY
><B.BODY>Each table in a database can have one Identity column. Identity columns cannot be updated and do not allow <CX5FX5FINPUT>NULL</CX5FX5FINPUT
>Stored <RBW-IDXTERM TERM1="procedures" TERM2="stored - in Sybase"></RBW-IDXTERM
>procedures</L.LABEL
><B.BODY>Sybase supports stored procedures. These procedures are written in Transact&truehy;SQL and stored in the database. For every table definition that is generated, stored procedures are generated that handle the database operations <CX5FX5FTITLE>delete</CX5FX5FTITLE
>, <CX5FX5FTITLE>insert</CX5FX5FTITLE
> and <CX5FX5FTITLE>update</CX5FX5FTITLE
>.</B.BODY
><B.BODY>The names of these stored procedures are:</B.BODY
><B.BODY>Transact&truehy;SQL procedures generally consist of a basic query, which can be preceded by referential integrity checks that are not enforced by the database engine. An example of a basic query is:</B.BODY
><B.BODY>To implement referential integrity that is not enforced by the database engine, ObjectTeam generates Transact&truehy;SQL procedures. </B.BODY
><B.BODY>Referential integrity rules are obtained from the SQL Model (see the <CX5FX5FTITLE>ObjectTeam Programming Interface Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>), where they are specified by links between tables. If a rule cannot be implemented, the procedure that should contain the rule is not generated and a warning message is issued. In that case, you have to implement the procedure manually.</B.BODY
><B.BODY>For a number of rules checked during the <CX5FX5FTITLE>delete</CX5FX5FTITLE
> operation, all fields must be available. If such a rule occurs, the following code is generated:</B.BODY
><EM.EXAMPLE.MONO><definition of extra local variables></EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>SELECT <extra local variable_1> = <nonkey_1>,</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> <extra local variable_2> = <nonkey_2>,</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> ...</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>FROM <table to delete from></EM.EXAMPLE.MONO
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Reject on exist impkey in master</CX5FX5FBULLET.EMPHASIS
>. This rule must be executed before the query. To check this rule, the entire row is needed. Because Sybase enforces the existence of an imported key with nullability of NOT NULL, the code generator only needs to test if the impkey is NULL. The following code is generated: </RBW-PARABODY
></LB.LIST.BULLET
><EM.EXAMPLE.MONO>IF <impkey> IS NOT NULL</EM.EXAMPLE.MONO
><LT.LIST.TEXT>This rule can only be processed when non&truehy;key columns in the master table are nullable. This cannot be checked during generation, but Sybase will issue a runtime error if they are not.</LT.LIST.TEXT
><LT.LIST.TEXT>Moreover, this cascade&truehy;<CX5FX5FTITLE>insert</CX5FX5FTITLE
> operation is subject to other RI rules as well. The following rules are applicable for the <CX5FX5FTITLE>insert</CX5FX5FTITLE
><RBW-PARABODY><CX5FX5FTITLE>insert in master impkey</CX5FX5FTITLE
> </RBW-PARABODY
></LB2.LIST.BULLET.2
><LT2.LIST.TEXT.2>This action is only supported if the impkey is equal to the key. If this is not the case, it will result in a runtime Sybase error. </LT2.LIST.TEXT.2
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Delete in master impkey</CX5FX5FBULLET.EMPHASIS
>. This is a special case: the rule should be executed <CX5FX5FEMPHASIS>after</CX5FX5FEMPHASIS
> the query, otherwise references from the detail to the master may still exist. For this rule, the entire tuple is needed. The following code is generated: </RBW-PARABODY
> is used by ObjectTeam to create, delete and fill databases. On PC platforms, <CX5FX5FINPUT>isql</CX5FX5FINPUT
> is invoked with the argument <CX5FX5FINPUT>&truehy;J</CX5FX5FINPUT
>.</B.BODY
><B.BODY>To be able to execute an application that was compiled to work with a Sybase database, the following environment variables must be set properly:</B.BODY
><RBW-PARABODY><CX5FX5FINPUT><RBW-IDXTERM TERM1="DBUSERNAME" TERM2="runtime environment variable for Sybase"></RBW-IDXTERM
>DBUSERNAME</CX5FX5FINPUT
> (PC platforms only). The name of the user as whom you connect to the database. This variable is only needed when you want to connect to the database under a different user name as specified by the variable USERNAME.</RBW-PARABODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="22291" TYPE="XREF-TEXTCOPY">How Tcl is Used in Code Generation&rbwtab;E–80</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="15250" TYPE="XREF-TEXTCOPY">Customizing Tcl Scripts Used for Code Generation&rbwtab;E–83</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="14052" TYPE="XREF-TEXTCOPY">Customizing Data Types&rbwtab;E–87</RBW-XREF
>How Tcl is Used in Code Generation</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="37266"></RBW-ANCHOR
>Introduction</L.LABEL
><B.BODY>This entry focuses on the use of Tcl (Tool command language) in ObjectTeam. It does not provide an introduction to Tcl itself. If you want to familiarize yourself with Tcl, we recommend the following introductory book on Tcl:</B.BODY
><LT.LIST.TEXT>Ousterhout, John K. <CX5FX5FTITLE>Tcl and the Tk Toolkit</CX5FX5FTITLE
><B.BODY>Tcl (Tool Command Language) is an interpretive command language that resembles C. By default all arguments are passed as strings. These strings are C&truehy;compatible. Tcl consists of:</B.BODY
><B.BODY>When the ObjectTeam shell executes a Tcl script file, it translates information from the repository, internal models, and <RBW-IDXTERM TERM1="code generation model" TERM2="and Tcl"></RBW-IDXTERM
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Refer to general Tcl documentation for details.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Calls to other Tcl procedures</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>These procedures are stored in other Tcl files. They become available when the file in which the procedure is defined is sourced.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Calls to methods of classes in the <RBWAUTO-0024>ObjectTeam</RBWAUTO-0024
><RBWAUTO-0024></RBWAUTO-0024
> models</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The classes of the ObjectTeam models (including the OOPL model and SQL model) are documented in <CX5FX5FTITLE>ObjectTeam Repository Interface Guide</CX5FX5FTITLE
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Besides methods of classes belonging to the <RBWAUTO-0024>ObjectTeam</RBWAUTO-0024
><RBWAUTO-0024></RBWAUTO-0024
> models, methods belonging to built&truehy;in classes can also be called. Refer to the <CX5FX5FTITLE>ObjectTeam Repository Interface Guide</CX5FX5FTITLE
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>These commands are built&truehy;in in otsh. You can use these commands, but you cannot edit or view them like Tcl procedures. Refer to the <CX5FX5FTITLE>ObjectTeam Repository Interface Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for details. </CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="35220"></RBW-ANCHOR
>Which Tcl files are used?</L.LABEL
><B.BODY>Tcl procedures used for code generation are stored in procedural Tcl script files. During code generation, these scripts are interpreted and executed by the ObjectTeam Shell (otsh). When you select Utilities | Generate C++ in the Browser on Implementation System level, otsh interprets the procedures in the Tcl file <CX5FX5FFILE.NAME><RBW-IDXTERM TERM1="import.tcl"></RBW-IDXTERM
>import.tcl</CX5FX5FFILE.NAME
>. These procedures use procedures defined in other Tcl scripts, and they also activate other Tcl script files.</B.BODY
><B.BODY>The Tcl files used for non&truehy;persistent and persistent code generation can be found in the following directories:</B.BODY
>Customizing Tcl Scripts Used for <RBW-IDXTERM TERM1="code generation" TERM2="adapting"></RBW-IDXTERM
>Code Generation</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>User&truehy;defined Tcl files</L.LABEL
><B.BODY>Because of the open character of Tcl, you are free to rewrite the Tcl procedures of the Tcl scripts, if you feel like adapting the code generation to your specific needs and circumstances. You can include your own properties, control flow keywords and section keywords in the code generation this way. You can even build your own code generator by creating your own Tcl scripts. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Which Tcl files can you customize</L.LABEL
><B.BODY>To customize a Tcl script, you must create a user&truehy;defined customization file. These are the ObjectTeam Tcl script files that you can extend with a user&truehy;defined customization file:</B.BODY
><B.BODY>The most obvious way to extend these default script is by creating a customization file <CX5FX5FFILE.NAME>u_</CX5FX5FFILE.NAME
><RBWAUTO-0022>fileName</RBWAUTO-0022
>.tcl. If you want to overrule any of the Tcl procedures in the following default Tcl files, Cayenne recommends that you include them in the customization file <CX5FX5FFILE.NAME><RBW-IDXTERM TERM1="u_gencpp.tcl"></RBW-IDXTERM
> contains several configurable procedures like the definition of DBObject. These procedures can also be redefined using a customization file called<RBW-IDXTERM TERM1="u_check.tcl"></RBW-IDXTERM
> <CX5FX5FFILE.NAME>u_check.tcl</CX5FX5FFILE.NAME
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="37212"></RBW-ANCHOR
>Where to Store User&truehy;defined Tcl Procedures</L.LABEL
><B.BODY>The Tcl script files used for the default code generation are stored in the file system. They can be found in the following directories under <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
> directory in the module directory of type PersCppClassLib</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>If you want to adapt the default code generation, you can edit the Tcl files in this directory, but it is better to leave the original files untouched. You can make otsh use user&truehy;defined files by: </B.BODY
><RBW-PARABODY>Creating and activating a user&truehy;defined ObjectTeam module.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>You can <CX5FX5FTITLE>overrule</CX5FX5FTITLE
> existing Tcl files or you can create new Tcl files with new user&truehy;defined Tcl procedures and thus <CX5FX5FTITLE>extending</CX5FX5FTITLE
> the default code generation. </B.BODY
><B.BODY>Each of the storing methods listed above are discussed below.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Storing Tcl files as customization file in the repository</L.LABEL
><B.BODY>The Browser level in which you store the customization file determines the extent to which the Tcl file must be used by otsh. A customization file stored on System level for instance, won’t affect the code generation for another system in the same Configuration. However, a customization file stored on Phase level will, provided there are no Tcl customization files of the same name stored on Implementation System level.</B.BODY
><B.BODY>The Tcl file which is stored the closest in hierarchy to the current level (for example, System level) overrules all higher customization files by the same name.</B.BODY
><RBW-PARABODY>If you want to replace an existing file, enter the exact name of the default Tcl file you want to replace (for example, <CX5FX5FFILE.NAME>cpp_regen.tcl</CX5FX5FFILE.NAME
>). The default Tcl file of the corporate level will be ignored in that case.</RBW-PARABODY
><RBW-PARABODY>If you want to create a customization file in which you either redefine procedures from the default file or extend the default file with new procedures, enter the name of the default file with the prefix <CX5FX5FFILE.NAME>u_</CX5FX5FFILE.NAME
> (for example, <CX5FX5FFILE.NAME>u_gencpp.tcl</CX5FX5FFILE.NAME
>). The default Tcl file on corporate level will be sourced and will be complemented by the customization file.</RBW-PARABODY
><RBW-PARABODY>Enter the required Tcl code.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>If you are replacing an existing default Tcl file, you might include the contents of the default Tcl file first and make all the necessary changes later.</LT.LIST.TEXT
><RBW-PARABODY>Save the customization file.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The next time you generate code, the new Tcl customization file is sourced by otsh.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Storing Tcl files in the same System as where the code is generated</L.LABEL
><B.BODY>One of the available file types on Implementation system level is <CX5FX5FTITLE>Tcl</CX5FX5FTITLE
>. You can create new files of this type and define user&truehy;defined Tcl procedures in such a file. During code generation, otsh sources all files of the type Tcl in the current system, regardless of their name.</B.BODY
><RBW-PARABODY>Edit and save the new Tcl file.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The next time you generate code, the new Tcl file is sourced by otsh.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Storing Tcl files in a System Tcl</L.LABEL
><B.BODY>If you don’t want to store user&truehy;defined Tcl files in the same system in which your code is generated, you can decide to create a system called <CX5FX5FTITLE>Tcl</CX5FX5FTITLE
> and store your user&truehy;defined Tcl files in that system. Any Tcl file that is defined in such a system is sourced during code generation. You can use this mechanism for new user&truehy;defined Tcl files or for user&truehy;defined Tcl files that are meant to replace existing ones.</B.BODY
><RBW-PARABODY>Edit and save the new Tcl file.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The next time you generate code, the new Tcl file is sourced by otsh.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Creating a user&truehy;defined module</L.LABEL
><B.BODY>Besides storing customized Tcl files as customization files or as External File Version, you can create a user&truehy;defined ObjectTeam module. You can then copy over all the files from the corresponding default module directory provided by Cayenne to your user&truehy;defined module, and edit the customization files directly. Finally, you activate it.</B.BODY
>In a user&truehy;defined module, you cannot extend the default files with your own procedures or redefine existing procedures through an <CX5FX5FFILE.NAME>u_ *.tcl</CX5FX5FFILE.NAME
> file. You have to edit the Tcl files directly.</N.NOTE
><B.BODY>If you want to test a customized Tcl file before you insert it into the repository of ObjectTeam, you can decide to create the Tcl file in your file system and feed it to otsh outside the ObjectTeam environment. </B.BODY
><B.BODY>See the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for details on how to start otsh from the command line.</B.BODY
><B.BODY>When the Tcl file has reached its final state, you can decide to incorporate it in the repository, as described above. </B.BODY
>Customizing Data <RBW-IDXTERM TERM1="data type" TERM2="customizing"></RBW-IDXTERM
>Types</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Standard data types</L.LABEL
><B.BODY>In the Object Design phase you can use standard types to define data types of data attributes and parameters. All the valid standard types are stored in the following file:</B.BODY
><B.BODY>This file also contains minimum and maximum values for the standard types.</B.BODY
><B.BODY>Whenever you generate code or check a diagram’s contents, the data types used in the diagram are checked against the data types in the standard types file. This checking is always carried out, even when you don’t generate persistent code.</B.BODY
><B.BODY>During code generation, the standard types are mapped to:</B.BODY
>Customizing the default stand_types file </L.LABEL
><B.BODY>You can create a customization file <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
> if you want to extend or change the default <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
> file. You can do that by selecting File | New on the Browser level of your choice with the pseudo object <CX5FX5FTITLE><customization files></CX5FX5FTITLE
> as the current object. The name of the new customization file must be <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
>. After you have created the file, you can edit it and save it.</B.BODY
><B.BODY>The next time you generate code, your user&truehy;defined customization file is evaluated instead of the customization file on Corporate level. The nearest customization file overrules all other customization files that might be defined on higher levels. So if you have, for instance, a user&truehy;defined customization file <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
> defined on Configuration level, Project level, and System level, the one on System level overrules all the other ones.</B.BODY
><B.BODY>C++ types are data types that are supported by the ESQLC++ implementation of the Relational Database System (RDBMS) used. If you are not using an RDBMS, the standard types are mapped to standard C++ types.</B.BODY
><B.BODY>The mapping is taken care of by the following customization file:</B.BODY
>What does the lang_types file look like?</L.LABEL
><B.BODY>Here is an example of a <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
> file for the Informix package. </B.BODY
><B.BODY>The first column in this file lists the standard types. These must be consistent with the types in the <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
> file. The second column lists the C types the standard types must be mapped upon. In the column <CX5FX5FINPUT>range</CX5FX5FINPUT
> the type of brackets used in the target language is indicated.</B.BODY
><B.BODY>SQL types are data types that are supported by the SQL implementation of the RDBMS used. If you are not using an RDBMS, the standard types are mapped to ANSI SQL types.</B.BODY
><B.BODY>The mapping is taken care of by the following configuration file:</B.BODY
><B.BODY>Here is an example of a <CX5FX5FFILE.NAME>db_types.db_types</CX5FX5FFILE.NAME
> file for the Informix package. </B.BODY
><B.BODY>The first column in this file lists the standard types. These must be consistent with the types in the <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
> file. The second column lists the SQL types the standard types must be mapped upon. In the column has <CX5FX5FINPUT>range</CX5FX5FINPUT
> the type of brackets used in the target language is indicated.</B.BODY
><B.BODY>ObjectTeam offers the possibility to incorporate rules for referential integrity checking in the database. The default Referential Integrity rules are specified in the following customization file:</B.BODY
><B.BODY>In this file, a rule is specified for every type of association, aggregation and generalization. The rules, specified in the last column of the file, refer to Tcl procedures. </B.BODY
><B.BODY>During persistent code generation, the Tcl procedure specified for the specific type of relation is called. The SQL code that is generated by this procedure is inserted in the SQL script <CX5FX5FFILE.NAME>create_procs</CX5FX5FFILE.NAME
>. See the <CX5FX5FTITLE>ObjectTeam Repository Interface Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for an overview of the mapping of the different types of relations to the SQL model.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What does the sqlrules file look like?</L.LABEL
><B.BODY>Here is an example of the customization file <CX5FX5FFILE.NAME>sqlrules</CX5FX5FFILE.NAME
><RBW-PARABODY><CX5FX5FTITLE>Cascade<RBW-IDXTERM TERM1="cascade" TERM2="policy for referential integrity"></RBW-IDXTERM
></CX5FX5FTITLE
>: referential integrity is maintained by propagating the database operation across the association. The most obvious use is for <CX5FX5FPROCEDURE.NAME>delete</CX5FX5FPROCEDURE.NAME
><RBW-PARABODY><CX5FX5FTITLE>Nullify<RBW-IDXTERM TERM1="nullify" TERM2="policy for referential integrity"></RBW-IDXTERM
></CX5FX5FTITLE
>: when an object is removed, the foreign key value is changed to NULL, indicating that no link exists. This policy cannot be selected for <CX5FX5FPROCEDURE.NAME>insert</CX5FX5FPROCEDURE.NAME
>: whether or not referential integrity is checked for this type of relation is determined by what is indicated at the top of the SQL rules file: on or off</RBW-PARABODY
>: this rule is only valid for the database operations <CX5FX5FTITLE>insert</CX5FX5FTITLE
> and <CX5FX5FTITLE>update</CX5FX5FTITLE
> and for the policy <CX5FX5FTITLE>Restrict</CX5FX5FTITLE
>. The database operation is cancelled if a tuple exports or imports keys and the tuple to which it export keys or from which it imports keys doesn’t exist.</RBW-PARABODY
>: this rule is only valid for the database operations <CX5FX5FTITLE>insert</CX5FX5FTITLE
> and <CX5FX5FTITLE>update</CX5FX5FTITLE
> and for the policy <CX5FX5FTITLE>Cascade</CX5FX5FTITLE
>. If a tuple is inserted in the detail table and the corresponding keys do not exist in the master table, they are inserted in the master table.</RBW-PARABODY
><B.BODY>If you want to change anything regarding Referential Integrity policies that must affect all relations of a particular type, you should create a customization file with the name <CX5FX5FFILE.NAME>sqlrules</CX5FX5FFILE.NAME
> on the Browser level of your choice.</B.BODY
><B.BODY>You can create customization files on Project level, Configuration level, Phase level, and System level. These files are stored in the repository. The customization files on Corporate level are not stored in the repository, but in the <CX5FX5FFILE.NAME>etc</CX5FX5FFILE.NAME
> directory under <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
>.</B.BODY
><B.BODY>The Tcl files that are used during code generation first check if there are any customization files present in the repository. If there aren’t, the customization file from corporate level (i.e. the file stored in the <CX5FX5FFILE.NAME>etc</CX5FX5FFILE.NAME
> directory under <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
>) is used. If the same customization file is stored on more than one Browser level, the file on the Browser level closest in hierarchy is evaluated.</B.BODY
><B.BODY>The default policy for a particular type of relation is specified in the SQL rules file. For every type of relation a certain rule is defined. However, for individual associations, aggregations or generalizations, you can overrule the following settings from the sqlrules file:</B.BODY
><RBW-PARABODY>Whether or not referential integrity must be checked </RBW-PARABODY
></LB.LIST.BULLET
><BI.BODY.INTRO>You can do that in the Class Association Diagram by editing the properties of the association, aggregation, or generalization you want to overrule the default settings for. The following figure shows the Edit Properties dialog box that you would use:</BI.BODY.INTRO
> contains information specific to the CORBA IDL code generator. The code generator automates the process of generating CORBA IDL specifications from systems in the Object Design phase. This guide describes the mapping of the ObjectTeam model to CORBA IDL. </B.BODY
><B.BODY>Refer to the <CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for general information about the code generation process.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisites</L.LABEL
><B.BODY>This guide is intended for experienced users of ObjectTeam and the analysis and design method it supports. Knowledge of CORBA IDL is also required. </B.BODY
><B.BODY>To customize or extend the capabilities of the CORBA IDL code generator, you must have a thorough understanding of the ObjectTeam Shell, the Object&truehy;Oriented Programming Language (OOPL) model structure, and the Tool Command Language (Tcl) commands.</B.BODY
> provides the menu items, the properties and the Tcl code required to use the CORBA IDL Code Generator. Therefore, before moving to the Object Design phase, make sure this module is active.</B.BODY
><B.BODY>You can check if a module is active on a particular Browser level by selecting Utilities | Show Active Modules on that level.</B.BODY
> for details on how to activate a module.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Object Design and Implementation</L.LABEL
><B.BODY>This chapter describes the tasks of the Object Design phase. <RBW-XREF REFID="41422" TYPE="XREF-TEXTCOPY">Chapter 2, Generating CORBA IDL</RBW-XREF
>, describes the tasks of the Implementation phase. You work iteratively in these two phases to generate code and complete your application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose of object design</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="Object Design" TERM2="activities in this phase"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Object Design" TERM2="development phase in ObjectTeam project"></RBW-IDXTERM
>In ObjectTeam, the CDs (and the objects defined in the CDs) provide all the source data needed for code generation. The goal of object design is to add to the CDs all the data required for successful code generation. For example, you add properties (such as the Attribute Access property, which establishes read/write access to an attribute) and incorporate language&truehy;specific syntax (such as data type specifications for attributes and the arguments of operations).</B.BODY
><B.BODY>You might also add data to diagrams other than CDs. The code generator does not use oter diagrams, but they are useful for describing the behavior of classes, their attributes and operations.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="19276" TYPE="XREF-TEXTCOPY">Refining the Class Diagrams&rbwtab;1–3</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="40198" TYPE="XREF-TEXTCOPY">Hints and Tips for Effective Code Generation&rbwtab;1–6</RBW-XREF
>Introduction<RBW-IDXTERM TERM1="Class Association Diagram"></RBW-IDXTERM
></L.LABEL
><B.BODY>The CDs and the objects defined in the CDs provide all the source data needed for code generation. <RBW-IDXTERM TERM1="Class Association Model"></RBW-IDXTERM
>These diagrams distinguish the classes in a system and describe their identities and their features. In the Object Design phase, you must add to the CDs sufficient detail for successful code generation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using data from diagrams other than CDs</L.LABEL
><B.BODY>Diagrams other than the CDs are not used as input for code generation. However, they contain valuable information that can help you to complete and verify the CDs. The following table summarizes how you can use these other diagrams to help you find important objects that are not yet in the CDs.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>STD state names (enumerated list as an attribute value)</CELLBODY
><CELLBODY>STD condition on an event</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Classes</L.LABEL
><B.BODY>When you work on CDs, you focus on the implementation of classes. The CD must include all classes and the associations (and inheritance) between classes. In the Object Design phase, you may introduce new classes to ease implementation and improve performance.</B.BODY
><B.BODY>You must include all attributes and operations for each class. The attributes of a class map to the attributes of the class type. The operations of the class map to functions and procedures of the class type. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>External classes</L.LABEL
><B.BODY>A class must have at least one attribute or one operation to generate code. Classes that have no attributes or operations are translated as external classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Associations</L.LABEL
><B.BODY>You must define the associations between all classes, including any constraints.</B.BODY
><B.BODY>Role names must also be defined. Every association needs at least one role name. Every mandatory association must have a role name. Without a role name, you cannot use the association.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role names in Analysis and System Design</SL.SUBLABEL
><B.BODY>In the Analysis and System Design phases, role names distinguish a class by showing the role the class is playing in a relationship with another class. Each role name defines the role of the class within the context of a single association. It also indicates the use and direction of the association toward the class that plays a role. For example, a manager can be both the boss of a coworker and an employee of a company.</B.BODY
>Role names in Object Design and Implementation</SL.SUBLABEL
><BI.BODY.INTRO>In the Object Design and Implementation phases, the use of role names is extended. The code generator creates access methods for an association if the class at the far end has a role name for the association. In the previous example, the code generated for Coworker includes access methods for Manager; the code generated for Manager does not include access methods for Coworker.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attributes</L.LABEL
><B.BODY>You must specify each attribute completely, including its data type. The way to specify a data type for an attribute is to include the type in the class symbol, for example:</B.BODY
><B.BODY>Data types of attributes and arguments can be standard ObjectTeam types, standard types for your target language, or class types and derived types. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Operations</L.LABEL
><BI.BODY.INTRO>You must specify each operation completely. This includes specifying such aspects as:</BI.BODY.INTRO
><RBW-PARABODY>Any parameters, as well as their data types</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Properties</L.LABEL
><BI.BODY.INTRO><RBW-IDXTERM TERM1="property" TERM2="using - to specify implementation details"></RBW-IDXTERM
>In the Object Design phase, a variety of properties allow you to specify many implementation details. <RBW-IDXTERM TERM1="property" TERM2="using - to specify implementation details"></RBW-IDXTERM
>These details are incorporated in the final code.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Checking</L.LABEL
><B.BODY>The last activity in object design is to use Check | Global Model to check the CDs. The CDs must be error&truehy;free before they can be used for code generation. See the <CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for more information about the Check utility.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</L.LABEL
><B.BODY><RBW-XREF REFID="37761" TYPE="XREF-TEXTCOPY">Chapter 3, Mapping Modeling Data to CORBA IDL</RBW-XREF
>, describes how the ObjectTeam model is translated into code. You can use this information to help you complete the CDs in the Object Design phase.</B.BODY
>Hints and Tips for Effective Code Generation</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Following are a few tips for effective code generation. It may be helpful to be aware of these items as you prepare for code generation, and then again as you generate and regenerate your source files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Understanding the translations</L.LABEL
><B.BODY>Before generating code, read through this guide. It contains detailed information about the data that you must include in your CDs for successful code generation. It also explains how the code generator translates the ObjectTeam model into source code files, what changes you can make to the source code files, and how to regenerate them without losing your changes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Naming conventions</L.LABEL
><B.BODY>Agree upon and follow a naming convention for projects, configurations, systems, classes, special characters, and so on. In addition, bear in mind that spaces between words (in class names, for instance) are deleted by ObjectTeam code generators.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing code generation</L.LABEL
><B.BODY>The code generators execute Tcl scripts that translate a model into source code. You can modify these scripts or create your own.. Always use caution when customizing or creating scripts; such scripts are not supported.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using multiple languages in a single application</L.LABEL
><B.BODY>Each ObjectTeam code generator is designed to generate code for one language. You can create an application that uses multiple languages by using different code generators to generate code for different systems; however, the generated code is not integrated across systems. </B.BODY
><B.BODY>The ObjectTeam code generators are not designed to provide language integration. To build an application that uses multiple languages, you must do the following: </B.BODY
>When you create a separate ObjectTeam system for each language&truehy;specific subsystem, be sure to define your classes in the appropriate system. When ObjectTeam generates code for the current system, it generates code for the classes that are defined in that system. It does not generate code for classes referenced, but not defined in, the current system; such classes are treated as external classes.</N.NOTE
>Typically, the ultimate goal of modeling an application is to produce code that implements the application. In ObjectTeam, you can generate a significant portion of the code automatically, then complete the code by adding the details that not specified in the model.</B.BODY
><RBW-PARABODY>Only the CDs (and the objects defined in the CDs) are used for code generation. Therefore, before code generation, it is critical that the CDs be fully defined, as described in <RBW-XREF REFID="30937" TYPE="XREF-TEXTCOPY">Chapter 1, Preparing Your ObjectTeam Model for Code Generation</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Steps in code generation</L.LABEL
><B.BODY>The following table provides an overview of the code generation process. This chapter describes each step in greater detail.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Generate CORBA IDL files. During this step, ObjectTeam creates CORBA IDL specification files on System level in the Implementation phase.</CELLBODY
> System level in the Implementation phase is fundamentally different than System level in other phases. The System files in the Implementation phase are specification files, not diagram files.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Using your ORB implementation, generate code. If necessary: correct the model, and regenerate the code files.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Illustration of code generation</L.LABEL
><BI.BODY.INTRO>The following illustration shows how ObjectTeam generates code, including the names of the Tcl scripts that it uses. The CDs and CDMs shown at the top are in the Object Design phase.</BI.BODY.INTRO
><B.BODY>The Object Management Group (OMG) developed specifications for interactions between distributed objects. These specifications are referred to as the Common Object Request Broker Architecture (CORBA). As part of its specifications, CORBA defines the Interface Definition Language (IDL). CORBA IDL describes an object’s interface which enables objects to communicate their methods and attributes to other objects. This is done without individual objects needing to know each other’s location or how they accomplish their tasks. Communication is handled by an Object Request Broker (ORB). ORBs negotiate requests (messages) between clients and servers and their related data sets. </B.BODY
><B.BODY>CORBA IDL is a separate language within the CORBA specification. Its lexical rules are similar to those of C++ with some new keywords added. Using CORBA IDL statements, you can define the kind of objects and their attributes and operations that your client uses or your server provides.</B.BODY
>CORBA IDL only defines the interface to the objects. An implementation mapping between the interface and the actual object data and procedures is required. The ObjectTeam CORBA IDL code generator does not support this mapping.</N.NOTE
><B.BODY>The CORBA IDL code generator automatically generates CORBA IDL specifications for ObjectTeam systems. It interprets classes, associations, and generalization (inheritance) and translates them into the appropriate CORBA IDL constructs. One file is produced per system with a file extension of <CX5FX5FFILE.NAME>.idl</CX5FX5FFILE.NAME
>.</B.BODY
><B.BODY>In contrast to the other ObjectTeam code generators, the CORBA IDL code generator produces only CORBA IDL specifications. To produce executable code, you normally compile the CORBA IDL specifications into a target language such as C++ or Java. Refer to your ORB vendor’s documentation for information on mapping CORBA IDL to client or server objects.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Regenerating specification files</L.LABEL
><B.BODY>The ObjectTeam CORBA IDL code generator produces ASCII format CORBA IDL files. Do not edit these files since any edits you make will not be maintained. They are overwritten each time you generate code.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Tcl scripts for code generation</L.LABEL
><B.BODY>The scripts written for code generation retrieve information from the code generation models, format this information and write the results to source code files. Code generation models are built from the CDs in the Object Design phase.</B.BODY
><B.BODY>The default <RBW-IDXTERM TERM1="Tcl" TERM2="script files used for code generation"></RBW-IDXTERM
>Tcl scripts used by otsh to generate CORBA IDL source code can be found under the <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
><B.BODY>When you generate code for a system in the Implementation phase, the code generator transforms the CDs and CDMs of the Object Design phase into CORBA IDL source files. At System level of the Implementation phase, you can then refine the source code and complete the application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Implementation Phase is different</L.LABEL
><B.BODY>The System level of the Implementation phase is fundamentally different from System level of any other phase. In the Implementation phase, the System files are CORBA IDL files. In other phases, the System files are ObjectTeam diagrams.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generate code on Phase or System level</L.LABEL
><B.BODY>You can generate code on the Implementation Phase level or on the System level of the Implementation phase.</B.BODY
><RBW-PARABODY>On the <CX5FX5FBULLET.EMPHASIS>Implementation Phase level</CX5FX5FBULLET.EMPHASIS
>, you can generate code for one or more systems. This creates a matching system in the Implementation Phase that contains the generated source files. To regenerate code for an existing system, use System level.</RBW-PARABODY
><RBW-PARABODY>On the <CX5FX5FBULLET.EMPHASIS>System level of the Implementation phase</CX5FX5FBULLET.EMPHASIS
>, you can (re)generate code for the entire system, or regenerate selected source files.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>Typically, you use Implementation Phase level to generate code for a system initially and System level to regenerate code subsequently.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to generate code on Implementation Phase level</L.LABEL
> to select the systems from the Object Design phase for which you want to generate code. You can select only systems for which no code has been generated yet</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>ObjectTeam opens a Monitor window for displaying log messages, then generates the source files.</LR.LIST.RESULT
><LR.LIST.RESULT>ObjectTeam opens a Monitor window for displaying log messages, then generates code for the files. The following illustration shows the Monitor window after generating code for a system that contains only one class.</LR.LIST.RESULT
><B.BODY>Source files are stored in the repository as external files. They are also written to the user environment. (See the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for more information about the user environment.)</B.BODY
><B.BODY>The objects and their characteristics specified in ObjectTeam do not always map exactly to the language of a particular ObjectTeam code generator.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>CORBA IDL code generation limitations </L.LABEL
><B.BODY>Please note the following limitations of the CORBA IDL code generator. They are described in detail in the following chapter.</B.BODY
><LT.LIST.TEXT>Attributes must have either their Read Access or Write Access property set to Public to be placed in the generated CORBA IDL file. (Class and instance attributes are treated the same way.)</LT.LIST.TEXT
><LT.LIST.TEXT>Only operations with a value of Public for their Method Access property are represented in the generated CORBA IDL file. (Class and instance operators are treated the same way.) Constructors are not represented in CORBA IDL, so they are ignored.</LT.LIST.TEXT
><LT.LIST.TEXT>Although any enumerable type is allowed for the discriminator in CORBA IDL, ObjectTeam forces the discriminator to be of type long. There is no default case.</LT.LIST.TEXT
><LT.LIST.TEXT>Although you can specify an optional second argument to indicate the sequence’s size in CORBA IDL, there is no way to specify it in ObjectTeam. </LT.LIST.TEXT
><RBW-TEXTFLD TYPE="text">Code Generation Guide for Corba</RBW-TEXTFLD
></RBW-SYSOBJ
></A.APPENDIX.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Corba code generation properties</L.LABEL
><B.BODY>The following table lists the properties that effect Corba IDL code generation. These are available in the CD in the Object Design phase.</B.BODY
><CHAPTERNONUM><CN.CHAPTER.NOX23>About This Manual<RBW-SYSOBJ TYPE="MIFmarker"><RBW-DATAFLD TYPE="number">0</RBW-DATAFLD
><RBW-TEXTFLD TYPE="text">Code Generation Guide for C++</RBW-TEXTFLD
></RBW-SYSOBJ
></CN.CHAPTER.NOX23
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>About this manual</L.LABEL
><B.BODY>ObjectTeam provides code generation tools that enable you to generate object&truehy;oriented code for a range of object&truehy;oriented programming languages. This guide focuses on Delphi as target language. </B.BODY
><B.BODY>This manual explains the following things:</B.BODY
><RBW-PARABODY>How you can customize the default code generation process</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisites</L.LABEL
><B.BODY>This book assumes a basic knowledge of ObjectTeam, including familiarity with the information provided in the <CX5FX5FTITLE><CX5FX5FTITLE>ObjectTeam Getting Started</CX5FX5FTITLE
></CX5FX5FTITLE
> and <CX5FX5FTITLE><CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
></CX5FX5FTITLE
>. </B.BODY
><B.BODY>Furthermore, knowledge of Delphi is necessary to understand the Delphi constructions generated from the CDs. You also need this knowledge to complete the generated source files.</B.BODY
><B.BODY>If you plan to customize the default code generation process, you should be familiar with Tcl and the object&truehy;oriented extensions to Tcl supplied with ObjectTeam. For details on Object Tcl, refer to the <CX5FX5FTITLE><CX5FX5FTITLE>ObjectTeam Programming Interface Guide</CX5FX5FTITLE
> provides the menu items, the properties and the Tcl code required to use the Delphi Code Generator. Therefore, before moving to the Object Design phase, make sure this module is active.</B.BODY
><B.BODY>You can check if a module is active on a particular Browser level by selecting Utilities | Show Active Modules on that level.</B.BODY
> for details on how to activate a module.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Object Design and Implementation</L.LABEL
><B.BODY>This chapter describes the tasks of the Object Design phase. <RBW-XREF REFID="27382" TYPE="XREF-TEXTCOPY">Chapter 2, Generating Code</RBW-XREF
>, describes the tasks of the Implementation phase. You work iteratively in these two phases to generate code and complete your application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose of object design</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="Object Design" TERM2="activities in this phase"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Object Design" TERM2="development phase in ObjectTeam project"></RBW-IDXTERM
>In ObjectTeam, the CDs (and the objects defined in the CDs) provide all the source data needed for code generation. The goal of object design is to add to the CDs all the data required for successful code generation. For example, you add properties (such as the Attribute Access property, which establishes read/write access to an attribute) and incorporate language&truehy;specific syntax (such as data type specifications for attributes and the arguments of operations).</B.BODY
><B.BODY>You might also add data to diagrams other than CDs. The code generator does not use oter diagrams, but they are useful for describing the behavior of classes, their attributes and operations.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="23235" TYPE="XREF-TEXTCOPY">Refining the Class Diagrams&rbwtab;1–3</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="11520" TYPE="XREF-TEXTCOPY">Hints and Tips for Effective Code Generation&rbwtab;1–6</RBW-XREF
>Introduction<RBW-IDXTERM TERM1="Class Association Diagram"></RBW-IDXTERM
></L.LABEL
><B.BODY>The CDs and the objects defined in the CDs provide all the source data needed for code generation. <RBW-IDXTERM TERM1="Class Association Model"></RBW-IDXTERM
>These diagrams distinguish the classes in a system and describe their identities and their features. In the Object Design phase, you must add to the CDs sufficient detail for successful code generation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using data from diagrams other than CDs</L.LABEL
><B.BODY>Diagrams other than the CDs are not used as input for code generation. However, they contain valuable information that can help you to complete and verify the CDs. The following table summarizes how you can use these other diagrams to help you find important objects that are not yet in the CDs.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>STD state names (enumerated list as an attribute value)</CELLBODY
><CELLBODY>STD condition on an event</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Classes</L.LABEL
><B.BODY>When you work on CDs, you focus on the implementation of classes. The CD must include all classes and the associations (and inheritance) between classes. In the Object Design phase, you may introduce new classes to ease implementation and improve performance.</B.BODY
><B.BODY>You must include all attributes and operations for each class. The attributes of a class map to the attributes of the class type. The operations of the class map to functions and procedures of the class type. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>External classes</L.LABEL
><B.BODY>A class must have at least one attribute or one operation to generate code. Classes that have no attributes or operations are translated as external classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Associations</L.LABEL
><B.BODY>You must define the associations between all classes, including any constraints.</B.BODY
><B.BODY>Role names must also be defined. Every association needs at least one role name. Every mandatory association must have a role name. Without a role name, you cannot use the association.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role names in Analysis and System Design</SL.SUBLABEL
><B.BODY>In the Analysis and System Design phases, role names distinguish a class by showing the role the class is playing in a relationship with another class. Each role name defines the role of the class within the context of a single association. It also indicates the use and direction of the association toward the class that plays a role. For example, a manager can be both the boss of a coworker and an employee of a company.</B.BODY
>Role names in Object Design and Implementation</SL.SUBLABEL
><BI.BODY.INTRO>In the Object Design and Implementation phases, the use of role names is extended. The code generator creates access methods for an association if the class at the far end has a role name for the association. In the previous example, the code generated for Coworker includes access methods for Manager; the code generated for Manager does not include access methods for Coworker.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attributes</L.LABEL
><B.BODY>You must specify each attribute completely, including its data type. The way to specify a data type for an attribute is to include the type in the class symbol, for example:</B.BODY
><B.BODY>Data types of attributes and arguments can be standard ObjectTeam types, standard types for your target language, or class types and derived types. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Operations</L.LABEL
><BI.BODY.INTRO>You must specify each operation completely. This includes specifying such aspects as:</BI.BODY.INTRO
><RBW-PARABODY>Any parameters, as well as their data types</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Properties</L.LABEL
><BI.BODY.INTRO><RBW-IDXTERM TERM1="property" TERM2="using - to specify implementation details"></RBW-IDXTERM
>In the Object Design phase, a variety of properties allow you to specify many implementation details. <RBW-IDXTERM TERM1="property" TERM2="using - to specify implementation details"></RBW-IDXTERM
>These details are incorporated in the final code.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Checking</L.LABEL
><B.BODY>The last activity in object design is to use Check | Global Model to check the CDs. The CDs must be error&truehy;free before they can be used for code generation. See the <CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for more information about the Check utility.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</L.LABEL
><B.BODY><RBW-XREF REFID="33269" TYPE="XREF-TEXTCOPY">Chapter 3, Mapping Classes to Units</RBW-XREF
>, and <RBW-XREF REFID="20051" TYPE="XREF-TEXTCOPY">Chapter 4, Modeling Forms and Data Modules</RBW-XREF
>, describe how the ObjectTeam model is translated into code. You can use this information to help you complete the CDs in the Object Design phase.</B.BODY
>Hints and Tips for Effective Code Generation</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Following are a few tips for effective code generation. It may be helpful to be aware of these items as you prepare for code generation, and then again as you generate and regenerate your source files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Understanding the translations</L.LABEL
><B.BODY>Before generating code, read through this guide. It contains detailed information about the data that you must include in your CDs for successful code generation. It also explains how the code generator translates the ObjectTeam model into source code files, what changes you can make to the source code files, and how to regenerate them without losing your changes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Naming conventions</L.LABEL
><B.BODY>Agree upon and follow a naming convention for projects, configurations, systems, classes, special characters, and so on. In addition, bear in mind that spaces between words (in class names, for instance) are deleted by ObjectTeam code generators.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing code generation</L.LABEL
><B.BODY>The code generators execute Tcl scripts that translate a model into source code. You can modify these scripts or create your own.. Always use caution when customizing or creating scripts; such scripts are not supported.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using multiple languages in a single application</L.LABEL
><B.BODY>Each ObjectTeam code generator is designed to generate code for one language. You can create an application that uses multiple languages by using different code generators to generate code for different systems; however, the generated code is not integrated across systems. </B.BODY
><B.BODY>The ObjectTeam code generators are not designed to provide language integration. To build an application that uses multiple languages, you must do the following: </B.BODY
>When you create a separate ObjectTeam system for each language&truehy;specific subsystem, be sure to define your classes in the appropriate system. When ObjectTeam generates code for the current system, it generates code for the classes that are defined in that system. It does not generate code for classes referenced, but not defined in, the current system; such classes are treated as external classes.</N.NOTE
>Typically, the ultimate goal of modeling an application is to produce code that implements the application. In ObjectTeam, you can generate a significant portion of the code automatically, then complete the code by adding the details that are not specified in the model.</B.BODY
><RBW-PARABODY>Only the CDs (and the objects defined in the CDs) are used for code generation. Therefore, before code generation, it is critical that the CDs be fully defined, as described in <RBW-XREF REFID="30937" TYPE="XREF-TEXTCOPY">Chapter 1, Preparing Your ObjectTeam Model for Code Generation</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Steps in code generation</L.LABEL
><B.BODY>The following table provides an overview of the code generation process. This chapter describes each step in greater detail.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Configure the Delphi environment, copying required source files from the ObjectTeam installation directories to the appropriate user environment directories.</CELLBODY
> System level in the Implementation phase is fundamentally different than System level in other phases. The System files in the Implementation phase are source files, not diagram files.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Edit the source files in Delphi or in ObjectTeam. ObjectTeam generates a large portion of your application code, but not all of it. In this step, you finish writing the application code.<RBW-IDXTERM TERM1="code regeneration"></RBW-IDXTERM
><CELLBODY>Changes you make to the source files are not lost. When you regenerate the source files, the code generator recognizes your changes and transfers them to the newly generated files. </CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>In the Delphi environment, test the application. If necessary, correct the generated source files, the ObjectTeam model, or both.</CELLBODY
><B.BODY>You use ObjectTeam to model classes and forms, as well as the associations among them. From that ObjectTeam model, you generate Delphi unit, form, data module, and project files. In Delphi, you open the project, complete the application, and test it.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>OOPL Model</L.LABEL
><B.BODY>When you generate code, ObjectTeam converts the CDs and CDMs of the Object Design phase into an intermediate model: the OOPL Model. The Delphi code generator then generates the Delphi source files based on the OOPL Model.</B.BODY
> activates other Tcl scripts that contain Tcl procedures to retrieve information from internal models, format it and write it to Delphi files.</B.BODY
><B.BODY>The default <RBW-IDXTERM TERM1="Tcl" TERM2="script files used for code generation"></RBW-IDXTERM
>Tcl scripts used to generate Delphi files can be found in the directory <CX5FX5FFILE.NAME>modules</CX5FX5FFILE.NAME
><RBW-PARABODY>Make sure the Delphi <CX5FX5FFILE.NAME>bin</CX5FX5FFILE.NAME
> directory is in your path.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What happens in the Object Design phase</L.LABEL
><B.BODY>When you configure your Delphi environment in the Object Design phase, ObjectTeam adds a new system to this phase of your project: the DelphiVCL system. This system defines the most commonly used classes in the Delphi Visual Component Library (VCL). You use these classes to model forms and their components.</B.BODY
><B.BODY>For more information, see <RBW-XREF REFID="20051" TYPE="XREF-TEXTCOPY">Chapter 4, Modeling Forms and Data Modules</RBW-XREF
>, and <RBW-XREF REFID="36394" TYPE="XREF-TEXTCOPY">Chapter 6, Editing the DelphiVCL System</RBW-XREF
>.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>If you skip this task</SL.SUBLABEL
><B.BODY>If you have no DelphiVCL system in the current Object Design phase, the ObjectTeam classes used for modeling Delphi forms are not defined. When you generate Delphi source files, forms and data modules are not generated. </B.BODY
><B.BODY>A form is generated for each ObjectTeam class that is a subclass of the TForm class. A data module is generated for each ObjectTeam class that is a subclass of the TDataModule class. The TForm and TDataModule classes are defined in the DelphiVCL system. If these classes are not defined, no forms or data modules are generated.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to configure the environment in Object Design</L.LABEL
><LR.LIST.RESULT>ObjectTeam creates the DelphiVCL system in the Object Design phase.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What happens in the Implementation phase</L.LABEL
><B.BODY>When you configure your Delphi environment in the Implementation phase, ObjectTeam copies the <CX5FX5FFILE.NAME>ClassDict.pas</CX5FX5FFILE.NAME
> file to the <CX5FX5FVARIABLE>user_environment\</CX5FX5FVARIABLE
>src directory, where <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
> is the file path for your generated files. For more information on the user environment, see the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
><B.BODY>The Delphi ClassDict class is automatically included in all generated Delphi projects. It is referenced in the Delphi code generated for qualified associations. For more information on how the ClassDict class is used, see <RBW-XREF REFID="24359" TYPE="XREF-TEXTCOPY">Mapping Qualified Associations</RBW-XREF
>.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>If you skip this task</SL.SUBLABEL
><B.BODY>If you have not configured your Delphi environment in the Implementation phase, when you compile the generated Delphi code, an error occurs because the ClassDict class is not available.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to configure the environment in Implementation</L.LABEL
><LR.LIST.RESULT>ObjectTeam copies the <CX5FX5FFILE.NAME>ClassDict.pas</CX5FX5FFILE.NAME
> file to the user_environment\<CX5FX5FFILE.NAME>src</CX5FX5FFILE.NAME
> directory.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Rename convert.exe to formconv.exe</L.LABEL
><B.BODY>In Delphi, forms and data modules can be stored as ASCII (<CX5FX5FFILE.NAME>.txt</CX5FX5FFILE.NAME
>) files or as Delphi form (<CX5FX5FFILE.NAME>.dfm</CX5FX5FFILE.NAME
>) files. The ObjectTeam code generator creates forms and data modules as ASCII (<CX5FX5FFILE.NAME>.txt</CX5FX5FFILE.NAME
>) files. To open the forms and data modules in Delphi, you must first convert the ASCII (<CX5FX5FFILE.NAME>.txt</CX5FX5FFILE.NAME
>) files to Delphi form (<CX5FX5FFILE.NAME>.dfm</CX5FX5FFILE.NAME
>) files.</B.BODY
><B.BODY>Delphi provides a conversion utility (<CX5FX5FFILE.NAME>convert.exe</CX5FX5FFILE.NAME
>) to convert between <CX5FX5FFILE.NAME>.txt</CX5FX5FFILE.NAME
> and <CX5FX5FFILE.NAME>.dfm</CX5FX5FFILE.NAME
> formats. In the Implementation phase of the Browser, two menu items (Delphi | Convert Text to Forms and Delphi | Convert Forms to Text) invoke the Delphi conversion utility.</B.BODY
><RBW-PARABODY>The ObjectTeam commands Delphi | Convert Text to Forms and Delphi | Convert Forms to Text invoke <CX5FX5FFILE.NAME>formconv.exe</CX5FX5FFILE.NAME
> instead of <CX5FX5FFILE.NAME>convert.exe</CX5FX5FFILE.NAME
>.</RBW-PARABODY
></LN.LIST.NUM
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>If you skip this task</SL.SUBLABEL
><B.BODY>If you do not rename the <CX5FX5FFILE.NAME>convert.exe</CX5FX5FFILE.NAME
> file, the ObjectTeam commands display an error message indicating that the <CX5FX5FFILE.NAME>formconv.exe</CX5FX5FFILE.NAME
> file cannot be found.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Add the Delphi bin directory to your path</L.LABEL
><B.BODY>In the Implementation phase of the Browser, the ObjectTeam commands Delphi | Run Delphi and Delphi | Run Delphi With Project start Delphi by invoking the Delphi executable. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>If you skip this task</SL.SUBLABEL
><B.BODY>If the Delphi <CX5FX5FFILE.NAME>bin</CX5FX5FFILE.NAME
> directory is not in your path, the ObjectTeam commands display an error message indicating that the Delphi executable cannot be found.</B.BODY
><B.BODY>When you generate source files, the code generator uses the CDs and CDMs that are in the Object Design phase to create Delphi source files in the Implementation phase. At System level of the Implementation phase, you can then refine the source code and complete the application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Implementation Phase is different</L.LABEL
><B.BODY>The System level of the Implementation phase is fundamentally different from System level of any other phase. In the Implementation phase, the System files are Delphi files. In other phases, the System files are ObjectTeam diagrams.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generate code on Phase or System level</L.LABEL
><B.BODY>You can generate code on the Implementation Phase level or on the System level of the Implementation phase.</B.BODY
><RBW-PARABODY>On the <CX5FX5FBULLET.EMPHASIS>Implementation Phase level</CX5FX5FBULLET.EMPHASIS
>, you can generate code for one or more systems. This creates a matching system in the Implementation Phase that contains the generated source files. To regenerate code for an existing system, use System level.</RBW-PARABODY
><RBW-PARABODY>On the <CX5FX5FBULLET.EMPHASIS>System level of the Implementation phase</CX5FX5FBULLET.EMPHASIS
>, you can (re)generate code for the entire system, or regenerate selected source files.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>Typically, you use Implementation Phase level to generate code for a system initially and System level to regenerate code subsequently.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to generate code on Implementation Phase level</L.LABEL
> to generate code for one or more systems in the Object Design phase. You can select only systems that do not yet exist in the Implementation phase.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>ObjectTeam opens a Monitor window for displaying log messages, then generates the source files.</LR.LIST.RESULT
> to (re)generate code for all classes that are defined in this system.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>ObjectTeam opens a Monitor window for displaying log messages, then generates the source files. </LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Location of the source files</L.LABEL
><B.BODY>The Delphi files are stored in the repository as external files. They are also written to the <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
> directory, where <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
> is the file path for your generated files. For more information on the user environment, see the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
><BI.BODY.INTRO>The following illustration shows how the source files appear in the Browser.</BI.BODY.INTRO
><RBW-IDXTERM TERM1="Update User Environment (Utilities menu)"></RBW-IDXTERM
>Update user environment</SL.SUBLABEL
><B.BODY>Utilities | Update User Environment synchronizes your user environment with the repository. </B.BODY
><B.BODY>This can be particularly useful if you are working on two machines, and the user environment of each is set to a local drive. When you move between machines, you can use Utilities | Update User Environment to update the local drive of the current machine.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated files</L.LABEL
><B.BODY>The Delphi code generator generates the following files:<RBW-IDXTERM TERM1="Visual Basic" TERM2="generating files"></RBW-IDXTERM
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>One per system. This is the Delphi project file, which lists all other files in the system.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>One for each ObjectTeam class that represents a Delphi class, form unit, or data module container. Each file contains the code generated for the attributes, operations, and associations of the class.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>One for each ObjectTeam class that represents a Delphi form unit or data module container. Each file contains the definition of the form or data module.</CELLBODY
><CELLBODY><CX5FX5FEMPHASIS>Note</CX5FX5FEMPHASIS
>: The code generator generates forms and data modules as ASCII (<CX5FX5FFILE.NAME>.txt</CX5FX5FFILE.NAME
>) files. To open these files in Delphi, you must convert them to Delphi form (<CX5FX5FFILE.NAME>.dfm</CX5FX5FFILE.NAME
>) files. See <RBW-XREF REFID="24431" TYPE="XREF-TEXTCOPY">Editing Generated Form (.txt/.dfm) Files</RBW-XREF
>Editing Generated Unit (.pas) Files</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This section describes the changes you can make to generated unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) files and how to edit the generated files.</B.BODY
><B.BODY>See <RBW-XREF REFID="24431" TYPE="XREF-TEXTCOPY">Editing Generated Form (.txt/.dfm) Files</RBW-XREF
> and <RBW-XREF REFID="24486" TYPE="XREF-TEXTCOPY">Editing Generated Project (.dpr) Files</RBW-XREF
> for information about editing other types of generated files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes to procedure bodies are preserved</L.LABEL
><B.BODY>The procedures in the generated Delphi unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) files reflect the information in the ObjectTeam model. They do not contain all of the code necessary for the application. Comments in the generated procedures indicate where you should add code to complete the application.</B.BODY
>A method is generated for each operation defined in an ObjectTeam class. You must add the code that implements the method. The body of each generated method contains the following comment. Add code below the comment.</RBW-PARABODY
></LB.LIST.BULLET
><EM.EXAMPLE.MONO>//Implement this function!</EM.EXAMPLE.MONO
><RBW-PARABODY>Most generated unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) files include constructor and destructor methods. The body of the generated constructor and destructor method might contain generated code, as well as the following comments. Optionally, add code between the comments.</RBW-PARABODY
></LB.LIST.BULLET
><EM.EXAMPLE.MONO>//Start user section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>//End user section</EM.EXAMPLE.MONO
><RBW-PARABODY>Other generated procedures (such as the Get, Set, Add and Remove methods that implement associations) contain generated code but no comments indicating where to add additional code. Changes you make to these procedures are lost when you regenerate the file.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes that change the model</L.LABEL
><B.BODY>If you make the following changes to unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) files, you must use round&truehy;trip engineering (see <RBW-XREF REFID="17037" TYPE="XREF-TEXTCOPY">Chapter 5, Reverse and Round&truehy;Trip Engineering</RBW-XREF
>) to update the matching attributes and operations in the ObjectTeam model <CX5FX5FEMPHASIS>before</CX5FX5FEMPHASIS
><RBW-PARABODY>Modify the header of a procedure</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Explanation</SL.SUBLABEL
><B.BODY>The code generator generates code based on the ObjectTeam model. If you do not update the model, the regenerated code reflects the model. Your changes are not preserved. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>You add a variable to a generated unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) file by editing the file. You do not add the matching attribute to the ObjectTeam model. When you regenerate the file, the code generator assumes that you deleted the matching attribute from the ObjectTeam model. This makes the Delphi variable obsolete, so ObjectTeam removes it from the generated source file.</B.BODY
><RBW-PARABODY>In the Information area, double&truehy;click on the source file that you want to edit, or select the source file and then select File | Edit.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam opens the file in your default text editor. When you save the file, ObjectTeam updates both the repository and the user environment.</LR.LIST.RESULT
> Select one or more of the generated <CX5FX5FFILE.NAME>.txt</CX5FX5FFILE.NAME
> files and then select Delphi | Convert Forms to Text | Selected.</LT.LIST.TEXT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Automatic conversion</L.LABEL
><B.BODY>To make <CX5FX5FFILE.NAME>.txt</CX5FX5FFILE.NAME
>/<CX5FX5FFILE.NAME>.dfm</CX5FX5FFILE.NAME
> conversion easier, Cayenne provides an automatic conversion option. When automatic conversion is enabled, ObjectTeam automatically converts between formats as follows:</B.BODY
><RBW-PARABODY>To disable automatic conversion, select Delphi | Auto Form Convert.</RBW-PARABODY
></P.PROCEDURE
><LRS.LIST.RESULT.SINGLE>The check mark disappears and automatic conversion is disabled.</LRS.LIST.RESULT.SINGLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to edit forms and data modules</L.LABEL
><B.BODY>Typically, you edit generated forms and data modules in Delphi, as described in <RBW-XREF REFID="35795" TYPE="XREF-TEXTCOPY">How to edit generated files in Delphi</RBW-XREF
>. Alternatively, you can edit the <CX5FX5FFILE.NAME>.txt</CX5FX5FFILE.NAME
> files in ObjectTeam, as described in <RBW-XREF REFID="26511" TYPE="XREF-TEXTCOPY">How to edit generated files in ObjectTeam</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes that are preserved</L.LABEL
><B.BODY>Most changes that you make to a form or data module, such as repositioning elements or changing their properties, are preserved when you regenerate the file. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes that change the model</L.LABEL
><B.BODY>If you add or remove elements from a generated form or data module, you must update the ObjectTeam model <CX5FX5FEMPHASIS>before</CX5FX5FEMPHASIS
> regenerating the files. You can use round&truehy;trip engineering (see <RBW-XREF REFID="17037" TYPE="XREF-TEXTCOPY">Chapter 5, Reverse and Round&truehy;Trip Engineering</RBW-XREF
>) to add elements to the ObjectTeam model. You cannot use it to delete elements from the model.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Explanation</SL.SUBLABEL
><B.BODY>The code generator generates code based on the ObjectTeam model. If you do not update the model, the regenerated code reflects the model. Your changes are not preserved. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>You add an element to a generated form. You do not add the matching class to the ObjectTeam model. When you regenerate the file, the code generator assumes that you deleted the matching class from the ObjectTeam model. This makes the Delphi element obsolete, so ObjectTeam removes it from the generated source file.</B.BODY
><B.BODY>This section describes how to edit generated project (<CX5FX5FFILE.NAME>.dpr</CX5FX5FFILE.NAME
>) files.</B.BODY
><B.BODY>See <RBW-XREF REFID="16756" TYPE="XREF-TEXTCOPY">Editing Generated Unit (.pas) Files</RBW-XREF
> and <RBW-XREF REFID="24431" TYPE="XREF-TEXTCOPY">Editing Generated Form (.txt/.dfm) Files</RBW-XREF
> for information about editing other types of generated files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Maintaining project files</L.LABEL
><B.BODY>Each ObjectTeam system maps to a Delphi project. When you generate code for a system, the code generator also generates a Delphi project file, <CX5FX5FVARIABLE>systemName</CX5FX5FVARIABLE
>.<CX5FX5FFILE.NAME>dpr</CX5FX5FFILE.NAME
>.</B.BODY
><B.BODY>If your Delphi project contains several ObjectTeam systems, you might find it easier to create and maintain a project file in Delphi, rather than using the generated project file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated project file</L.LABEL
><B.BODY>The code generator creates a project file by copying the <CX5FX5FFILE.NAME>default.dpr</CX5FX5FFILE.NAME
> customization file to the <CX5FX5FVARIABLE>systemName</CX5FX5FVARIABLE
>.dpr file and then updating the <CX5FX5FVARIABLE>systemName</CX5FX5FVARIABLE
>.dpr file. The generated project file contains:</B.BODY
><LT.LIST.TEXT>By default, the uses clause lists only the units generated from the current ObjectTeam system. If the current system references classes defined in other systems, you must add to the current project file the units generated from the other systems.</LT.LIST.TEXT
><RBW-PARABODY>The application initialize and run clauses</RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>In Delphi, by default, all forms are automatically created. In ObjectTeam, only the main form is automatically created. The main form is the form that maps to the ObjectTeam class whose Main Form class property is set, as described in described in <RBW-XREF REFID="17659" TYPE="XREF-TEXTCOPY">Editing Class Properties</RBW-XREF
>. You cannot compile or run a Delphi project that does not have a main form.</LT.LIST.TEXT
><LT.LIST.TEXT>This block contains the names of all units generated by the ObjectTeam code generator. It serves as a checklist for the code generator to remove obsolete units from the project.</LT.LIST.TEXT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to edit a project file</L.LABEL
><B.BODY>Typically, you edit a generated project file in Delphi, as described in <RBW-XREF REFID="35795" TYPE="XREF-TEXTCOPY">How to edit generated files in Delphi</RBW-XREF
>. Alternatively, you can edit the project file in ObjectTeam, as described in <RBW-XREF REFID="26511" TYPE="XREF-TEXTCOPY">How to edit generated files in ObjectTeam</RBW-XREF
>.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
><CX5FX5FFILE.NAME>default.dpr</CX5FX5FFILE.NAME
> file</SL.SUBLABEL
><B.BODY>You can edit the <CX5FX5FFILE.NAME>default.dpr</CX5FX5FFILE.NAME
> customization file, as described in <RBW-XREF REFID="10944" TYPE="XREF-TEXTCOPY">Editing the default.dpr Customization File</RBW-XREF
>, but it is rarely necessary.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes that are preserved</L.LABEL
><B.BODY>When you regenerate an existing project file, with the following exceptions, all changes are preserved.</B.BODY
>Editing the default.dpr Customization File</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><CX5FX5FFILE.NAME>default.dpr</CX5FX5FFILE.NAME
> customization file</L.LABEL
><B.BODY>When you install ObjectTeam, there is an <CX5FX5FFILE.NAME>default.dpr</CX5FX5FFILE.NAME
> customization file on Corporate level. You can edit the customization file on Corporate level, or create a new customization file on a lower level, as described in this section.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>For general information about customization files, see the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Levels of customization</L.LABEL
><B.BODY>From high to low, the levels for customization files are:</B.BODY
> customization file must be available when you generate the Delphi files. Therefore, creating this customization file at System level in a phase other than Implementation has no effect.</N2.NOTE.2
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Which customization file is used</L.LABEL
><B.BODY>If you have more than one <CX5FX5FFILE.NAME>default.dpr</CX5FX5FFILE.NAME
> customization file, the code generator uses the lowest&truehy;level customization file. For example, a System&truehy;level customization file is used before a Phase&truehy;level customization file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to create a new <CX5FX5FFILE.NAME>default.dpr</CX5FX5FFILE.NAME
><RBW-PARABODY>Move to the level on which you want to create the customization file. For example, to create a Project&truehy;level customization file, move to Project level.</RBW-PARABODY
>How to edit an <CX5FX5FFILE.NAME>default.dpr</CX5FX5FFILE.NAME
> file</L.LABEL
><B.BODY>Customization files, except those on Corporate level, are in the Cayenne repository. They are not available as files in the file system. Therefore, if you have an <CX5FX5FFILE.NAME>default.dpr</CX5FX5FFILE.NAME
> customization file and you want to modify it, use the following procedure.</B.BODY
><B.BODY>ObjectTeam supports incremental development. You can generate code from your models, edit that code, and regenerate the code without losing your changes. You can work with ObjectTeam models or Delphi source files, shifting your focus between the two as necessary. It is, however, important that you make changes where appropriate.</B.BODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Change the model</CX5FX5FBULLET.EMPHASIS
> when you are changing the structure of the model (for example, if you are changing the class hierarchy or class associations), or when you are making global changes to the code (for example, if you are changing the name of a class, attribute, or operation).</RBW-PARABODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Change the code</CX5FX5FBULLET.EMPHASIS
> when you are adding code that is not generated by ObjectTeam (for example, adding method bodies), or when you are making local changes to the code (for example, adding a missing variable, procedure, or form element).</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing the ObjectTeam model</L.LABEL
><B.BODY>The ObjectTeam model is always used as the source for generating the Delphi files. If you change the ObjectTeam model, you generally want to regenerate the Delphi files.</B.BODY
><B.BODY>If, in the model, you rename, delete, or change the declaration of an operation, the matching procedure in the generated file is no longer correct. ObjectTeam preserves the original method and you can choose whether to correct it, move it to another file, or delete it.</B.BODY
><RBW-PARABODY>When you rename or delete an operation, the code generator moves the original method to the end of the generated file and marks it as <CX5FX5FBULLET.EMPHASIS>OBSOLETE_CODE</CX5FX5FBULLET.EMPHASIS
><RBW-PARABODY>When you change the declaration of an operation, the code generator leaves the method in place, but marks the method body as <CX5FX5FBULLET.EMPHASIS>OLD_CODE</CX5FX5FBULLET.EMPHASIS
><EM.EXAMPLE.MONO> // !! Implement this method !!</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>[ text that you added to the method body ]</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>{$ELSE}</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> // !! Implement this method !!</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>{$ENDIF}</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>end;</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing generated files</L.LABEL
><B.BODY>The generated Delphi files are framework files that you need to complete. Comments in the file indicate where you should add code.</B.BODY
><B.BODY>Always edit the generated files in accordance with the guidelines described in <RBW-XREF REFID="16756" TYPE="XREF-TEXTCOPY">Editing Generated Unit (.pas) Files</RBW-XREF
>, <RBW-XREF REFID="24431" TYPE="XREF-TEXTCOPY">Editing Generated Form (.txt/.dfm) Files</RBW-XREF
>, and <RBW-XREF REFID="24486" TYPE="XREF-TEXTCOPY">Editing Generated Project (.dpr) Files</RBW-XREF
>. This ensures that your changes are preserved when you regenerate the Delphi files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Before you begin</L.LABEL
><B.BODY>Before you regenerate Delphi files:</B.BODY
><RBW-PARABODY>If necessary, update the ObjectTeam model to reflect changes that you have made to the generated files. See <RBW-XREF REFID="16756" TYPE="XREF-TEXTCOPY">Editing Generated Unit (.pas) Files</RBW-XREF
> and <RBW-XREF REFID="24431" TYPE="XREF-TEXTCOPY">Editing Generated Form (.txt/.dfm) Files</RBW-XREF
><RBW-PARABODY>This chapter describes the Delphi units generated by ObjectTeam. Unless otherwise noted, all of the information in this chapter applies to units, form units, and data module containers.</RBW-PARABODY
><RBW-PARABODY>Chapter 4, Modeling Forms and Data Modules, describes the forms and data modules generated by ObjectTeam.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Examples</L.LABEL
><B.BODY>For simplicity, the examples in this chapter generate units (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
> files) without forms or data modules.</B.BODY
><B.BODY>Similar code is generated for a unit that has an associated form or data module. The form or data module (<CX5FX5FFILE.NAME>.dfm</CX5FX5FFILE.NAME
> file) is generated in addition to the unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
> file). </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><B.BODY>By default, an ObjectTeam class maps to a Delphi class. Depending on the supertype of the ObjectTeam class, it can instead map to a TForm class, a TDataModule class, or a TComponent.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>DelphiVCL system</L.LABEL
><B.BODY>In ObjectTeam, the classes in the DelphiVCL system represent commonly used Delphi classes, such as TForm and TDataModule. You can indicate the type of Delphi object that you want to create by making your ObjectTeam class a subclass of a DelphiVCL class. For example, to model a form, you create an ObjectTeam class that is a subclass of the TForm class.</B.BODY
><B.BODY>The DelphiVCL system is added to the Object Design phase of your project when you configure your Delphi environment, as described in <RBW-XREF REFID="10153" TYPE="XREF-TEXTCOPY">Configuring Your Delphi Environment</RBW-XREF
>. You can add additional Delphi classes to the DelphiVCL system, as described in Chapter 6, Editing the Delphi VCL System.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="17092"></RBW-ANCHOR
>Delphi classes</L.LABEL
><B.BODY>An ObjectTeam class that is <CX5FX5FEMPHASIS>not</CX5FX5FEMPHASIS
> a subclass of the TComponent class maps to a Delphi class. The code generator creates a unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) file to implement the class. The generated file includes:</B.BODY
><RBW-PARABODY>Inheritance information (see <RBW-XREF REFID="40371" TYPE="XREF-TEXTCOPY">Mapping Inheritance</RBW-XREF
>)</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Delphi forms and data modules</L.LABEL
><B.BODY>An ObjectTeam class that is a subclass of the TForm class maps to a Delphi form unit. An ObjectTeam class that is a subclass of the TDataModule class maps to a Delphi data module container. The TForm and TDataModule classes are subclass of TComponent; all three classes are defined in the DelphiVCL system.</B.BODY
><B.BODY>To implement a form or data module, the code generator creates:</B.BODY
><RBW-PARABODY>A form (<CX5FX5FFILE.NAME>.txt</CX5FX5FFILE.NAME
>/<CX5FX5FFILE.NAME>.dfm</CX5FX5FFILE.NAME
>) file for the associated form or data module</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See Chapter 4, Modeling Forms and Data Modules.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="32628"></RBW-ANCHOR
>Delphi components</L.LABEL
><B.BODY>An ObjectTeam class that is a subclass of the TComponent class maps to a Delphi component. Many of the TComponent subclasses, such as TRadioButton and TListBox, are defined in the DelphiVCL system.</B.BODY
><B.BODY>Typically, a component is not generated as a separate class. Instead, the code generator defines the component in the <CX5FX5FFILE.NAME>.txt</CX5FX5FFILE.NAME
>/<CX5FX5FFILE.NAME>.dfm</CX5FX5FFILE.NAME
> file that defines the form or data module that contains the component. If you want to generate the component as a separate class, you can do so by setting the class property Component Class Declaration (see <RBW-XREF REFID="17659" TYPE="XREF-TEXTCOPY">Editing Class Properties</RBW-XREF
>).</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See Chapter 4, Modeling Forms and Data Modules.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Delphi type declarations</L.LABEL
><B.BODY>An ObjectTeam class can also map to a Delphi type declaration, as described in <RBW-XREF REFID="31687" TYPE="XREF-TEXTCOPY">Mapping Special Classes</RBW-XREF
>. In this case, the code generator creates unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) files that contain only the type declaration sections.</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="12004" TYPE="XREF-TEXTCOPY">Generating Class Constructors and Destructors&rbwtab;3–4</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="17659" TYPE="XREF-TEXTCOPY">Editing Class Properties&rbwtab;3–7</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="22880" TYPE="XREF-TEXTCOPY">Sample Unit Files&rbwtab;3–9</RBW-XREF
>Generating Class Constructors and Destructors</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Constructors and destructors</L.LABEL
><B.BODY>The Delphi code generator includes a constructor and destructor in each unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) file that implements a Delphi class.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>$create operation and constructor</L.LABEL
><B.BODY>ObjectTeam uses the $create operation of a class to determine whether to create a default constructor or a user&truehy;defined constructor.</B.BODY
>The name of the $create operation is case sensitive.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Default constructor</L.LABEL
><B.BODY>If the ObjectTeam class has no $create operation, or has a $create operation without parentheses or parameters, the code generator creates a default constructor named Create. ObjectTeam maintains the parameter list and body of a default constructor. Cayenne <CX5FX5FEMPHASIS>strongly</CX5FX5FEMPHASIS
> recommends that you use default constructors.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Parameter list</SL.SUBLABEL
><B.BODY>The parameter list of a default constructor contains the following:</B.BODY
><RBW-PARABODY>The association attribute of each association that has, at the far end, a multiplicity of exactly one and a role name.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Body</SL.SUBLABEL
><B.BODY>ObjectTeam uses the body of a default constructor to initialize and maintain variables as necessary. Comments in the body of the constructor indicate where you can additional code.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>User&truehy;defined constructors</L.LABEL
><B.BODY>If the ObjectTeam class has a $create operation that includes a parameter list, even an empty parameter list, the code generator creates a user&truehy;defined constructor named Create. You are responsible for maintaining the parameter list and body of a user&truehy;defined constructor.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The generated code that implements associations uses the constructor to initialize and maintain the association variables. If you use default constructors, ObjectTeam provides this code for you. If you use user&truehy;defined constructors, you must write it yourself.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Destructor</L.LABEL
><B.BODY>The code generator creates a default destructor named Destroy. ObjectTeam uses the body of the default destructor to destroy objects and reset variables as necessary. Comments in the body of the destructor indicate where you can additional code.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Multiple constructors and destructors</L.LABEL
><B.BODY>ObjectTeam generates one constructor and one destructor for each class. Delphi allows multiple constructors and destructors for each class. If you use Delphi to add additional constructors or destructors to the generated files, ObjectTeam preserves them when you regenerate the edited files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="26603"></RBW-ANCHOR
>Example</L.LABEL
><B.BODY>The following code excerpt shows the default constructor and destructor created for the Customer class. </B.BODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>If set, generates this ObjectTeam class as the main form for the Delphi project. Set this property for exactly one subclass of TForm or TDataModule.</CELLBODY
></ENTRY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Chapter 4, Modeling Forms and Data Modules</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Component Class Declaration</CELLBODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>If set, generates this component as a Delphi class; otherwise, defines the component in the <RBWAUTO-0004>.txt</RBWAUTO-0004
>/<RBWAUTO-0004>.dfm</RBWAUTO-0004
> file that defines the form or data module that contains the component. Applies only to subclasses of TComponent.</CELLBODY
></ENTRY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY>Chapter 4, Modeling Forms and Data Modules</CELLBODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Identifies the dynamic&truehy;linked library (DLL), if any, that contains this class.</CELLBODY
><B.BODY>When one unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
> file) references another, the name of the referenced unit must appear in the <CX5FX5FPROCEDURE.NAME>uses</CX5FX5FPROCEDURE.NAME
> clause of the referencing unit. The Library Unit property of the referenced class specifies the unit name that is added to the <CX5FX5FPROCEDURE.NAME>uses</CX5FX5FPROCEDURE.NAME
> clause of the referencing unit. By default, Library Unit is None and the name added to the <CX5FX5FPROCEDURE.NAME>uses</CX5FX5FPROCEDURE.NAME
> clause is <CX5FX5FVARIABLE>referenced&truehy;classname</CX5FX5FVARIABLE
>Unit.</B.BODY
><B.BODY>The Library Unit property is most often used when you are adding classes to the DelphiVCL system. See Chapter 6, Editing the Delphi VCL System.</B.BODY
><B.BODY>This section shows the complete unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) file generated for a Delphi unit and for a form unit. For an example of a unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) file generated for a Delphi type declaration, see <RBW-XREF REFID="31687" TYPE="XREF-TEXTCOPY">Mapping Special Classes</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class unit</L.LABEL
><B.BODY>The following illustration shows an ObjectTeam class that represents a Delphi class. The generated unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
><B.BODY>The following illustration shows an ObjectTeam class that represents a Delphi form. The generated unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) file follows the illustration. For an example of the associated form (<CX5FX5FFILE.NAME>.txt</CX5FX5FFILE.NAME
>/<CX5FX5FFILE.NAME>.dfm</CX5FX5FFILE.NAME
>) file, see Chapter 4, Modeling Forms and Data Modules.</B.BODY
><B.BODY>The generated unit for the form is almost identical to the generated unit for the class. Bold text highlights where the generated form unit is different.</B.BODY
><RBW-PARABODY>* indicates a key attribute. A key attribute maps to a private variable. It is included in the parameter list of the default constructor. </RBW-PARABODY
><RBW-PARABODY>/ indicates a derived attribute. Delphi does not support derived attributes; therefore, the code generator ignores this indicator.<RBW-IDXTERM TERM1="derived attribute"></RBW-IDXTERM
> must be a standard type or the name of another class, as described in <RBW-XREF REFID="26856" TYPE="XREF-TEXTCOPY">Specifying Attribute Data Types</RBW-XREF
>, if specified, is an initial value that is assigned to the variable in the default constructor.<RBW-IDXTERM TERM1="attribute" TERM2="default value"></RBW-IDXTERM
><RBW-IDXTERM TERM1="default value, for attribute"></RBW-IDXTERM
><RBW-IDXTERM TERM1="initial value, for attribute"></RBW-IDXTERM
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies a type modifier for the variable in a typedef class. Applies only to the attribute in a typedef class. </CELLBODY
></ENTRY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="31687" TYPE="XREF-TEXTCOPY">Mapping Special Classes</RBW-XREF
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="26856" TYPE="XREF-TEXTCOPY">Specifying Attribute Data Types&rbwtab;3–17</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="40016" TYPE="XREF-TEXTCOPY">Specifying Visibility of a Variable&rbwtab;3–18</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="16861" TYPE="XREF-TEXTCOPY">Specifying Access Methods for Variables&rbwtab;3–19</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="23727" TYPE="XREF-TEXTCOPY">Mapping Attributes to Delphi Properties&rbwtab;3–21</RBW-XREF
>Specify the data type of an attribute with either a standard data type, such as integer, or the name of another class. For example:</B.BODY
><EM.EXAMPLE.MONO>attr:integer</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Standard data types</L.LABEL
><B.BODY>The standard data types are defined by the <CX5FX5FFILE.NAME><RBW-IDXTERM TERM1="stand_types customization file"></RBW-IDXTERM
>etc\stand_types</CX5FX5FFILE.NAME
> customization file in the Delphi module directory. These are the data types that are valid in the Object Design phase.</B.BODY
><B.BODY>The translation between standard data types and Delphi data types is defined by the <CX5FX5FFILE.NAME><RBW-IDXTERM TERM1="lang_types customization file"></RBW-IDXTERM
>etc\lang_types</CX5FX5FFILE.NAME
> customization file. These are the translations used by the Delphi code generator.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing the standard data types</L.LABEL
><B.BODY>You can add additional data types to the list of standard types by editing the <CX5FX5FFILE.NAME>stand_types</CX5FX5FFILE.NAME
> customization file. If you add additional standard types, you must also provide translations for those data types by editing the <CX5FX5FFILE.NAME>lang_types</CX5FX5FFILE.NAME
> customization file.</B.BODY
><B.BODY>By default, the <CX5FX5FFILE.NAME>stand_types</CX5FX5FFILE.NAME
> and <CX5FX5FFILE.NAME>lang_types</CX5FX5FFILE.NAME
> customization files are defined on Corporate level. You can edit the customization files at Corporate level, or create and edit them at a lower level, such as Project level. The customization files at the lower level override the customization files at the higher level.</B.BODY
> describes how to create and edit customization files. The <CX5FX5FFILE.NAME>stand_types</CX5FX5FFILE.NAME
> and <CX5FX5FFILE.NAME>lang_types</CX5FX5FFILE.NAME
> customization files are ASCII files that can be edited using any text editor.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Data structures and pointers</L.LABEL
><B.BODY>To generate data structures and pointers, use special classes. See <RBW-XREF REFID="31687" TYPE="XREF-TEXTCOPY">Mapping Special Classes</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Arrays</L.LABEL
><B.BODY>The Delphi code generator does not support specification of arrays in ObjectTeam; that is, you cannot use the ObjectTeam notation attrName:type[x]. However, variant variables can hold arrays in Delphi. To create a variable that can hold an array, use the Variant data type:</B.BODY
>Specifying Visibility of a Variable</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attribute Visibility property</L.LABEL
><B.BODY>Use the Attribute Visibility property on the Misc tab of the Edit Properties dialog box to specify the visibility of the generated variable.</B.BODY
>. The variable has no special restrictions on its visibility. Delphi generates runtime type information for published components, but not for public components. See the Delphi documentation for more information.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The code excerpt below shows the variable declarations generated for the customerID and name attributes of the Customer class. The Attribute Visibility property is set to Public for customerID and to Private (the default) for name.</B.BODY
><EWM.EXAMPLEW.MONO>...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>type</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> ...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> private</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> // User defined attributes</EWM.EXAMPLEW.MONO
> is a special type of procedure that gets (reads) and sets (writes) an attribute’s value. Use the Attribute Access group box on the Misc tab of the Edit Properties dialog box to specify the visibility of the generated methods and to prevent access methods from being generated.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Read and Write fields</L.LABEL
><B.BODY>The Attribute Access group box allows you to specify the access methods for both read and write. The setting you specify in the Read field affects the Get attribute access method. The setting you specify in the Write field affects the Set attribute access method.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Access functions</L.LABEL
><B.BODY>The following values are allowed for both Read and Write fields. You can enter the same or different values in the two fields.</B.BODY
><B.BODY>The code excerpt below shows the access methods generated for the name attribute of the Customer class. In the Attribute Access group box, the Write field is specified as Private and the Read field is specified as Public (the default).</B.BODY
>Mapping Attributes to Delphi Properties</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Two attributes to model a Delphi property</L.LABEL
><B.BODY>In Delphi, you typically store property data in a class field. Therefore, in ObjectTeam, you generally model a property using two attributes:</B.BODY
><RBW-PARABODY>A method name in <CX5FX5FPROCEDURE.NAME>read</CX5FX5FPROCEDURE.NAME
> or <CX5FX5FPROCEDURE.NAME>write</CX5FX5FPROCEDURE.NAME
> specifier indicates that you access the property value using the specified method. The specified methods are generally private or public, virtual methods.</RBW-PARABODY
><RBW-PARABODY>The read method must be a function that takes no parameters (or a single index value parameter) and returns a value of the same type as the property.</RBW-PARABODY
><RBW-PARABODY>The write method must be a procedure that takes a single parameter of the same type as the property (and, optionally, a second index value parameter).</RBW-PARABODY
></LB2.LIST.BULLET.2
><B.BODY>See the Delphi documentation for more information about reading and writing property values.</B.BODY
><RBW-PARABODY>Edit the attribute properties of the attribute that represents the Delphi property. Use the Property check box on the Property tab of the Edit Properties dialog box to specify that the attribute maps to a Delphi property. Use the remaining properties on the Property tab to specify additional information.<RBWAUTO-0025></RBWAUTO-0025
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Field or method for the <CX5FX5FBULLET.EMPHASIS>read</CX5FX5FBULLET.EMPHASIS
> specifier of the property declaration. Specify either the attribute that represents the class field that holds the property value or the operation that represents the read method.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Field or method for the <CX5FX5FBULLET.EMPHASIS>write</CX5FX5FBULLET.EMPHASIS
> specifier of the property declaration. Specify either the attribute that represents the class field that holds the property value or the operation that represents the write method.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Index specifier that is passed to the read and write property methods. Use index specifiers to create a read or write method that is shared by several properties. For more information, see the Delphi documentation.</CELLBODY
><RBW-PARABODY>Edit the attribute properties of the attribute that represents the class field that stores property value. On the Misc tab, set the Read and Write fields in the Attribute Access group box to None. This prevents ObjectTeam from generating read and write access methods for this attribute.</RBW-PARABODY
><RBW-PARABODY>Edit the operation properties of the operations that represent the read and write methods. Set the Method Visibility property to Private or Protected. Set the Method Modifier property to Virtual.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Complete the read and write methods</L.LABEL
><B.BODY>After generating the Delphi unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) files, you must complete the read and write methods by filling in the method bodies.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The following example models a count property for the Book class. The class field that stores the property value is FCount. The property is read directly. It is written using the SetCount write method.</B.BODY
><B.BODY>Following are excerpts from the generated code. The highlighted text in the write method shows the text that you might add to complete the method.</B.BODY
><EWM.EXAMPLEW.MONO>type</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> Book = class</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> private</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> // User defined attributes</EWM.EXAMPLEW.MONO
><RBW-PARABODY>If you select the Event property, the operation maps to an <CX5FX5FBULLET.EMPHASIS>event handler</CX5FX5FBULLET.EMPHASIS
>. An ObjectTeam class can contain events if the class represents a Delphi form, data module, or component; that is, if it is a subclass of TComponent.</RBW-PARABODY
><RBW-PARABODY>no return type, the operation maps to a <CX5FX5FBULLET.EMPHASIS>procedure</CX5FX5FBULLET.EMPHASIS
>.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LT.LIST.TEXT>An ObjectTeam class can contain functions and procedures if the class generates a unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) file. An ObjectTeam class that represents a component does not generate a unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) file unless you select the Component Class Declaration property (see <RBW-XREF REFID="17659" TYPE="XREF-TEXTCOPY">Editing Class Properties</RBW-XREF
>).</LT.LIST.TEXT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Operation syntax</L.LABEL
><B.BODY>Use the following syntax to specify operations for an ObjectTeam class:</B.BODY
>Delphi does not support overloaded methods. If an ObjectTeam class has two operations with the same name, the code generator displays an error message.</T2.TIP.2
> of a parameter must be either a standard type or a class modeled in the CD. Specifying the data type of a parameter is similar to specifying the data type of an attribute (see <RBW-XREF REFID="26856" TYPE="XREF-TEXTCOPY">Specifying Attribute Data Types</RBW-XREF
> is either a standard type or a class modeled in the CD. Specifying the return type for a procedure is similar to specifying the data type of an attribute (see <RBW-XREF REFID="26856" TYPE="XREF-TEXTCOPY">Specifying Attribute Data Types</RBW-XREF
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies attribute visibility (public, private, protected, published). Ignored for class operations; class operations are always published.</CELLBODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the dispatch mechanism for the method (static, vitural, dynamic, abstract).</CELLBODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the calling convention for the method (register, pascal, cdecl, stdcall, safecall).</CELLBODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the type of array parameter (open&truehy;array, variant open&truehy;array).</CELLBODY
><B.BODY>The Delphi code generator generates the following special procedures, which you do not have to specify as operations in an ObjectTeam class:</B.BODY
><RBW-PARABODY>Class constructors and destructors, as described in <RBW-XREF REFID="12004" TYPE="XREF-TEXTCOPY">Generating Class Constructors and Destructors</RBW-XREF
>. Class constructors can be specified as $create operations on an ObjectTeam class, but do not have to be.</RBW-PARABODY
><RBW-PARABODY>Attribute access methods, as described in <RBW-XREF REFID="16861" TYPE="XREF-TEXTCOPY">Specifying Access Methods for Variables</RBW-XREF
>. Do not specify access methods as operations on an ObjectTeam class.</RBW-PARABODY
><RBW-PARABODY>Association access methods, as described in <RBW-XREF REFID="20174" TYPE="XREF-TEXTCOPY">Mapping Unidirectional and Bidirectional Associations</RBW-XREF
>. Do not specify access methods as operations on an ObjectTeam class.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section contains the following topics:</B.BODY
>. The operation has no special restrictions on its visibility. Delphi generates runtime type information for published components, but not for public components. See the Delphi documentation for more information.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Special characters</L.LABEL
><B.BODY>You can display the visibility of methods in your diagram by checking Options | Show Visibility in the Class Diagram Editor. Method names will then be displayed with the following leading characters indicating the method’s access level:</B.BODY
>No leading character is displayed for methods with a visibility of <CX5FX5FBULLET.EMPHASIS>Published</CX5FX5FBULLET.EMPHASIS
>.</N.NOTE
><B.BODY>These special characters can also be used to <CX5FX5FEMPHASIS>set</CX5FX5FEMPHASIS
> the access level of methods. Typing a hatch sign (#) before a method name will set the access level of the method to Protected, for example. </B.BODY
>The special characters only work if the menu entry Options | Show Visibility in the Class Diagram Editor has been checked. Otherwise, the special characters will just be regarded as part of the method name.</W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The code excerpt below shows the operation declarations generated for the checkCredit and printCustomer operations of the Customer class. The Method Visibility property for checkCredit is set to Private. The same property for printCustomer is set to Public (the default).</B.BODY
><EWM.EXAMPLEW.MONO>...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>type</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> private</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> // User defined methods</EWM.EXAMPLEW.MONO
> (None, the default). The compiler determines the exact address of the method and links the method at compile time. You cannot override static methods; if you declare a method in a derived class with the same name as a static method in the ancestor class, the new method replaces the inherited method.</RBW-PARABODY
>. The address of a virtual method is stored in the Virtual Method Table (VMT) of the owner object. The address of the method is found at runtime.</RBW-PARABODY
>. Similar to virtual methods. Dynamic methods use less memory because their addresses are not stored in the VMT; they are dispatched more slowly because the address is found at runtime by searching the inheritance tree.</RBW-PARABODY
><B.BODY>Use the Calling Convention property on the Misc tab of the Edit Properties dialog box to specify the calling convention for the method. The calling convention determines how parameters are passed to the method:</B.BODY
> (default). Parameters are passed left&truehy;to&truehy;right. The called method removes the parameters from the stack upon returning. This convention uses up to 3 registers to pass parameters; the remaining parameters are passed on the stack.</RBW-PARABODY
><B.BODY>Use the Parameter Passing and Type Modifier properties on the Misc tab of the Edit Properties dialog box for a parameter to specify the kind of parameter that you want to use.</B.BODY
> (default). Value parameters allow expressions to be passed into the method. Within the method, value parameters are similar to local variables.</RBW-PARABODY
>. Constant parameters allow expressions to be passed into the method. Within the method, constant parameters are similar to read&truehy;only local variables.</RBW-PARABODY
>. Type variant open&truehy;array parameters allow arrays of varying sizes and types to be passed into the method.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Examples</L.LABEL
><B.BODY>The following tables show how the Parameter Passing and Type Modifier properties effect the generated declaration for the following ObjectTeam operation:</B.BODY
><B.BODY>The Delphi code generator provides support for inheritance among ObjectTeam classes that represent class units, form units, and data module containers.</B.BODY
>In ObjectTeam, you can specify either disjoint or overlapping inheritance. The Delphi code generator does not distinguish between the two types of inheritance.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Multiple inheritance</L.LABEL
><B.BODY>Delphi does not support multiple inheritance; therefore, the code generator displays an error if you attempt to generate code for a class that has more than one parent.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The following code excerpt shows how the code generated for the Rectangle subclass references the Shape superclass.</B.BODY
><B.BODY>N&truehy;ary associations are ignored by the Delphi code generator. Code is generated for the classes involved, but no code is generated for the n&truehy;ary association.</B.BODY
>The Delphi code generator translates aggregations like associations, unless the aggregrations are being used to model forms or data module containers. See Chapter 4, Modeling Forms and Data Modules, for more information.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Ordered associations</L.LABEL
><B.BODY>The {ordered} indicator on an association is ignored by the Delphi code generator. In lists of associations generated by the Delphi code generator, new elements are always added to the front of the list.</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="20174" TYPE="XREF-TEXTCOPY">Mapping Unidirectional and Bidirectional Associations&rbwtab;3–38</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="39817" TYPE="XREF-TEXTCOPY">Mapping Associations Based on Multiplicity&rbwtab;3–43</RBW-XREF
>Mapping Unidirectional and Bidirectional Associations </SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This section describes how the Delphi code generator implements the following simple associations between the Customer class and the Book class.</B.BODY
>The direction of an association is defined by the role names on the association. A role name at the far end of the association indicates an association from the class at the near end to the class at the far end.</B.BODY
><B.BODY>If an association has a role name at only one end, it is a <CX5FX5FEMPHASIS>unidirectional</CX5FX5FEMPHASIS
> association (implemented in one direction). If an association has role names at both ends, it is a <CX5FX5FEMPHASIS>bidirectional</CX5FX5FEMPHASIS
> association (implemented in both directions).</B.BODY
>The Delphi code generator implements a unidirectional association by adding an <CX5FX5FEMPHASIS>association attribute</CX5FX5FEMPHASIS
> and a set of <CX5FX5FEMPHASIS>association methods</CX5FX5FEMPHASIS
> to the code generated for the class at the near end of the association. This allows the class at the near end of the association (Customer) to access the class at the far end (Book); the class at the far end of the association cannot access the class at the near end.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Mapping a bidirectional association</L.LABEL
><B.BODY>The Delphi code generator implements a bidirectional association by adding an <CX5FX5FEMPHASIS>association attribute</CX5FX5FEMPHASIS
> and a set of <CX5FX5FEMPHASIS>association methods</CX5FX5FEMPHASIS
> to the code generated for both classes. This allows each class to access the other. To ensure integrity of a bidirectional association, the update method for a bidirectional association always maintains the association in both directions.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example of a unidirectional association</L.LABEL
><B.BODY>Following is an excerpt from the code generated for the Customer class in the unidirectional association. Because this is a unidirectional association, the Book class does not contain any code related to the association.</B.BODY
><B.BODY>Following is an excerpt from the code generated for the Customer class in the bidirectional association. Because this is a bidirectional association, the Book class contains similar code.</B.BODY
><RBW-PARABODY>As in the previous example, the remove, set, and get methods update the association attribute Customer.possessionRef to reflect the association between the Customer and the Book.</RBW-PARABODY
><RBW-PARABODY>Because this is a bidirectional association, the remove and set methods <CX5FX5FEMPHASIS>also</CX5FX5FEMPHASIS
> update the complementary association between the Book and the Customer. To update the complementary association, the association methods defined in the Customer class use the association methods defined in the Book class.</RBW-PARABODY
><RBW-PARABODY>Because this is a bidirectional association, when a Customer is deleted, if the Customer is associated with a Book, the association between the Book and the Customer must also be deleted. The destructor for Customer removes that association.</RBW-PARABODY
>Mapping Associations Based on Multiplicity</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>The code generated for an association depends on the multiplicity of the association. This section shows an example of the code generated for each type of association. For simplicity, all of the associations shown in this section are unidirectional associations.</B.BODY
>The Delphi code generator does not support mandatory&truehy;mandatory bidirectional associations. Such associations cause a code generation error.</W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisite</L.LABEL
><B.BODY>This section assumes that you are familiar with the information in <RBW-XREF REFID="20174" TYPE="XREF-TEXTCOPY">Mapping Unidirectional and Bidirectional Associations</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="19832"></RBW-ANCHOR
>Zero or one</L.LABEL
><B.BODY>In the following example, each Customer can have zero or one Books:</B.BODY
><RBW-PARABODY>The set method creates an association between the Customer and a Book. A Customer can have at most one Book; therefore, if the Customer already has a Book, the set method replaces the old Book with the new one.</RBW-PARABODY
><RBW-PARABODY>The set method creates an association between the Customer and a Book. A Customer must have exactly one Book; therefore, the set method replaces the old Book with the new one.</RBW-PARABODY
><RBW-PARABODY>The association attribute, Customer.possessionRef, is public rather than private. See <RBW-XREF REFID="30500" TYPE="XREF-TEXTCOPY">Visibility of an association attribute</RBW-XREF
><RBW-PARABODY>The association attribute is a TList object, which allows the attribute to store and maintain the list of associated objects. The Customer class constructor creates the TList object; the class destructor destroys it.</RBW-PARABODY
><RBW-PARABODY>The add method adds an association to the set of associations. If the association is already in the set, the add method does nothing.</RBW-PARABODY
><RBW-PARABODY>The remove method removes an association from the set. If the association is not in the set, the remove method does nothing.</RBW-PARABODY
><BI.BODY.INTRO>In the following example, each Customer can have at most 10 Books. The Delphi code generator ignores the more specific value. The code generated for this association is the same as that shown above.</BI.BODY.INTRO
>The mapping of a qualified association, is similar to that of an association with multiplicity of many. For a qualified association, however, the qualifier (bookID, in the following example) is used to identify each association in the set of associations.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisite</L.LABEL
><B.BODY>This section assumes that you are familiar with the information in <RBW-XREF REFID="39817" TYPE="XREF-TEXTCOPY">Mapping Associations Based on Multiplicity</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Qualified association</L.LABEL
><B.BODY>This section describes how the Delphi code generator implements the following associations between the Customer class and the Book class. </B.BODY
><B.BODY>A qualified association must be a bidirectional association. The association can be retrieved from either class. The association is created, deleted, and updated from the qualified class (in this example, the Customer class).</B.BODY
><B.BODY>For a qualified association, the association attribute is a ClassDict object. The ClassDict class, which is supplied with the Delphi code generator, includes special methods for handling qualifiers. The association methods use the ClassDict methods to access the qualifier.</B.BODY
>ObjectTeam copies the ClassDict class to your user environment when you configure your Implementation environment, as described in <RBW-XREF REFID="40480" TYPE="XREF-TEXTCOPY">Configuring Your PowerBuilder Environment</RBW-XREF
>.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated Customer code</L.LABEL
><BI.BODY.INTRO>Following is an excerpt from the code generated for the Customer class shown above. Notice the following:</BI.BODY.INTRO
><RBW-PARABODY>The Customer class destructor removes all associations from Books to this Customer class, then deletes the ClassDict object that is the association attribute.</RBW-PARABODY
><RBW-PARABODY>Because this is a bidirectional association, the add and remove methods update both the Customer&truehy;Book and Book&truehy;Customer associations.</RBW-PARABODY
><RBW-PARABODY>The association attribute, Book.ownerRef, is public rather than private. See <RBW-XREF REFID="30500" TYPE="XREF-TEXTCOPY">Visibility of an association attribute</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
><EWM.EXAMPLEW.MONO>...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>type</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> Book = class</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> ...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> public</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> ...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> // Association attributes</EWM.EXAMPLEW.MONO
><B.BODY>During code generation, an association with an association class is transformed (internally only, the model is not changed). The generated code is then based on the transformed association. The transformation replaces the original association with associations from the association class to the two other classes.</B.BODY
><B.BODY>As with all associations, role names are required. If a role name is omitted, the association attributes and methods that would map to that role name are not generated.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>OMT notation and link attributes</L.LABEL
><B.BODY>If you are using OMT notation, you can use either an association class or link attributes. The code generated for a link attribute is similar to that generated for an association class.</B.BODY
><B.BODY>When ObjectTeam transforms a link attribute association, it creates a new class for the link attributes. The name of the new class is the name of the association. Therefore, an association that has a link attribute must have an association name.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated Purchase code</L.LABEL
><BI.BODY.INTRO>Following is the code generated for the Purchase class. The code reflects the transformed CD (<RBW-XREF REFID="19936" TYPE="XREF-TEXTCOPY">Association mapped as two associations</RBW-XREF
><RBW-PARABODY>The Purchase class constructor creates the two mandatory associations: Purchase&truehy;to&truehy;Customer and Purchase&truehy;to&truehy;Book. Because the associations are bidirectional, it also creates the complementary associations: Customer&truehy;to&truehy;Purchase and Book&truehy;to&truehy;Purchase.</RBW-PARABODY
><RBW-PARABODY>The Purchase class destructor removes the Customer&truehy;to&truehy;Purchase and Book&truehy;to&truehy;Purchase associations.</RBW-PARABODY
><RBW-PARABODY>Two set methods update the two mandatory associations: Purchase&truehy;to&truehy;Customer and Purchase&truehy;to&truehy;Book. Because the associations are bidirectional, they also update the complementary associations: Customer&truehy;to&truehy;Purchase and Book&truehy;to&truehy;Purchase.</RBW-PARABODY
><RBW-PARABODY>The association attributes, ownerRef and possessionRef, are public rather than private. See <RBW-XREF REFID="30500" TYPE="XREF-TEXTCOPY">Visibility of an association attribute</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
><EWM.EXAMPLEW.MONO>...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>type</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> ...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> public</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> ...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> // Association attributes</EWM.EXAMPLEW.MONO
><BI.BODY.INTRO>Following is the code generated for the Customer class. The code reflects the transformed CD (<RBW-XREF REFID="19936" TYPE="XREF-TEXTCOPY">Association mapped as two associations</RBW-XREF
><RBW-PARABODY>The Customer class constructor creates the TList object that is the association attribute for the many association: Customer&truehy;to&truehy;Purchase. </RBW-PARABODY
><RBW-PARABODY>The Customer class destructor destroys the TList object. Because of the mandatory relationship from Purchase to Customer, the Customer class destructor raises an error if a Purchase has an association with this Customer.</RBW-PARABODY
><RBW-PARABODY>The add method adds a Purchase to the set of associated Purchases. Because this is a bidirectional association, it also sets the complementary association: Purchase&truehy;to&truehy;Customer.</RBW-PARABODY
><RBW-PARABODY>The association attribute, Customer.purchaseofpossessionSet, is public rather than private. See <RBW-XREF REFID="30500" TYPE="XREF-TEXTCOPY">Visibility of an association attribute</RBW-XREF
><BI.BODY.INTRO>Following is the code generated for the Book class. The code reflects the transformed CD (<RBW-XREF REFID="19936" TYPE="XREF-TEXTCOPY">Association mapped as two associations</RBW-XREF
><RBW-PARABODY>Because of the mandatory relationship from Purchase to Book, the Book class destructor raises an error if a Purchase has an association with this Book.</RBW-PARABODY
><RBW-PARABODY>The association attribute, Book.purchaseofownerRef, is public rather than private. See <RBW-XREF REFID="30500" TYPE="XREF-TEXTCOPY">Visibility of an association attribute</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
><EWM.EXAMPLEW.MONO>...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>type</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> Book = class</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> ...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> public</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> ...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> // Association attributes</EWM.EXAMPLEW.MONO
>Specifying Association Properties</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Use the properties of an association to effect the visibility and data type of the generated association attribute, and the visibility of the generated association methods.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to edit association attribute properties<RBW-IDXTERM TERM1="Edit Properties (Item menu)" TERM2="for association"></RBW-IDXTERM
>For a qualified attribute, you can select either a role name or the qualifier. <RBW-XREF REFID="24359" TYPE="XREF-TEXTCOPY">Mapping Qualified Associations</RBW-XREF
> describes the qualifier properties.</N2.NOTE.2
><LR.LIST.RESULT>The association properties appear on the right side of the dialog box.</LR.LIST.RESULT
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies visibility of the association methods (public, private, protected, published).</CELLBODY
></ENTRY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="11796" TYPE="XREF-TEXTCOPY">Visibility of association methods</RBW-XREF
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the data type of the association attribute (pointer, object reference). Ignored for qualified associations and associations with multiplicity of many.</CELLBODY
></ENTRY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="33250" TYPE="XREF-TEXTCOPY">Data type of an association attribute</RBW-XREF
><B.BODY>By default, the code generator creates private association attributes. You can use the Association Access property to change the visibility of an association attribute. Changing the visibility of an association attribute is similar to changing the visibility of an attribute. See <RBW-XREF REFID="40016" TYPE="XREF-TEXTCOPY">Specifying Visibility of a Variable</RBW-XREF
>.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Public association attributes</SL.SUBLABEL
><B.BODY>In the following cases, the code generator ignores the Association Access property and creates public association attributes:</B.BODY
><B.BODY>In these cases, the current class does not include all the association methods; instead, the associated class updates the association attribute. The association attribute is public so that the associated class can update it.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="11796"></RBW-ANCHOR
>Visibility of association methods</L.LABEL
><B.BODY>By default, the code generator creates public association methods. You can use the Access Methods group box to specify the visibility of the generated methods and to prevent association methods from being generated. Changing the visibility of association methods is similar to changing the visibility of the access methods for an attribute. See <RBW-XREF REFID="16861" TYPE="XREF-TEXTCOPY">Specifying Access Methods for Variables</RBW-XREF
>.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Public association methods</SL.SUBLABEL
><B.BODY>The association methods for bidirectional associations must be public. Therefore, for bidirectional associations, the code generator ignores the Access Methods group box and creates publc association methods.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="33250"></RBW-ANCHOR
>Data type of an association attribute</L.LABEL
><B.BODY>For an association that has a maximum multiplicity of one, you can generate the association attribute as a Pointer (default) or as an instance of the associated class. Use the Association Implementation property to select the data type that you want to use.</B.BODY
><B.BODY>For an association with a multiplicity of many, the generated association attribute is a TList object (see <RBW-XREF REFID="39817" TYPE="XREF-TEXTCOPY">Mapping Associations Based on Multiplicity</RBW-XREF
>). The Association Implementation property of the association is ignored.</B.BODY
><B.BODY>For a qualified association, the generated association attribute is a ClassDict object (see <RBW-XREF REFID="24359" TYPE="XREF-TEXTCOPY">Mapping Qualified Associations</RBW-XREF
>). The Association Implementation property of the association is ignored.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>In the following example, the <RBWAUTO-0026>Association Implementation property</RBWAUTO-0026
> of the association is set to Object Reference. In code generated for the Customer class, the <RBWAUTO-0026>association attribute is a Book</RBWAUTO-0026
>. <RBWAUTO-0026><RBW-XREF REFID="19832" TYPE="XREF-TEXTCOPY">Zero or one</RBW-XREF
> shows the same example with the Association Implementation property</RBWAUTO-0026
> of the association set to Pointer (the default).</B.BODY
><RBW-PARABODY>Create an attribute to represent each field in the record.</RBW-PARABODY
></LN.LIST.NUM
><B.BODY>The class cannot have operations, associations, superclasses, or subclasses.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The following illustration shows the customerRecord class. The Class Type property is set to Record. The generated unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
><EWM.EXAMPLEW.MONO> // Start user include section</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> // End user include section</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>// Do not delete this line &truehy;&truehy; regeneration marker</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>end.</EWM.EXAMPLEW.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using the generated record</L.LABEL
><B.BODY>Typically, you use a generated record by creating a variable of that record type. The code generator automatically adds the unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) file for the record type declaration to the <CX5FX5FPROCEDURE.NAME>uses</CX5FX5FPROCEDURE.NAME
> clause of the referencing unit.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The following illustration shows a class that defines a customerRecord variable. An excerpt of the generated code follows the illustration.</B.BODY
><EWM.EXAMPLEW.MONO> // Start user include section</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> // End user include section</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>// Do not delete this line &truehy;&truehy; regeneration marker</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>end.</EWM.EXAMPLEW.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using the enumerated type</L.LABEL
><B.BODY>Typically, you use an enumerated type by creating a variable of that type. The code generator automatically adds the unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) file for the enumerated type to the uses clause of the referencing unit.</B.BODY
><RBW-PARABODY>For each member of the set, create a class attribute with data type enum.</RBW-PARABODY
></LN.LIST.NUM
><B.BODY>The class cannot have operations, associations, superclasses, or subclasses.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The following illustration shows the riskTolerance class. The Class Type property is set to Set. The generated unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
><EWM.EXAMPLEW.MONO> // Start user include section</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> // End user include section</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>// Do not delete this line &truehy;&truehy; regeneration marker</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>end.</EWM.EXAMPLEW.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using the generated set</L.LABEL
><B.BODY>Referencing a set is similar to referencing an enumerated type. You use a set by creating a variable of that type. The code generator automatically adds the unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) file for the set to the <CX5FX5FPROCEDURE.NAME>uses</CX5FX5FPROCEDURE.NAME
> clause of the referencing unit. See the example in <RBW-XREF REFID="34171" TYPE="XREF-TEXTCOPY">Enumerated Types</RBW-XREF
><RBW-PARABODY>Set both Attribute Access (Read and Write) fields to None. This prevents the code generator from generating the read and write access methods for the attribute.</RBW-PARABODY
>Pointer or File are provided in a drop&truehy;down list. You can enter any other modifier by typing a value into the Type Modifier field.</N2.NOTE.2
><B.BODY>The class cannot have other attibutes, operations, associations, superclasses, or subclasses.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class example</L.LABEL
><B.BODY>The following illustration shows a class that defines a pointer to a customerRecord. The Type Modifier property of the custPtr attribute is set to Pointer. The generated code follows the illustration.</B.BODY
><EWM.EXAMPLEW.MONO> // Start user include section</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> // End user include section</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>// Do not delete this line &truehy;&truehy; regeneration marker</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>end.</EWM.EXAMPLEW.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using the generated pointer</L.LABEL
><B.BODY>Typically, you use a generated pointer by creating a variable of that type. The code generator automatically adds the unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) file for the pointer type declaration to the <CX5FX5FPROCEDURE.NAME>uses</CX5FX5FPROCEDURE.NAME
>In this example, the pointer points to a record. The unit file that defines the record (customerRecordUnit) is <CX5FX5FEMPHASIS>not</CX5FX5FEMPHASIS
> automatically added to the <CX5FX5FPROCEDURE.NAME>uses</CX5FX5FPROCEDURE.NAME
> clause. You must add it to the user include section. In the following code excerpt, the bolded text was manually added to the generated code.</W.WARNING
><RBW-PARABODY>Create attributes and operations to represent the properties and methods of the interface. See <RBW-XREF REFID="23727" TYPE="XREF-TEXTCOPY">Mapping Attributes to Delphi Properties</RBW-XREF
> and <RBW-XREF REFID="37299" TYPE="XREF-TEXTCOPY">Mapping Operations</RBW-XREF
> for more information.</RBW-PARABODY
></LN.LIST.NUM
><B.BODY>The class cannot have associations, superclasses, or subclasses. All attributes of the class must represent properties.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The online help for Delphi 3 provides an example of mapping interface methods. The following illustration shows the ObjectTeam class that generates the IMalloc interface shown in that example. The properties are set as shown in the following table. The generated code follows the illustration.</B.BODY
>Forms and Data Modules<RBW-SYSOBJ TYPE="MIFmarker"><RBW-DATAFLD TYPE="number">0</RBW-DATAFLD
><RBW-TEXTFLD TYPE="text">Code Generation Guide for Delphi</RBW-TEXTFLD
></RBW-SYSOBJ
></C.CHAPTER.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Forms</L.LABEL
><B.BODY>A Delphi form is a Delphi unit that has an associated form (<CX5FX5FFILE.NAME>.txt</CX5FX5FFILE.NAME
>/<CX5FX5FFILE.NAME>.dfm</CX5FX5FFILE.NAME
> file). Forms can contain visual and nonvisual components. A form is a subclass of the VCL class TForm.</B.BODY
><B.BODY>This chapter describes how to model forms. It provides examples of CDs and the results produced when you generate Delphi files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Data module containers</L.LABEL
><B.BODY>A Delphi data module container is a Delphi class that has an associated data module (<CX5FX5FFILE.NAME>.txt</CX5FX5FFILE.NAME
>/<CX5FX5FFILE.NAME>.dfm</CX5FX5FFILE.NAME
> file). Data module containers can contain only nonvisual components.<RBWAUTO-0026> </RBWAUTO-0026
>A data module container is a subclass of the VCL class TDataModule.</B.BODY
><B.BODY>Data module containers and forms are modeled in the same way. This chapter focuses on modeling forms, but the information also applies to modeling data module containers.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attributes, operations, and associations</L.LABEL
><B.BODY>Forms and data module containers are Delphi classes. ObjectTeam classes that represent forms and data modules can, therefore, have attributes, operations, and associations. The code generated for these features is described in <RBW-XREF REFID="33269" TYPE="XREF-TEXTCOPY">Chapter 3, Mapping Classes to Units</RBW-XREF
>.</B.BODY
><B.BODY>For simplicity, the sample classes in this chapter have no attributes, operations, or associations (except those that are used to model the form).</B.BODY
> recommends that you follow the Delphi convention of beginning each class name with a capital T. This is mandatory for forms and data models.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisite</L.LABEL
><B.BODY>Before you can model forms and data module containers in ObjectTeam, you must add the DelphiVCL system to the Object Design phase of your project. This system defines ObjectTeam classes that represent the most commonly used classes in Delphi’s Visual Component Library (VCL).</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See <RBW-XREF REFID="10153" TYPE="XREF-TEXTCOPY">Configuring Your Delphi Environment</RBW-XREF
> and <RBW-XREF REFID="36394" TYPE="XREF-TEXTCOPY">Chapter 6, Editing the DelphiVCL System</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><B.BODY>This section describes the construction of the CD shown at the beginning of this section (see <RBW-XREF REFID="25036" TYPE="XREF-TEXTCOPY">page 4–3</RBW-XREF
>The folded classes in the CD (TImage, TGroupBox, TForm, TButton, and TLabel) are defined in the DelphiVCL system. Notice that every class used to model the form is a subclass of a class defined in the DelphiVCL system.</B.BODY
><B.BODY>You create a class to represent each component that you want to create. You specify the type of component that you want to create by making your class a subclass of the appropriate DelphiVCL class. For example:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Create the TConsole class to represent the form. Also, add the TForm class and make TConsole a subclass of TForm.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Set the Main Form property of the TConsole class. Optionally, add attributes and operations to the TConsole class.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Create the TControls class to represent the group box that contains the TV controls (the TV monitor and channel buttons). Also, add the TGroupBox class and make TControls a subclass of TGroupBox.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Create the TMonitor class to represent an image component that can be used as the TV screen. Add the TImage class and make TMonitor a subclass of TImage.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Create the TUpBtn and TDownBtn classes to represent the command buttons. Add the TButton class and make TUpBtn and TDownBtn subclasses of TButton.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Create the TChannel, TBrand, and TTime classes to represent the labels. Add the TLabel class and make TChannel, TBrand, and TTime subclasses of TLabel.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The TControls group box contains four components: TMonitor, TChannel, TUpBtn, and TDownBtn. It is an <CX5FX5FTERM>aggregation</CX5FX5FTERM
> of these components. Create the four relationships that define the aggregation. </CELLBODY
><CELLBODY>Each relationship must have a role name. The role name will be the component name in Delphi; for example, in Delphi, ChannelLbl will be the name of the TChannel component.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The TConsole form is an aggregation of three components: the TControls group box and the TBrand and TTime labels. Create the three relationships that define the aggregation.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Add Click events to the TUpBtn class and TDownBtn class. See <RBW-XREF REFID="15442" TYPE="XREF-TEXTCOPY">Adding Events</RBW-XREF
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>For each class that is not defined in the DelphiVCL system, select Item | Edit properties. If the Define item button is available, select it to define the class item. See <RBW-XREF REFID="36562" TYPE="XREF-TEXTCOPY">All classes must be defined items</RBW-XREF
> for more information.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Forms</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="form" TERM2="representing in ObjectTeam"></RBW-IDXTERM
>A class that represents a form is similar to a class that represents a class module. It can contain the following features:</B.BODY
><RBW-PARABODY>Associations to other classes that represent either forms or class modules, as described in <RBW-XREF REFID="21676" TYPE="XREF-TEXTCOPY">Mapping Associations</RBW-XREF
></RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Components</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="controls" TERM2="representing in ObjectTeam"></RBW-IDXTERM
>A class that represents a component is a special type of class.</B.BODY
><RBW-PARABODY>It should not have associations, other than the aggregations used to model the form. If specified, they will be ignored by the code generator (or cause errors).</RBW-PARABODY
><RBW-PARABODY>Each of its operations must represent an event, as described <RBW-XREF REFID="37299" TYPE="XREF-TEXTCOPY">Mapping Operations</RBW-XREF
> and <RBW-XREF REFID="15442" TYPE="XREF-TEXTCOPY">Adding Events</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="36562"></RBW-ANCHOR
>All classes must be defined items</L.LABEL
><B.BODY>ObjectTeam generates code for class items. It does not generate code for graphical elements that do not have associated class items.</B.BODY
><B.BODY>When you create a class, ObjectTeam creates a graphical element. When you perform one of the following actions, ObjectTeam creates a class item:</B.BODY
><B.BODY>Classes in the DelphiVCL system represent the VCL classes available in Delphi. The operations and operation parameters on the DelphiVCL classes represent the events and event parameters defined in the VCL classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to model the form</L.LABEL
><B.BODY>As described in <RBW-XREF REFID="42715" TYPE="XREF-TEXTCOPY">Modeling the Form</RBW-XREF
>, you model a form in ObjectTeam by creating a class to represent each form and component that you want to create. You specify the type of component that you want to create by making each class a subclass of the appropriate DelphiVCL class.</B.BODY
><RBW-PARABODY>To model an event for a form or component, add an operation to the ObjectTeam class that represents the form or component:</RBW-PARABODY
><RBW-PARABODY>Set the Event property of the operation.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>Use the following ObjectTeam operation to model the OnClick event. Remember to set the Event property of the operation.</B.BODY
><EM.EXAMPLE.MONO>Click()</EM.EXAMPLE.MONO
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Event parameters</SL.SUBLABEL
><B.BODY>Event parameters are defined on the VCL classes in the DelphiVCL system. By specifying an empty parameter list, you indicate that ObjectTeam should use the event parameters defined for the event in the DelphiVCL system. If you specify parameters, ObjectTeam uses the specified parameters rather than those defined in the DelphiVCL system.</B.BODY
><B.BODY>In ObjectTeam, you model the form content, not the form layout. When ObjectTeam generates a form for the first time, the form contains all the specified components, but only default property values. </B.BODY
>When you open the generated project in Delphi, the form appears with all its components stacked in the upper left corner, as shown below. To complete the form, reposition the components and specify property values for the form and component properties.</BI.BODY.INTRO
>The Name property defines the name of the form or component. This information is also stored in ObjectTeam; therefore, it is recommended that you not change the Name property.</N2.NOTE.2
><RBW-PARABODY>You can add components to a form; however, you must then use round&truehy;trip engineering to add the components to the ObjectTeam model <CX5FX5FEMPHASIS>before</CX5FX5FEMPHASIS
>If you delete components from a form, you must manually update the ObjectTeam module. Round&truehy;trip engineering does not delete the components for you.</N2.NOTE.2
><RBW-PARABODY>You can add new events; however, you must then use round&truehy;trip engineering to add those events to the ObjectTeam model <CX5FX5FEMPHASIS>before</CX5FX5FEMPHASIS
> regenerating the files.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See <RBW-XREF REFID="24431" TYPE="XREF-TEXTCOPY">Editing Generated Form (.txt/.dfm) Files</RBW-XREF
> and <RBW-XREF REFID="39943" TYPE="XREF-TEXTCOPY">Round&truehy;Trip Engineering</RBW-XREF
><B.BODY>As described in the previous sections, you can use ObjectTeam to model forms and components, then use Delphi to complete the generated form. The benefit of this approach is that, while modeling the application, you remain focused on the functions of the application rather than becoming distracted by the details of the GUI.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Model the form only</L.LABEL
><B.BODY>Alternatively, you can use the following approach:</B.BODY
><B.BODY>To model a form in ObjectTeam, create a class that represents the form and make it a subclass of the TForm class. Every window in a Delphi application is a form.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>FormStyle property</L.LABEL
><B.BODY>In Delphi, the FormStyle property of a form determines whether the form is a normal form, an MDI form, an MDI child, or a stay&truehy;on&truehy;top form. When ObjectTeam generates a form, it sets the FormStyle property to fsNormal. You can modify the FormStyle property in Delphi.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Main form</L.LABEL
><B.BODY>A Delphi project must have a main form to execute. To specify the main form in ObjectTeam, select the Main Form class property for exactly one ObjectTeam class that represents a form. (See <RBW-XREF REFID="17659" TYPE="XREF-TEXTCOPY">Editing Class Properties</RBW-XREF
><RBW-PARABODY>If you set this property for more than one class, or for a class that does not represent a form, the code generator displays an error message.</RBW-PARABODY
><B.BODY>For clarity, the CD shown above defines only the menu items for the form; it does not define all the other components. Modeling your menus in a separate CD, as shown here, helps keep your CDs readable and makes your model easier to maintain.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>TConsole class</SL.SUBLABEL
><B.BODY>The CD shown here assumes that the TConsole class is defined in another CD (the CD shown in <RBW-XREF REFID="33022" TYPE="XREF-TEXTCOPY">Basic Modeling Technique</RBW-XREF
>). The TForm superclass is not shown in this CD because the other CD defines the TConsole class as a subclass of TForm.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Complete the menu in Delphi</L.LABEL
><B.BODY>When ObjectTeam generates a menu for the first time, it uses default property values. Therefore, when you open the generated project in Delphi, the menu is not attached to the form and the menu items do not have captions.</B.BODY
><RBW-PARABODY>Edit the Caption property of each menu item to specify the text of the menu item. You can modify other properties, if desired.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>ObjectTeam preserves these changes when you regenerate the Delphi files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to use menu templates</L.LABEL
><B.BODY>Delphi provides menu templates for commonly used menus, such as File, Edit, and so on. If you plan to use Delphi’s menu templates, model only the main menu in ObjectTeam.</B.BODY
><RBW-PARABODY>If necessary, create a CDM for the main menu class. (Round&truehy;trip engineering ignores classes that do not have CDMs.)</RBW-PARABODY
> are components that cannot contain other components; for example, TButton and TImage.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>All components must be part of a form</L.LABEL
><B.BODY>Every component must be part of a form. Leaf components can be part of a form, or part of a container component that is part of a form. If a component is not part of a form, no code is generated for that component.</B.BODY
><RBW-PARABODY>Make it a subclass of the appropriate class in the DelphiVCL system. For example, make your class a subclass of TGroupBox or TButton.</RBW-PARABODY
><RBW-PARABODY>Use an aggregation to place the component on a form, or to place a leaf component in a container component. The role name becomes the name of the component in Delphi.</RBW-PARABODY
> for examples of how to model both container components and leaf components.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to model new component types</L.LABEL
><B.BODY>In the VCL, Delphi provides a rich library of component types. Delphi also allows you to create component types. New component types must be derived from existing component types.</B.BODY
><RBW-PARABODY>Set the Class Component Declaration class property of the new component class.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>When you generate code, ObjectTeam creates a unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) file that defines the component.</LR.LIST.RESULT
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using the new component type</SL.SUBLABEL
><B.BODY>Add a component of the new type to a form in the same way you add a component of any other type. Create a class to represent the component, make it a subclass of the new component type, and use an aggregation to place the component on a form.</B.BODY
>You might want to create an ObjectTeam system that defines commonly used menus and components. Adding such a system to the Object Design phase of a project allows you to reuse the menus and components on any form in that project.</T.TIP
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example of reuse</L.LABEL
><BI.BODY.INTRO>If the TControls group box is defined in a shared system, the CD used to define the TConsole form can reuse that group box. Compare the following CD with the CD shown in <RBW-XREF REFID="33022" TYPE="XREF-TEXTCOPY">Basic Modeling Technique</RBW-XREF
> Delphi code makes the classes, forms, data structures, and procedures visible in ObjectTeam. This facilitates your understanding of the existing code, thus giving you more opportunity for reusing the code.</B.BODY
> updates the ObjectTeam model based on the changes you have made to the generated Delphi source files (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
> and <CX5FX5FFILE.NAME>.txt/.dfm</CX5FX5FFILE.NAME
>). Use round&truehy;trip engineering to update the ObjectTeam model <CX5FX5FEMPHASIS>before</CX5FX5FEMPHASIS
> you regenerate the source files. If you add an attribute, procedure, event, or component to the generated source file, but do not add it to the ObjectTeam model, that attribute, procedure, event, or component is lost when you regenerate the source files.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Explanation</SL.SUBLABEL
><B.BODY>The code generator generates code based on the ObjectTeam model. When you regenerate the source file, only the attributes, operations, and form components defined in the model appear in the generated source file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
>Reverse engineering parses Delphi unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) files and builds CDs and CDMs that show the classes and forms defined in those files. It can be particularly useful if you have access to a class library and want to better understand its contents.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose </L.LABEL
><B.BODY>Use reverse engineering to capture and display the classes defined in your Delphi files. This serves two primary purposes:</B.BODY
><RBW-PARABODY>Helps you to understand the structure and functionality of the forms and classes.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Not an import utility</SL.SUBLABEL
><B.BODY>Reverse engineering is not designed to capture all the information in a Delphi file. Therefore, do not use reverse engineering to import forms or classes <CX5FX5FEMPHASIS>in order to maintain them in ObjectTeam</CX5FX5FEMPHASIS
><CX5FX5FEMPHASIS></CX5FX5FEMPHASIS
>. If you generate Delphi files from the CDs and CDMs created by reverse engineering, they will not match the files you used to create those CDs and CDMs.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Reverse engineering forms</L.LABEL
><B.BODY>If the form (and data module) files are in <CX5FX5FFILE.NAME>.dfm</CX5FX5FFILE.NAME
> format, ObjectTeam reverse engineers the forms without reverse engineering their components or events. If the form and data module files are in <CX5FX5FFILE.NAME>.txt</CX5FX5FFILE.NAME
> format, ObjectTeam reverse engineers the forms, their components, and their events.</B.BODY
><B.BODY>For the clearest view of the code, reverse engineering forms (and data modules) without reverse engineering their components and events.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What happens during reverse engineering</L.LABEL
><B.BODY>Reverse engineering uses the following steps to translate Delphi files into CDs and CDMs:</B.BODY
><B.BODY>After parsing the Delphi files, reverse engineering maps the Delphi constructs to ObjectTeam elements, as shown in the following table:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>As for Variable. The default value of the attribute is set to the value of the constant.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Class with default class properties. Members of the enumerated type are mapped to class attributes of the class. All attributes have a data type of enum.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Operation and parameters. The Event operation property is set. Parameter properties are set appropriately.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Subclass of the appropriate TComponent subclass. Default class properties are set. An aggregation association from the component to the class that represents the owner form is created. The class name of the component and the role name of the aggregation association are the same: the name of the Delphi component.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Class with Class Type property set to Interface. Properties and methods are mapped to attributes and operations of the class.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Procedure or function</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Operation and parameters. Operation and parameter properties are set appropriately.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Attribute. Properties on the Property tab of the attribute’s Edit Properties dialog box are set appropriately.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Class with Class Type property set to Record. Fields are mapped to attributes of the class.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Class with Class Type property set to Set. Members of the set are mapped to class attributes of the class. All attributes have a data type of enum.</CELLBODY
> file in the Delphi module defines the reverse engineering rules used to detect associations and attribute accessors. You can modify reverse engineering by editing this customization file, as described in the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><BI.BODY.INTRO>After mapping the Delphi constructs to ObjectTeam elements, reverse engineering creates the CDs and CDMs that define the ObjectTeam elements. It creates the following CDs:</BI.BODY.INTRO
><RBW-PARABODY>One or more CDs to show the associations among the classes</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Naming conventions for CDs</SL.SUBLABEL
><B.BODY>Each CD is named for the primary class in the CD; for example, Class1. The word Tree is appended to the name of each CD that defines part of the class hierarchy; for example, SuperClass1Tree.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How many diagrams are created</L.LABEL
><B.BODY>The number and complexity of the CDs created by reverse engineering depend largely on the following:</B.BODY
><RBW-PARABODY>The files that you select for reverse engineering, particularly the number and complexity of classes defined in the files.</RBW-PARABODY
><RBW-PARABODY>The reverse engineering options that you select, particularly whether you choose to reverse engineer associations.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="18986"></RBW-ANCHOR
>Options for reverse engineering</L.LABEL
><BI.BODY.INTRO>During reverse engineering, ObjectTeam displays the following dialog box prompting you to select the options that you want to use:</BI.BODY.INTRO
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>If selected, reverse engineering creates a separate reference CD for each class that exceeds the maximum size. The class is folded in all diagrams other than the reference diagram.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Max Class Width & Height</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a class. When a class exceeds this size, it is folded.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Max Tree Width & Height</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a class tree. When a class hierarchy exceeds this size, it is split.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a diagram. When a diagram exceeds this size, it is split.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Delphi almost always uses lowercase and ObjectTeam is case sensitive. Use this field to specify which case should be used in ObjectTeam.</CELLBODY
><RBW-PARABODY>FirstCase. For each identifier, use the case that is first encountered. (When reverse engineering multiple files, use this option with caution.)</RBW-PARABODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>If selected, reverse engineering examines the attributes and accessor methods defined on each class to determine the associations among classes. It then creates CDs that show those associations.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>GUI aggregations</SL.SUBLABEL
><B.BODY>Reverse engineering always creates CDs that show the aggregations that define the GUI, even if you have not selected the Reverse Engineer Associations option. How it creates these CDs depends on which Placement Algorithm option you selected in the Reverse Engineer dialog box.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>CDs that show the class hierarchy</L.LABEL
><BI.BODY.INTRO>Following are the guidelines used to draw the CDs that show the class hierarchy:</BI.BODY.INTRO
><RBW-PARABODY>Reverse engineering creates a CD for each top&truehy;level parent class. The CD contains the parent class and all subclasses.</RBW-PARABODY
><RBW-PARABODY>If a class has multiple parent classes, reverse engineering creates a CD for each parent. The CD for the first parent class contains the parent class, the child class, and all subclasses of the child class. The CD for each of the other parent classes contains only the parent class and the child class; in these diagrams, the child class is folded.</RBW-PARABODY
><B.BODY>If you select the Reverse Engineer Associations option in the Reverse Engineer dialog box, reverse engineering creates CDs that show the associations. How it creates these CDs depends on which Placement Algorithm option you selected in the Reverse Engineer dialog box. Both algorithms are described below.</B.BODY
><B.BODY>If you do not select the Reverse Engineer Associations option, reverse engineering shows associations only as attributes and accessor methods in the appropriate classes.</B.BODY
>Bidirectional associations are reverse engineered as two unidirectional associations.</N.NOTE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>GUI aggregations</SL.SUBLABEL
><B.BODY>Reverse engineering always creates CDs that show the aggregations that define the GUI, even if you have not selected the Reverse Engineer Associations option. How it creates these CDs depends on which Placement Algorithm option you selected in the Reverse Engineer dialog box.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Simple algorithm</L.LABEL
><B.BODY>If you select Simple in the Placement Algorithm field of the Reverse Engineer dialog box, reverse engineering draws the CDs as follows:</B.BODY
><RBW-PARABODY>Divides all classes into groups of <CX5FX5FEMPHASIS>n</CX5FX5FEMPHASIS
>, where <CX5FX5FEMPHASIS>n</CX5FX5FEMPHASIS
> is the number specified by the Number of Classes per CD field of the Reverse Engineer dialog box. The algorithm attempts to group associated classes.</RBW-PARABODY
><RBW-PARABODY>For each group of classes, creates a CD and adds the classes (unfolded) to the CD. To position the classes, reverse engineering uses a uniform grid whose squares are the size of the largest class in the group and its longest association.</RBW-PARABODY
><RBW-PARABODY>For each class in each CD, draws all associations from the class to all associated classes. If an associated class is not in the CD, reverse engineering adds it (folded) to the CD.</RBW-PARABODY
></LN.LIST.NUM
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>Reverse engineering a number of related classes using the grid algorithm creates one CD, as shown below. (The classes have been rearranged to fit more easily on the page.)</B.BODY
>Reverse engineering creates CDs and CDMs based on the files that you select. Therefore, you generally want to reverse engineer all related files at the same time.</T2.TIP.2
><RBW-PARABODY>Select the files that you want to reverse engineer, then select Open.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>A second Reverse Engineer Delphi dialog box appears (see <RBW-XREF REFID="18986" TYPE="XREF-TEXTCOPY">Options for reverse engineering</RBW-XREF
>), prompting you to select the options that you want to use. </LR.LIST.RESULT
><B.BODY>Round&truehy;trip engineering updates the ObjectTeam model based on the changes you have made to the generated unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) files and generated form or data module (<CX5FX5FFILE.NAME>.txt</CX5FX5FFILE.NAME
>) files. Use round&truehy;trip engineering to update the ObjectTeam model <CX5FX5FEMPHASIS>before</CX5FX5FEMPHASIS
> you regenerate the source files.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>.txt/.dfm</SL.SUBLABEL
><B.BODY>Forms and data modules can be stored in <CX5FX5FFILE.NAME>.txt</CX5FX5FFILE.NAME
> files. It does not examine <CX5FX5FFILE.NAME>.dfm </CX5FX5FFILE.NAME
>files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose</L.LABEL
><B.BODY>The code generator generates code based on the ObjectTeam model. If you do not update the ObjectTeam model before regenerating the source files, the new source files do not include your changes. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>You generate Delphi files. You then edit the generated source file, adding a new event to a component on a form. If you do not update the ObjectTeam model, the model does not contain the operation that corresponds to the event. When you regenerate the source file, the code generator assumes that you <CX5FX5FEMPHASIS>deleted</CX5FX5FEMPHASIS
> the operation from ObjectTeam and, therefore, does not include the <CX5FX5FEMPHASIS>obsolete</CX5FX5FEMPHASIS
> event in the newly generated source file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes captured by round&truehy;trip engineering</L.LABEL
><B.BODY>If you have made the following types of changes to the generated Delphi source, round&truehy;trip engineering updates the ObjectTeam model based on those changes:</B.BODY
><RBW-PARABODY>Added components to a form</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes not captured by round&truehy;trip engineering</L.LABEL
><B.BODY>Round&truehy;trip engineering ignores the following types of changes that you might have made to the generated source files. If you have made these types of changes, you must update the ObjectTeam model manually:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>For each difference it finds, ObjectTeam proposes an action and prompts you for confirmation. For example:</CELLBODY
><CELLBODY><CX5FX5FINPUT>In class Account : delete attribute Address?</CX5FX5FINPUT
>Parsing the Generated (Edited) Source Files</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This section describes which changes to the generated source files are captured by round&truehy;trip engineering. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes to attributes</L.LABEL
><B.BODY>You can add, delete, and modify attribute declaration statements in a generated unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) file. However, all attribute declaration statements must be specified beneath the following comment in the generated source file:</B.BODY
><EM.EXAMPLE.MONO>// User defined attributes</EM.EXAMPLE.MONO
><B.BODY>Attribute declarations not in this section of the generated source file are ignored by round&truehy;trip engineering.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attribute Access property</SL.SUBLABEL
><B.BODY>Round&truehy;trip engineering determines the value of an attribute’s Attribute Access property based on the methods specified beneath the following comment in the generated source file:</B.BODY
><B.BODY>For example, if you add an attribute declaration to the source file but do not add attribute access methods, round&truehy;trip engineerings sets the Read and Write values of the attribute’s Attribute Access property to None.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class constructor</SL.SUBLABEL
><B.BODY>The parameter list of the class constructor (Create) includes key attributes. In the CD, a key attribute is prefixed with an asterisk (*).</B.BODY
><B.BODY>If you remove an attribute from the parameter list of the constructor, round&truehy;trip engineering removes the asterisk (*) from the attribute name in the CD. If you add an attribute to the parameter list of the constructor, round&truehy;trip engineering adds an asterisk (*) to the attribute name in the CD.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes to functions</L.LABEL
><BI.BODY.INTRO>You can add, delete, and modify function declaration statements in a generated unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
>) file. However, all such declaration statements must be specified beneath the following comment in the generated source file:</BI.BODY.INTRO
><EM.EXAMPLE.MONO>// User defined methods</EM.EXAMPLE.MONO
><B.BODY>Function declarations not in this section of the generated source file are ignored by round&truehy;trip engineering.</B.BODY
><B.BODY>You can change the code in the body of any function. Such changes are ignored by round&truehy;trip engineering, but are preserved by the code generator when you regenerate the source files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes to events</L.LABEL
><B.BODY>You can add, delete, and modify event declaration statements in a generated unit (<CX5FX5FFILE.NAME>.pas</CX5FX5FFILE.NAME
> file).</B.BODY
><B.BODY>You can change the code in the body of any event. Such changes are ignored by round&truehy;trip engineering, but are preserved by the code generator when you regenerate the source files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes to components</L.LABEL
><B.BODY>You can add components to a generated form. However, <CX5FX5FEMPHASIS>if you delete a component, you must edit the ObjectTeam</CX5FX5FEMPHASIS
><CX5FX5FEMPHASIS> model manually</CX5FX5FEMPHASIS
>. Round&truehy;trip engineering does not delete components from the ObjectTeam model.</B.BODY
><B.BODY>If you add a component to a generated form, round&truehy;trip engineering updates the ObjectTeam model. Round&truehy;trip engineering does not modify existing CDs. It creates the following CDs to hold the classes that represent the new components:</B.BODY
> in the <CX5FX5FVARIABLE>M4_home\</CX5FX5FVARIABLE
>etc directory controls what actions round&truehy;trip engineering proposes, as well as the default answers it supplies. To examine or modify the current behavior of round&truehy;trip engineering, examine or modify the customization file.</B.BODY
><RBW-PARABODY>Optionally, enter a prefix to be used in naming any CDs created by round&truehy;trip engineering, then select OK. If you do not enter a prefix, round&truehy;trip engineering uses the prefix <CX5FX5FINPUT>NewRT</CX5FX5FINPUT
>.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam opens the Roundtrip Selected Files dialog box, compares the classes in the Delphi files to the classes in the Object Design phase, and then begins proposing actions and prompting you for confirmation.</LR.LIST.RESULT
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Cancel round&truehy;trip engineering. Changes that you have already saved are not backed out.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
><LR.LIST.RESULT>ObjectTeam updates the model based on your responses.</LR.LIST.RESULT
><RBW-TEXTFLD TYPE="text">Code Generation Guide for Delphi</RBW-TEXTFLD
></RBW-SYSOBJ
></A.APPENDIX.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Delphi code generation properties</L.LABEL
><B.BODY>The following table lists the properties that effect Delphi code generation. These are available in the CD in the Object Design phase.</B.BODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="20051" TYPE="XREF-TEXTCOPY">Chapter 4, Modeling Forms and Data Modules</RBW-XREF
><CHAPTERNONUM><CN.CHAPTER.NOX23>About This Manual<RBW-SYSOBJ TYPE="MIFmarker"><RBW-DATAFLD TYPE="number">0</RBW-DATAFLD
><RBW-TEXTFLD TYPE="text">Code Generation Guide for Fort\x8e </RBW-TEXTFLD
></RBW-SYSOBJ
></CN.CHAPTER.NOX23
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>About this manual</L.LABEL
><B.BODY>The <CX5FX5FTITLE>ObjectTeam Code Generation Guide for Forté</CX5FX5FTITLE
> contains information specific to the Forté TOOL programming language. This manual includes all the information that you need to generate Forté TOOL code from ObjectTeam. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisites</L.LABEL
><B.BODY>This guide is intended for experienced users of ObjectTeam and the analysis and design method it supports. This guide gives you information on how to map ObjectTeam diagrams to Forté TOOL code; it does not teach you the Forté TOOL language.</B.BODY
><B.BODY>To customize or extend the capabilities of the Forté code generator, you must have a thorough understanding of the ObjectTeam Shell, the Object&truehy;Oriented Programming Language (OOPL) model structure, and the Tool Command Language (Tcl) commands.</B.BODY
> provides the menu items, the properties and the Tcl code required to use the Forte Code Generator. Therefore, before moving to the Object Design phase, make sure this module is active.</B.BODY
><B.BODY>You can check if a module is active on a particular Browser level by selecting Utilities | Show Active Modules on that level.</B.BODY
> for details on how to activate a module.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Object Design and Implementation</L.LABEL
><B.BODY>This chapter describes the tasks of the Object Design phase. <RBW-XREF REFID="40110" TYPE="XREF-TEXTCOPY">Chapter 2, Building a Forté Application</RBW-XREF
>, describes the tasks of the Implementation phase. You work iteratively in these two phases to generate code and complete your application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose of object design</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="Object Design" TERM2="activities in this phase"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Object Design" TERM2="development phase in ObjectTeam project"></RBW-IDXTERM
>In ObjectTeam, the CDs (and the objects defined in the CDs) provide all the source data needed for code generation. The goal of object design is to add to the CDs all the data required for successful code generation. For example, you add properties (such as the Attribute Access property, which establishes read/write access to an attribute) and incorporate language&truehy;specific syntax (such as data type specifications for attributes and the arguments of operations).</B.BODY
><B.BODY>You might also add data to diagrams other than CDs. The code generator does not use oter diagrams, but they are useful for describing the behavior of classes, their attributes and operations.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="23233" TYPE="XREF-TEXTCOPY">Refining the Class Diagrams&rbwtab;1–3</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="11506" TYPE="XREF-TEXTCOPY">Hints and Tips for Effective Code Generation&rbwtab;1–6</RBW-XREF
>Introduction<RBW-IDXTERM TERM1="Class Association Diagram"></RBW-IDXTERM
></L.LABEL
><B.BODY>The CDs and the objects defined in the CDs provide all the source data needed for code generation. <RBW-IDXTERM TERM1="Class Association Model"></RBW-IDXTERM
>These diagrams distinguish the classes in a system and describe their identities and their features. In the Object Design phase, you must add to the CDs sufficient detail for successful code generation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using data from diagrams other than CDs</L.LABEL
><B.BODY>Diagrams other than the CDs are not used as input for code generation. However, they contain valuable information that can help you to complete and verify the CDs. The following table summarizes how you can use these other diagrams to help you find important objects that are not yet in the CDs.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>STD state names (enumerated list as an attribute value)</CELLBODY
><CELLBODY>STD condition on an event</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Classes</L.LABEL
><B.BODY>When you work on CDs, you focus on the implementation of classes. The CD must include all classes and the associations (and inheritance) between classes. In the Object Design phase, you may introduce new classes to ease implementation and improve performance.</B.BODY
><B.BODY>You must include all attributes and operations for each class. The attributes of a class map to the attributes of the class type. The operations of the class map to functions and procedures of the class type. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>External classes</L.LABEL
><B.BODY>A class must have at least one attribute or one operation to generate code. Classes that have no attributes or operations are translated as external classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Associations</L.LABEL
><B.BODY>You must define the associations between all classes, including any constraints.</B.BODY
><B.BODY>Role names must also be defined. Every association needs at least one role name. Every mandatory association must have a role name. Without a role name, you cannot use the association.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role names in Analysis and System Design</SL.SUBLABEL
><B.BODY>In the Analysis and System Design phases, role names distinguish a class by showing the role the class is playing in a relationship with another class. Each role name defines the role of the class within the context of a single association. It also indicates the use and direction of the association toward the class that plays a role. For example, a manager can be both the boss of a coworker and an employee of a company.</B.BODY
>Role names in Object Design and Implementation</SL.SUBLABEL
><BI.BODY.INTRO>In the Object Design and Implementation phases, the use of role names is extended. The code generator creates access methods for an association if the class at the far end has a role name for the association. In the previous example, the code generated for Coworker includes access methods for Manager; the code generated for Manager does not include access methods for Coworker.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attributes</L.LABEL
><B.BODY>You must specify each attribute completely, including its data type. The way to specify a data type for an attribute is to include the type in the class symbol, for example:</B.BODY
><B.BODY>Data types of attributes and arguments can be standard ObjectTeam types, standard types for your target language, or class types and derived types. Types are abstracted from the data types recognized by the database system and the OOPL environment. The code generator translates the standard types to the target types. </B.BODY
><B.BODY>Take care when customizing the files that define standard types. Any additions you make must conform to the target language or the generated code may not be usable.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Operations</L.LABEL
><BI.BODY.INTRO>You must specify each operation completely. This includes specifying such aspects as:</BI.BODY.INTRO
><RBW-PARABODY>Any parameters, as well as their data types</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Properties</L.LABEL
><BI.BODY.INTRO><RBW-IDXTERM TERM1="property" TERM2="using - to specify implementation details"></RBW-IDXTERM
>In the Object Design phase, a variety of properties allow you to specify many implementation details. <RBW-IDXTERM TERM1="property" TERM2="using - to specify implementation details"></RBW-IDXTERM
>These details are incorporated in the final code.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Checking</L.LABEL
><B.BODY>The last activity in object design is to use Check | Global Model to check the CDs. The CDs must be error&truehy;free before they can be used for code generation. See the <CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for more information about the Check utility.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</L.LABEL
><B.BODY><RBW-XREF REFID="22643" TYPE="XREF-TEXTCOPY">Chapter 3, Mapping Modeling Data to Forté</RBW-XREF
>, describes how the ObjectTeam model is translated into code. You can use this information to help you complete the CDs in the Object Design phase.</B.BODY
>Hints and Tips for Effective Code Generation</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Following are a few tips for effective code generation. It may be helpful to be aware of these items as you prepare for code generation, and then again as you generate and regenerate your source files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Understanding the translations</L.LABEL
><B.BODY>Before generating code, read through this guide. It contains detailed information about the data that you must include in your CDs for successful code generation. It also explains how the code generator translates the ObjectTeam model into source code files, what changes you can make to the source code files, and how to regenerate them without losing your changes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Naming conventions</L.LABEL
><B.BODY>Agree upon and follow a naming convention for projects, configurations, systems, classes, special characters, and so on. In addition, bear in mind that spaces between words (in class names, for instance) are deleted by ObjectTeam code generators.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing code generation</L.LABEL
><B.BODY>The code generators execute Tcl scripts that translate a model into source code. You can modify these scripts or create your own.. Always use caution when customizing or creating scripts; such scripts are not supported.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using multiple languages in a single application</L.LABEL
><B.BODY>Each ObjectTeam code generator is designed to generate code for one language. You can create an application that uses multiple languages by using different code generators to generate code for different systems; however, the generated code is not integrated across systems. </B.BODY
><B.BODY>The ObjectTeam code generators are not designed to provide language integration. To build an application that uses multiple languages, you must do the following: </B.BODY
>When you create a separate ObjectTeam system for each language&truehy;specific subsystem, be sure to define your classes in the appropriate system. When ObjectTeam generates code for the current system, it generates code for the classes that are defined in that system. It does not generate code for classes referenced, but not defined in, the current system; such classes are treated as external classes.</N.NOTE
>Typically, the ultimate goal of modeling an application is to produce code that implements the application. In ObjectTeam, you can generate a significant portion of the code automatically, then complete the code by adding the details that are not specified in the model.</B.BODY
><RBW-PARABODY>Only the CDs (and the objects defined in the CDs) are used for code generation. Therefore, before code generation, it is critical that the CDs be fully defined, as described in <RBW-XREF REFID="11405" TYPE="XREF-TEXTCOPY">Chapter 1, Preparing Your ObjectTeam Model for Code Generation</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Steps for code generation</L.LABEL
><B.BODY>The following table provides an overview of the code generation process. This chapter describes each step in greater detail.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Configure the Forté environment, installing the required systems in the Object Design Phase of your ObjectTeam Project.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Generate code. During this step, ObjectTeam runs the Tcl scripts that generate the Forté source files.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Import the generated classes into a Forté Project, fill in the method bodies, and export the classes back to ObjectTeam.</CELLBODY
> activates, among other things, the Tcl script <CX5FX5FFILE.NAME>forteimpor.tcl</CX5FX5FFILE.NAME
>, which contains Tcl code to retrieve information from internal models, format it and write it to Forté files. <CX5FX5FFILE.NAME>forteimpor.tcl</CX5FX5FFILE.NAME
> uses other Tcl scripts that use other Tcl scripts as well, and so on.</B.BODY
><B.BODY>The default <RBW-IDXTERM TERM1="Tcl" TERM2="script files used for code generation"></RBW-IDXTERM
>Tcl scripts used to generate Forté files can be found under the <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
>\<CX5FX5FFILE.NAME>modules</CX5FX5FFILE.NAME
>\<CX5FX5FFILE.NAME>forte</CX5FX5FFILE.NAME
>\<CX5FX5FFILE.NAME>tcl</CX5FX5FFILE.NAME
> directory tree. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>OOPL model</L.LABEL
><B.BODY>When you generate code, ObjectTeam converts the CDs and CDMs of the Object Design phase into an intermediate model: the OOPL model. The Forté code generator then generates the Forté source files based on the OOPL model.</B.BODY
> provides a detailed description of the classes in the OOPL model.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-IDXTERM TERM1="VisualWorks"></RBW-IDXTERM
>Forté files</L.LABEL
><B.BODY>You use ObjectTeam to model objects, as well as the associations among them. From the ObjectTeam model, you generate a <CX5FX5FFILE.NAME>.pex</CX5FX5FFILE.NAME
> file that can be imported into a Forté workspace. Typically, a Forté project is created for each ObjectTeam system.</B.BODY
><RBW-PARABODY>If you make changes to the generated files in Forté and then export those changes, your changes are preserved when you regenerate the files.</RBW-PARABODY
><RBW-PARABODY>Creation of the DCDs and CDMs representing the classes in the Forté class libraries Framework and DisplayProject. Bear in mind that his action involves the creation of a few hundred CDMs.</RBW-PARABODY
>Only the Forté <CX5FX5FEMPHASIS>class hierarchy </CX5FX5FEMPHASIS
>is made available in ObjectTeam, not the methods of the classes involved. Each class in the Framework and DisplayProject systems only contains a name and a <CX5FX5FINPUT>$create</CX5FX5FINPUT
> method.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Configuring your Forté environment automatically </L.LABEL
><B.BODY>Each custom class you draw in ObjectTeam must be derived from a Forté prefabricated class. The advantage of Forté classes being defined as external classes in ObjectTeam is that you can indicate in ObjectTeam from which Forté class you derive a custom class, without having to recreate the entire class hierarchy of the Forté class in ObjectTeam. </B.BODY
><B.BODY>In other words, if you derive custom classes from a lot of different prefabricated Forté classes, configuring your Forté environment will save you time.</B.BODY
><B.BODY>If you derive your custom classes only from a limited set of Forté classes, configuring your Forté environment is not recommendable, since hundreds of classes will be created unnecessarily. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to configure your Forté environment automatically</L.LABEL
><RBW-PARABODY>Select Utilities | Configure Forte Environment.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The appropriate System Versions are created on the current level. The appropriate CDs and CDMs are created in these System Versions.</LR.LIST.RESULT
><LT.LIST.TEXT>This action may take a while.</LT.LIST.TEXT
>For an overview of the classes created in the Framework and DisplayProject systems, open the system of your choice on Object Design level. Alternatively, you can use Utilities | Reports | On Classes to generate a report of the classes in the system, or use Utilities | Class Browser to start the ObjectTeam class browser.</T.TIP
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Configuring your Forté environment manually </L.LABEL
><B.BODY>If you do not configure your Forté environment automatically, you must create the new systems manually and populate them with the appropriate Forté classes. </B.BODY
><B.BODY>The name and the number of the CDs in these systems are unimportant for the Forté code generator. What does matter is the following:</B.BODY
><RBW-PARABODY>The top class the Forté class is derived from.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>The Forté code generator qualifies a class with the name of the ObjectTeam system it is defined in, so when a generated <CX5FX5FFILE.NAME>.cex</CX5FX5FFILE.NAME
> file is imported into Forté, it will recognize the super class as being the prefabricated Forté class from the Forté library. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to configure your Forté environment manually</L.LABEL
><RBW-PARABODY>Create in the Object Design phase the systems Framework and DisplayProject.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>If you are going to use classes from other Forté libraries, create corresponding ObjectTeam systems for these libraries as well.</LT.LIST.TEXT
><B.BODY>If you configure your Forté environment in the Object Design phase (see <RBW-XREF REFID="26207" TYPE="XREF-TEXTCOPY">Object Design Phase</RBW-XREF
>) the ObjectTeam System Versions Framework and DisplayProject in the Object Design Phase are populated with CADs and CDMs representing classes from the Forté class libraries.</B.BODY
><B.BODY>The classes in these systems serve as external classes; no code should be generated. However, if you do not configure your Forté environment in the Implementation Phase and select Utilities | Generate Forte | New Systems in this phase, the code generator detects the systems FrameWork and DisplayProject in the ObjectDesign phase, and attempts to generate code for the classes defined in these systems. </B.BODY
><B.BODY>The code generator can be prevented from doing this by creating the System Versions in the Implementation phase before code is generated. Utilities | Configure Forté Environment on Implementation Phase level does that for you.</B.BODY
><B.BODY>When you generate source files, the code generator uses the CDs and CDMs that are in the Object Design phase to create Forté source files in the Implementation phase. At System level of the Implementation phase, you can then refine the source code and complete the application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Implementation Phase is different</L.LABEL
><B.BODY>The System level of the Implementation phase is fundamentally different from System level of any other phase. In the Implementation phase, the System files are Forté source files. In other phases, the System files are ObjectTeam diagrams.</B.BODY
><RBW-PARABODY>On the <CX5FX5FBULLET.EMPHASIS>Implementation Phase level</CX5FX5FBULLET.EMPHASIS
>, you can generate code for one or more systems. This creates a matching system in the Implementation Phase that contains the generated source files. To regenerate code for an existing system, use System level.</RBW-PARABODY
><RBW-PARABODY>On the <CX5FX5FBULLET.EMPHASIS>System level of the Implementation phase</CX5FX5FBULLET.EMPHASIS
>, you can (re)generate code for the entire system, or regenerate selected source files.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>Typically, you use Implementation Phase level to generate code for a system initially and System level to regenerate code subsequently.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to generate code on Implementation Phase level</L.LABEL
> to generate code for one or more systems in the Object Design phase. You can select only systems that do not yet exist in the Implementation phase.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>ObjectTeam opens a Monitor window for displaying log messages, then generates the code.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to (re)generate code on System level</L.LABEL
> to (re)generate code for all classes that are defined in this system.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>ObjectTeam opens a Monitor window for displaying log messages, then (re)generates the files. The following illustration shows the Monitor window after generating code for a system.</LR.LIST.RESULT
><B.BODY>When you generate code, the Forté code generator generates the following ASCII files:</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
><CX5FX5FFILE.NAME>.cex file</CX5FX5FFILE.NAME
></SL.SUBLABEL
><B.BODY>Component EXport file, the file format used by Forté to export data from the Forté repository and import data into it. One <CX5FX5FFILE.NAME>.cex</CX5FX5FFILE.NAME
> file is generated for each ObjectTeam class.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
><CX5FX5FFILE.NAME>.hex file</CX5FX5FFILE.NAME
></SL.SUBLABEL
><B.BODY>These files contain the same information as <CX5FX5FFILE.NAME>.cex</CX5FX5FFILE.NAME
> files, except for the method implementations. <CX5FX5FFILE.NAME>.hex</CX5FX5FFILE.NAME
> files are generated to avoid conflicts in bidirectional associations (see <RBW-XREF REFID="21654" TYPE="XREF-TEXTCOPY">Mapping a bidirectional association</RBW-XREF
>). One <CX5FX5FFILE.NAME>.hex</CX5FX5FFILE.NAME
> file is generated for each ObjectTeam class.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Location of the source files</L.LABEL
><B.BODY>Source files are stored in the repository as external files. They are also written to the <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
> directory, where <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
> is the file path for your generated files. For more information on the user environment, see the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>. </B.BODY
><B.BODY>The following illustration shows how the source files appear in the Browser.</B.BODY
><RBW-IDXTERM TERM1="Update User Environment (Utilities menu)"></RBW-IDXTERM
>Updating user environment</L.LABEL
><B.BODY>Use Utilities | Update User Environment in ObjectTeam to update your user environment based on the repository. </B.BODY
><B.BODY>This can be particularly useful if you are working on two machines, and the user environment of each is set to a local drive. When you move between machines, you can use Utilities | Update User Environment to update the local drive of the current machine.</B.BODY
><RBW-PARABODY>When you have finished editing the objects in Forté, export the objects to the ObjectTeam user environment, overwriting the originally generated files.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>You can export classes to <CX5FX5FFILE.NAME>.cex</CX5FX5FFILE.NAME
> files using Component | Export Class in the Project Workshop.</LT.LIST.TEXT
><LR.LIST.RESULT>The generated files now reflect the changes that you made in Forté.</LR.LIST.RESULT
> files that are exported from Forté may contain many more properties than the originally generated <CX5FX5FFILE.NAME>.cex</CX5FX5FFILE.NAME
> files. Class properties are preserved when you regenerate code in ObjectTeam; component properties are not.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Exporting selected files</L.LABEL
><B.BODY>Instead of packing all <CX5FX5FFILE.NAME>.cex</CX5FX5FFILE.NAME
> and <CX5FX5FFILE.NAME>.hex</CX5FX5FFILE.NAME
> files, you can decide to include only selected files in a <CX5FX5FFILE.NAME>.pex</CX5FX5FFILE.NAME
> file. </B.BODY
><B.BODY>To do this, first select the files of your choice in the Information Area of the Browser and then select Forte | Generate pex File | From cex Files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Exporting .hex files only</L.LABEL
><B.BODY>In some situations, when dependencies exist across systems, for example, simply generating a <CX5FX5FFILE.NAME>.pex</CX5FX5FFILE.NAME
> file may not work. You then may have to export the <CX5FX5FFILE.NAME>.hex</CX5FX5FFILE.NAME
> files first, in order to make certain classes known to Forté.</B.BODY
><B.BODY>To do this, use Forte | Generate pex File | From hex Files followed by Forte | Generate pex File | From cex Files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes are preserved</L.LABEL
><B.BODY>Changes you make to generated Forté files are preserved when you regenerate the files, provided that you adhere to the following guidelines:</B.BODY
><RBW-PARABODY>If you have added, deleted, or modified Forté attributes or methods, use round&truehy;trip engineering (see <RBW-XREF REFID="21358" TYPE="XREF-TEXTCOPY">Round&truehy;Trip Engineering</RBW-XREF
>) to update the ObjectTeam model <CX5FX5FEMPHASIS>before</CX5FX5FEMPHASIS
>The code generator generates code based on the ObjectTeam model. If you do not add the new Forté objects to the ObjectTeam model, the code generator assumes that you deleted them from ObjectTeam. This makes the Forté objects obsolete, so ObjectTeam removes them from the generated source files.</N2.NOTE.2
>Regenerating Code<RBW-IDXTERM TERM1="code regeneration" TERM2="edited C++ source file"></RBW-IDXTERM
></S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Design changes and code changes</L.LABEL
><B.BODY>ObjectTeam supports incremental development. You can generate code from your models, edit that code, and regenerate the code without losing your changes. You can work with models during design and with code during implementation, shifting your focus between the two as necessary.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Code regeneration</L.LABEL
><B.BODY>The code regeneration process can be depicted as follows:</B.BODY
><RBW-PARABODY>Use the Forté Project Workshop to edit the <CX5FX5FEMPHASIS>bodies</CX5FX5FEMPHASIS
> of methods that were generated by ObjectTeam. When you export the class back to the ObjectTeam user environment, and you then regenerate the corresponding class, these method bodies are preserved.</RBW-PARABODY
><B.BODY>If, in the model, you rename, delete, or change the signature of an operation, the matching method in the generated Forté file is no longer correct. When you regenerate the file, ObjectTeam displays a message warning you that the method is being moved to the obsolete code section. It then appends the original method to the end of the generated file, as shown in the following example:</B.BODY
><E.EXAMPLE>/* OBSOLETE_CODE *</E.EXAMPLE
><E.EXAMPLE>....</E.EXAMPLE
><E.EXAMPLE>* OBSOLETE_CODE */</E.EXAMPLE
><B.BODY>You must delete the obsolete code before you can regenerate the Forté file.</B.BODY
><RBW-PARABODY>Select Utilities | Generate Forte | Selected.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam opens a Monitor window for displaying log messages, then imports the files.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Preserving previous versions</L.LABEL
><B.BODY>If you want to save the previously generated files, you can, before changing the ObjectTeam model, freeze both the model and the generated Forté files. This ensures that you have a stable version of the model and generated files to return to should your changes to the model not give the desired results.</B.BODY
>Modeling Data to <RBW-SYSOBJ TYPE="MIFmarker"><RBW-DATAFLD TYPE="number">0</RBW-DATAFLD
><RBW-TEXTFLD TYPE="text">Code Generation Guide for Fort\x8e </RBW-TEXTFLD
></RBW-SYSOBJ
>Forté</C.CHAPTER.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This chapter describes how ObjectTeam model information maps to Forté code. It provides examples of CDs and the results produced when you generate Forté code.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><B.BODY>These constructions can be enforced by setting the Class Type property to the appropriate value and by following certain rules, which are discussed in the sections listed above.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Initializing attributes</L.LABEL
><B.BODY>For every Forté class, a method <CX5FX5FINPUT>Init()</CX5FX5FINPUT
> is generated. This method is used for the initialization of public attributes of the class. It is automatically invoked on an object immediately after it is constructed. </B.BODY
><RBW-PARABODY>Draw another class named Object.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>This Forté root class, which is defined in the system Framework, is an external class. The system Framework is added to your ObjectTeam project when you configure your Forte environment.</LT.LIST.TEXT
>Here, the non&truehy;window class is explicitly derived from the Forté root class Framework.Object. However, since every class that is not derived from any other class is considered a subclass of Framework.Object by the Forté code generator, it is not necessary to do so.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The Class Type property of this example class is set to Class, which is the default. The example class is explicitly derived from the class Framework.Object.</B.BODY
><B.BODY>A window class is a class that is directly or indirectly derived from the Forté class UserWindow. This abstract class is part of the Forté DisplayProject library.</B.BODY
><B.BODY>A window class provides you with an empty window, which you can further specify using the Forté Window Workshop.</B.BODY
><RBW-PARABODY>Draw another class named UserWindow.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>This Forté class, which is defined in the system DisplayProject, is an external class. The system DisplayProject is added to your ObjectTeam project when you configure your Forté environment.</LT.LIST.TEXT
>You cannot model window and menu definitions in ObjectTeam. The idea behind modeling window classes in ObjectTeam is to generate basic GUI classes, which can be imported into Forté and further refined using the Forté Window Workshop.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What is generated</L.LABEL
><B.BODY>Every window class that is successfully generated contains:</B.BODY
><RBW-PARABODY>A GUI part in a compiled format (binary ASCII encoded)</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The Class Type property of this example class is set to Class, which is the default. The example class is derived from the class UserWindow.</B.BODY
><B.BODY>A Domain Class is a class that is a subclass of a Forté nullable DataValue subclass. </B.BODY
><B.BODY>The following nullable DataValue subclasses classes are defined in the system Framework. This system is added to your ObjectTeam project when you configure your Forte environment: </B.BODY
><B.BODY>Refer to your Forté documentation for more information on these classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Importing and exporting domain classes</L.LABEL
><B.BODY>A domain class is not very different from a non&truehy;domain class as far as the Forté code generation in ObjectTeam is concerned. However, in Forté, domain classes have many special properties, which are set when you import a generated <CX5FX5FFILE.NAME>.cex</CX5FX5FFILE.NAME
> file containing a domain class.</B.BODY
><B.BODY>When you export a domain class from Forté, import it into ObjectTeam, and regenerate the <CX5FX5FFILE.NAME>.cex</CX5FX5FFILE.NAME
> file, properties that were set by Forté are preserved.</B.BODY
><RBW-PARABODY>Make the first class a subclass of the DataValue class.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The Class Type property of this example class is set to Class, which is the default. The example class is derived from the class TextNullable.</B.BODY
><B.BODY>In the Object Design phase, you define properties of a class that control its implementation and accessibility within Forté. The code generated for a class is based on its properties. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to edit class properties<RBW-IDXTERM TERM1="Edit Properties (Item menu)" TERM2="for class"></RBW-IDXTERM
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>If the ObjectTeam class must be generated into a special Forté construction (such as a constant or service object) rather than a Forté class</CELLBODY
></ENTRY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="40407" TYPE="XREF-TEXTCOPY">Handling Special Classes</RBW-XREF
>ObjectTeam maps data attributes of normal ObjectTeam classes to Forté private or public attributes. You can determine the accessibility (private or public) through the attribute property Access.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attribute syntax</L.LABEL
><B.BODY>In ObjectTeam, the following syntax is used to specify data attributes for a class:</B.BODY
><E.EXAMPLE>[ / | $ | *] name : type = initial&truehy;value</E.EXAMPLE
><B.BODY>You use attribute properties to provide input to the code generator, such as a special kind of data type and the accessibility of data attributes. </B.BODY
><B.BODY>This section describes how to edit attribute properties, and the effect of each property.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section contains the following topics:</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="34064" TYPE="XREF-TEXTCOPY">Specifying Accessibility of Data Attributes&rbwtab;3–16</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="24666" TYPE="XREF-TEXTCOPY">Specifying Access Methods for Data Attributes&rbwtab;3–17</RBW-XREF
><B.BODY>The standard data types are defined in the <CX5FX5FFILE.NAME><RBW-IDXTERM TERM1="stand_types customization file"></RBW-IDXTERM
>stand_types</CX5FX5FFILE.NAME
> customization file. These are the data types that are valid in the Object Design phase.</B.BODY
><B.BODY>The translation between standard data types and Forté data types is defined by the <CX5FX5FFILE.NAME><RBW-IDXTERM TERM1="lang_types customization file"></RBW-IDXTERM
>lang_types</CX5FX5FFILE.NAME
> customization file. These are the translations used by the Forté code generator.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Modifying data types</L.LABEL
><B.BODY>Attribute data types can be modified through the attribute property Type Modifier. </B.BODY
><B.BODY>You can add additional data types to the list of standard types by editing the <CX5FX5FFILE.NAME>stand_types</CX5FX5FFILE.NAME
> customization file. If you add additional standard types, you must also provide translations for those data types by editing the <CX5FX5FFILE.NAME>lang_types</CX5FX5FFILE.NAME
> customization file.</B.BODY
><B.BODY>By default, the <CX5FX5FFILE.NAME>stand_types</CX5FX5FFILE.NAME
> and <CX5FX5FFILE.NAME>lang_types</CX5FX5FFILE.NAME
> customization files are defined on Corporate level. You can edit the customization files at Corporate level, or create and edit them at a lower level, such as Project level. (The customization files at the lower level override the customization files at the higher level.)</B.BODY
><B.BODY>In the Object Design phase, you define properties of the data attributes. These properties define the accessibility of the attribute, as well as the behavior of the attributes. The code generated for a data attribute is based on its properties.</B.BODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>A particular kind of data type for the attribute, such as an array or a pointer, or a user&truehy;defined type modifier</CELLBODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>The accessibility of the data attribute</CELLBODY
></ENTRY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="34064" TYPE="XREF-TEXTCOPY">Specifying Accessibility of Data Attributes</RBW-XREF
>Edit the Access property to specify the accessibility of a data attribute. You find this property on the Misc tab in the Edit Properties dialog box when the Attribute Name is selected.</B.BODY
> is a special type of method that gets (reads) and sets (writes) an attribute’s value. </B.BODY
><B.BODY>Use the Attribute Access Methods group box on the Access tab of the Edit Properties dialog box to specify what accessors are generated for the data attribute. You find this group box on the Misc tab in the Edit Properties dialog box when the Attribute Name is selected.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Read and Write fields</L.LABEL
><B.BODY>The Attribute Access Methods group box allows you to specify the access method for both read and write. The setting you specify in the Read field affects the Get attribute access method. The setting you specify in the Write field affects the Set attribute access method.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Access methods</L.LABEL
><B.BODY>The following values are allowed for both Read and Write fields. You can enter the same or different values in the two fields.</B.BODY
><B.BODY>The code excerpt below shows the code generated for the Account class, which has one attribute, Amount. The attribute’s Read and Write access methods are both specified as Public (the default).</B.BODY
><EM.EXAMPLE.MONO>...</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>class Account inherits from Framework.Object</EM.EXAMPLE.MONO
><B.BODY>Virtual attributes in Forté are attributes that are based on a calculation rather than a value or a point to an object. A virtual attribute consists of two expressions: one that is evaluated when the program sets the value of the attribute and another that is evaluated when the program gets the value of the attribute.</B.BODY
><RBW-PARABODY>Set the Type Modifier property for the attribute, the parameter or the method to Array or LargeArray.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>You find the Type Modifier property on the Misc tab in the Edit Properties dialog box. Use Array for arrays smaller than 256 entries, and LargeArray for arrays beyond this limit. </LT.LIST.TEXT
><RBW-PARABODY>To model a simple C&truehy;style array as type, specify a standard type for the attribute, the parameter or the method, and use an integer between square brackets to indicate the upper bounds of the array.</RBW-PARABODY
></P.PROCEDURE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example (ObjectTeam data attribute)</SL.SUBLABEL
><B.BODY></B.BODY
><EM.EXAMPLE.MONO>name:char[20]</EM.EXAMPLE.MONO
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated .cex file</SL.SUBLABEL
><B.BODY></B.BODY
><EM.EXAMPLE.MONO>...</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>has private attribute name: <CX5FX5FBULLET.EMPHASIS>array[20] of char</CX5FX5FBULLET.EMPHASIS
>;</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>...</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="26586"></RBW-ANCHOR
>Modifying pointer types</L.LABEL
><B.BODY>In Forté, a pointer to a specific data type or a specific class can be used for attribute type definition. You can model such an attribute type in ObjectTeam by setting the Type Modifier property to Pointer.</B.BODY
><B.BODY>In Forté you can define a variety of attribute types; class types as well as (derived) C&truehy;data types. The most common types can be modified in ObjectTeam by selecting the appropriate Type Modifier.</B.BODY
><B.BODY>However, you can modify your own attribute type in ObjectTeam by entering the required Forté code in the Type Modifier field.</B.BODY
>In this example a special form of a C&truehy;style array is specified, but you can use the Type Modifier field to enter any Forté code in order to specify the attribute’s type. </N.NOTE
><B.BODY>You indicate through the operation property Operation Type into which Forté element your operation must be generated. The way you model your operation and the set of properties you can specify depend on this property.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Operation syntax</L.LABEL
><B.BODY>In ObjectTeam, you use the following syntax to specify operations for a class:</B.BODY
><RBW-PARABODY>$ indicates a class feature.</RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>Forté does not support class features; therefore, this indicator is ignored by the code generator. It is only meaningful in the method<CX5FX5FINPUT> $create</CX5FX5FINPUT
> indicates an abstract operation. Forté does not support abstract operations; therefore, this indicator is ignored by the code generator.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section contains the following topics:</B.BODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Whether a reference to a copy of the class type object, or the reference to the class type object itself must be passed (only applicable to methods with a class return type)</CELLBODY
></ENTRY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="17071" TYPE="XREF-TEXTCOPY">Specifying the return type as copy</RBW-XREF
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>If the ObjectTeam operation must be generated into a Method, an Event or an Event Handler</CELLBODY
><B.BODY>You can also specify properties for parameters, as described in <RBW-XREF REFID="15651" TYPE="XREF-TEXTCOPY">Editing parameter properties</RBW-XREF
>, and for the return type of an operation, as described in <RBW-XREF REFID="18091" TYPE="XREF-TEXTCOPY">Editing method properties</RBW-XREF
>.</B.BODY
><B.BODY>Besides for operations as a whole, you can specify properties for the return type of an operation, and for parameters within an operation.</B.BODY
>While in Object Design, use the Access field on the Misc tab in the Edit Properties dialog box to define the extent to which other classes can access a method, an event or an event handler of a class. </B.BODY
><B.BODY>You can display the access level of methods in your diagram by checking Options | Show Visibility in the Class Diagram Editor. Method names will then be displayed with the following leading characters indicating the method’s access level:</B.BODY
><B.BODY>These special characters can also be used to <CX5FX5FEMPHASIS>set</CX5FX5FEMPHASIS
> the access level of methods. Typing a minus sign (&truehy;) before a method name will set the access level of the method to Private, for example. </B.BODY
>The special characters only work if the menu entry Options | Show Visibility in the Class Diagram Editor has been checked. Otherwise, the special characters will just be regarded as part of the method name.</W.WARNING
><B.BODY>Parameters can optionally be added to Methods, Events, and Event Handlers. </B.BODY
><B.BODY>Method parameters are used by the caller of the method to provide input values to the method, to hold output values from the method or both. </B.BODY
><B.BODY>Event Handler parameters are only used to provide input values to the event handler, such as the object for which the events are being handled.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Syntax</L.LABEL
><B.BODY>The parameters in the parameter list are separated by commas. Every parameter needs to have a type, which can either be a standard type or a (prefabricated or custom) class:</B.BODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Whether a reference to a copy of the class type object, or the reference to the class type object itself must be passed</CELLBODY
></ENTRY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="27277" TYPE="XREF-TEXTCOPY">Specifying the parameter type as copy</RBW-XREF
><B.BODY>The property Mechanism gives you control over the input/output mechanism of parameters in Forté.</B.BODY
><B.BODY>By default, a parameter is for input only. The caller specifies a parameter value when invoking the method. The method uses that value for processing.</B.BODY
><B.BODY>You can use the parameter property Mechanism to change the default input/output behavior. The available values are:</B.BODY
><B.BODY>The Mechanism property for the parameter par1 in the following example has not been touched (i.e is set to Input), whereas for par2 it has been set to Output, and for par3 to Input Output:</B.BODY
><B.BODY>You can use the parameter property Type Modifier to modify the type of a parameter. This is similar to modifying the type of an attribute (see <RBW-XREF REFID="17574" TYPE="XREF-TEXTCOPY">Modifying Types</RBW-XREF
>). </B.BODY
><B.BODY>You can modify it to be an Array, a LargeArray, or a Pointer. You can also provide a user&truehy;defined type modifier.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="27277"></RBW-ANCHOR
>Specifying the parameter type as copy</L.LABEL
><B.BODY>When the type of a parameter in Forté is a class, Forté passes a reference to the object, instead of the object itself. The copy option allows you to prevent the calling and called method from referencing the same object. When you specify copy for a class parameter, Forté makes a copy of the object and passes a reference to that copy as the parameter.</B.BODY
><B.BODY>You can indicate that you want to use the copy option for a parameter in ObjectTeam by turning on the parameter property Copy. This property is turned off by default.</B.BODY
><B.BODY>The property Copy for the parameter par1 in this example has not been touched (i.e is turned off), whereas for par2 it has been switched on.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated .cex file</SL.SUBLABEL
><B.BODY></B.BODY
><EWM.EXAMPLEW.MONO>...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>has public method myMethod(input par1: Framework.IntegerData,</EWM.EXAMPLEW.MONO
><B.BODY>In a call to a method, valid values for the method’s parameters <CX5FX5FEMPHASIS>must</CX5FX5FEMPHASIS
> be supplied, unless a default value has been specified. If a parameter has a default value, the parameter value <CX5FX5FEMPHASIS>can</CX5FX5FEMPHASIS
> be specified in the call, overriding the default value. </B.BODY
><B.BODY>Parameters with a default value are usually referred to as optional parameters; parameters without a default value as required parameters.</B.BODY
><B.BODY>In ObjectTeam you can specify the default value of a parameter through the parameter property Default Value. </B.BODY
>When your parameter type is a standard type, you can specify anything as default type, as long as it is compatible with the type of the parameter. In the case of a class type, the only default value you can specify is NIL, indicating “no object”.</N.NOTE
><B.BODY>In Forté, all methods consist of a name and the Forté source code that is executed when the method is called. The Forté code generator generates the method name and everything else that can be determined from your ObjectTeam model. The Forté source code you have to provide yourself. The following generated comment line reminds you of this:</B.BODY
><EM.EXAMPLE.MONO>&truehy;&truehy; !! Implement this method !!</EM.EXAMPLE.MONO
><B.BODY>Most methods include parameters, which allow the caller to pass information to and from the object that the method is manipulating. See <RBW-XREF REFID="24200" TYPE="XREF-TEXTCOPY">Defining Parameters</RBW-XREF
> for details on parameters.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="30419"></RBW-ANCHOR
>Special methods</L.LABEL
><B.BODY>The Forté code generator also generates the following special methods automatically; you do not have to specify them as operations in an ObjectTeam class:</B.BODY
><LT.LIST.TEXT>This Forté method is generated by default for all classes; that is, all ObjectTeam classes that have the Class Type Class specified.</LT.LIST.TEXT
><LT.LIST.TEXT>This Forté method is only generated for window classes; that is, ObjectTeam classes that are derived from the prefabricated Forté class UserWindow.</LT.LIST.TEXT
><RBW-PARABODY>Attribute access methods, as described in <RBW-XREF REFID="24666" TYPE="XREF-TEXTCOPY">Specifying Access Methods for Data Attributes</RBW-XREF
> are ignored by the Forté code generator. However, sometimes you need them to prevent an ObjectTeam class from being generated as a (generic) typedef (see <RBW-XREF REFID="24618" TYPE="XREF-TEXTCOPY">Typedef Class</RBW-XREF
>).</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="18091"></RBW-ANCHOR
>Editing method properties</L.LABEL
><B.BODY>The following properties can be set for a method:</B.BODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>Whether a reference to a copy of the class type object, or the reference to the class type object itself must be passed</CELLBODY
></ENTRY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="17071" TYPE="XREF-TEXTCOPY">Specifying the return type as copy</RBW-XREF
>The properties Access and Operation Type are described in <RBW-XREF REFID="16670" TYPE="XREF-TEXTCOPY">How to specify operation properties</RBW-XREF
>. All properties specific to methods are described below.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="24050"></RBW-ANCHOR
>Modifying a method’s return type</L.LABEL
><B.BODY>Specifying a return type for a method is optional. The return type is the data type of the value that is passed back to the caller by a <CX5FX5FINPUT>return</CX5FX5FINPUT
> statement in the method. </B.BODY
><B.BODY>The return type of a method can be a standard data type or a class type. Both these types can be modified using the method property Type Modifier, whose usage is similar to the attribute property Type Modifier (See <RBW-XREF REFID="17574" TYPE="XREF-TEXTCOPY">Modifying Types</RBW-XREF
><B.BODY>The Type Modifier for IntegerData has been set to Array.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated .cex file</SL.SUBLABEL
><B.BODY></B.BODY
><EWM.EXAMPLEW.MONO>...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>has public method myMethod(input par1: Framework.TextData,</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> input par2: short): <CX5FX5FBULLET.EMPHASIS>Framework.Array of Framework.IntegerData</CX5FX5FBULLET.EMPHASIS
>;</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>...</EWM.EXAMPLEW.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="14000"></RBW-ANCHOR
>Specifying a return event</L.LABEL
><B.BODY>In Forté, you can use the <CX5FX5FINPUT>start task</CX5FX5FINPUT
> statement in combination with a return event to call a method as a separate task and receive a notification when the task completes. </B.BODY
><B.BODY>To make this mechanism work, you must define a return event for the method, which you can do in ObjectTeam through the method property Return Event. You find this property on the Method tab in the Edit Properties dialog box.</B.BODY
><B.BODY>When you call the method with the <CX5FX5FINPUT>start task</CX5FX5FINPUT
> statement and you request the return event, the method automatically produces a return event when it completes. This return event uses the output and input&truehy;output parameters defined for the method (see <RBW-XREF REFID="22972" TYPE="XREF-TEXTCOPY">Specifying the Input Output mechanism</RBW-XREF
>).</B.BODY
><B.BODY>If a return type has been defined for the method, the last parameter of the event is a return value called <CX5FX5FINPUT>return</CX5FX5FINPUT
> statement in Forté can also be used in combination with an exception event to call a method as a separate task and receive a notification when the task terminates due to an unhandled exception.</B.BODY
><B.BODY>To make this mechanism work, you must define an exception event, which you can do in ObjectTeam through the method property Exception Event. You find this property on the Method tab in the Edit Properties dialog box.</B.BODY
><B.BODY>When you use <CX5FX5FINPUT>start task</CX5FX5FINPUT
> statement with the exception event on to call the method, the method automatically produces an exception event when it is terminated. This exception event has one parameter called <CX5FX5FINPUT>exception</CX5FX5FINPUT
><B.BODY>If your return type is a class, you can prevent the calling and the called method from referencing the same object in Forté by using the copy option. In ObjectTeam you can indicate that you want to use the copy option through the method property Copy. The way this property works is similar to how it works for parameter types (see <RBW-XREF REFID="27277" TYPE="XREF-TEXTCOPY">Specifying the parameter type as copy</RBW-XREF
><B.BODY>You mark an operation in ObjectTeam as event by setting the operation property Operation Type to Event. This property can be found on the Misc tab in the Edit Properties dialog box.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Events in Forté</L.LABEL
><B.BODY>An event is a notification that something significant has happened. In Forté, an object as well as a method that is operating on an object can trigger an event. When such an event is triggered, other parts of the application that are watching for that event can react to it.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Event parameters</L.LABEL
><B.BODY>Like methods, events can have parameters that allow the method that is triggering the event to provide information to any objects responding to the event. However, after the event is triggered, no communication takes place between the method triggering the event and the object or method responding to the event.</B.BODY
><B.BODY>You mark an operation in ObjectTeam as event handler by setting the operation property Operation Type to Event Handler. This property can be found on the Misc tab in the Edit Properties dialog box.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Event handlers in Forté</L.LABEL
><B.BODY>An event handler in Forté is a piece of TOOL code with a name. It is executed in response to one or more events. The event handler provides code that can be included in any number of event statements.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Event handler parameters </L.LABEL
><B.BODY>Like events, event handlers can have parameters. The mechanism used for these parameters is always <CX5FX5FEMPHASIS>input</CX5FX5FEMPHASIS
>. Other values specified in ObjectTeam will be ignored by the Forté code generator.</B.BODY
><B.BODY>If the operation property Operation Type is set to Event Handler, then the following Forté code is generated for the operation GlueHandler:</B.BODY
><EWM.EXAMPLEW.MONO>...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>has public <CX5FX5FBULLET.EMPHASIS>event handler</CX5FX5FBULLET.EMPHASIS
><B.BODY>In Forté, a default Init method is provided for every class. The Init method is automatically invoked on an object immediately after it is constructed. The default Init method simply invokes the Init method from the class’s superclass.</B.BODY
><B.BODY>The Forté generator adds the default Init method to every Forté class. It also adds comment lines, indicating where you should initialize public attributes, for example:</B.BODY
><EM.EXAMPLE.MONO> &truehy;&truehy; Start constructor user section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> &truehy;&truehy; End constructor user section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>end method;</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>...</EM.EXAMPLE.MONO
><B.BODY>The Forté generator generates a framework for Init methods and initializes the public attributes it is able to initialize. Other initializations you can do yourself. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Public attributes</L.LABEL
><B.BODY>If the data type of a public attribute in a class is a class itself, the Forté code generator generates a <CX5FX5FINPUT>new</CX5FX5FINPUT
> statement for this attribute in the body of the Init method. </B.BODY
><B.BODY>If the data type is a standard type, which is provided with an initial value, the attribute is initialized with this value.</B.BODY
><EM.EXAMPLE.MONO><CX5FX5FBULLET.EMPHASIS> name = new;</CX5FX5FBULLET.EMPHASIS
></EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO><CX5FX5FBULLET.EMPHASIS> id = 9;</CX5FX5FBULLET.EMPHASIS
></EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> &truehy;&truehy; Start constructor user section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> &truehy;&truehy; End constructor user section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>end method;</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>...</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>The Init method in “many” associations</L.LABEL
><B.BODY>In associations with a multiplicity of many, the Forté code generator adds an extra statement to the default Init method of the class at the other side of the many association. In this statement, an attribute with the name <CX5FX5FEMPHASIS>role_name</CX5FX5FEMPHASIS
><EM.EXAMPLE.MONO> &truehy;&truehy; Start constructor user section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> &truehy;&truehy; End constructor user section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>end method;</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>...</EM.EXAMPLE.MONO
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See <RBW-XREF REFID="14505" TYPE="XREF-TEXTCOPY">Mapping Associations With Multiplicity of Many</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="28842"></RBW-ANCHOR
>The Init method in qualified associations</L.LABEL
><B.BODY>The extra attribute that is initialized in qualified associations is of the type HashTable. You must explicitly initialize this hash table in the body of the Init method using Setup. An extra comment in the Init method reminds you of this.</B.BODY
><B.BODY>The Forté code generator supports single inheritance for classes. Multiple inheritance is not supported.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What is generated</L.LABEL
><B.BODY>In Forté, every class is a subclass of another class, with Framework.Object as root class. Every custom class you draw in ObjectTeam is part of an inheritance hierarchy. Even if you do not draw a superclass for a custom class, the class is assumed to be a subclass of Framework.Object.</B.BODY
><B.BODY>In the <CX5FX5FFILE.NAME>.cex</CX5FX5FFILE.NAME
> file that is generated for a custom class, the class’s superclass is always included in the class definition.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The following picture shows a simple inheritance hierarchy:</B.BODY
><B.BODY>N&truehy;ary associations are ignored by the Forté code generator. Code is generated for the classes involved, but no code is generated for the association itself.</B.BODY
>The Forté code generator translates aggregations like associations.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="32778"></RBW-ANCHOR
>Association attribute properties</L.LABEL
><B.BODY>Association attributes and accessors, like data attributes and accessors, have associated ObjectTeam properties. You can effect the code generated for any association by specifying these properties in ObjectTeam.</B.BODY
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>The accessibility of the association attribute</CELLBODY
></ENTRY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="34064" TYPE="XREF-TEXTCOPY">Specifying Accessibility of Data Attributes</RBW-XREF
><ENTRY COLNAME="3" VALIGN="TOP" MOREROWS="0"><CELLBODY>The (expected) maximum number of entries in your many association (only applicable to associations with a multiplicity of many).</CELLBODY
></ENTRY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="21308" TYPE="XREF-TEXTCOPY">Specifying the maximum volume</RBW-XREF
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="38957" TYPE="XREF-TEXTCOPY">Mapping Link Attributes and Classes as Associations&rbwtab;3–61</RBW-XREF
><B.BODY>This section describes how the Forté code generator implements the following simple associations between the Customer class and the Book class.</B.BODY
>The direction of an association is defined by the role names on the association. A role name at the far end of the association indicates an association from the class at the near end to the class at the far end.</B.BODY
><B.BODY>If an association has a role name at only one end, it is a <CX5FX5FEMPHASIS>unidirectional</CX5FX5FEMPHASIS
> association (implemented in one direction). If an association has role names at both ends, it is a <CX5FX5FEMPHASIS>bidirectional</CX5FX5FEMPHASIS
> association (implemented in both directions).</B.BODY
>The Forté code generator implements a unidirectional association by adding an <CX5FX5FEMPHASIS>association attribute</CX5FX5FEMPHASIS
> and a set of <CX5FX5FEMPHASIS>association attribute accessor methods</CX5FX5FEMPHASIS
> to the code generated for the class at the near end of the association. This allows the class at the near of the association (Customer) to access the class at the far end (Book); the class at the far end of the association cannot access the class at the near end.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="21654"></RBW-ANCHOR
>Mapping a bidirectional association</L.LABEL
><B.BODY>The Forté code generator implements a bidirectional association by adding an <CX5FX5FEMPHASIS>association attribute</CX5FX5FEMPHASIS
> and a set of <CX5FX5FEMPHASIS>association attribute accessor methods </CX5FX5FEMPHASIS
>to the code generated for both classes. This allows each class to access the other. To ensure integrity of a bidirectional association, the update method for a bidirectional association always maintains the association in both directions.</B.BODY
>In bidirectional associations, the accesibility of association attributes and association attribute accessors is always Public. Hence, the association properties Access and Access Methods are ignored by the code generator.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Bidirectional associations and .hex files</L.LABEL
><B.BODY>Since both classes (class A and class B) in a bidirectional association use accessor methods to one another, class A should be known to Forté before class B, and class B should be known to Forté before class A. </B.BODY
><B.BODY>To avoid conflicts on this, the Forté generator generates <CX5FX5FFILE.NAME>.hex</CX5FX5FFILE.NAME
> files, which are equal to <CX5FX5FFILE.NAME>.cex</CX5FX5FFILE.NAME
> files, except that the method bodies are lacking. These <CX5FX5FFILE.NAME>.hex</CX5FX5FFILE.NAME
> files need to be imported in Forté first.</B.BODY
><B.BODY>Following is an excerpt from the code generated for the Customer class in the unidirectional association. Because this is a unidirectional association, the Book class does not contain any code related to the association.</B.BODY
><B.BODY>Following is an excerpt from the code generated for the Customer class in the bidirectional association. Because this is a bidirectional association, the Book class contains similar code to implement the association in the other direction.</B.BODY
>The ObjectTeam documentation use the term <CX5FX5FTERM>association attribute</CX5FX5FTERM
> to refer to data attributes generated to support ObjectTeam associations (as opposed to data attributes generated from ObjectTeam attributes). In Forté, an association attribute is simply another data attribute and association accessors are simply data attribute accessors.</B.BODY
> describes the mapping of an ObjectTeam association with a multiplicity of one. This section assumes that you are familiar with that information.</B.BODY
>The mapping of an association with a multiplicity of many is similar to that of an association with a multiplicity of one; however, the type of the association attribute is different. </B.BODY
>. For an association with a multiplicity of many, the type of the association attribute is the Array class. </RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>The Array class uses a slightly different set of attribute access methods. For read access, it uses a get method. For write access, however, it uses two methods: add and remove. All three attribute access methods are shown in the following example.</LT.LIST.TEXT
><B.BODY>The Array class is used for arrays smaller than 256 entries, whereas the LargeArray class is used for arrays beyond this limit. </B.BODY
><B.BODY>You can use the Association property Maximum Volume to specify the (expected) maximum number of entries in your many association. Depending on this number, the Forté generator uses the Array or the LargeArray class.</B.BODY
>If you do not specify a value for the Maximum Volume property, the Forté code generator uses the Array class.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>Following is an excerpt from the code generated for the Customer class shown above. (This association is unidirectional; therefore, the Book class does not contain any code related to the association.)</B.BODY
><B.BODY><RBW-XREF REFID="14505" TYPE="XREF-TEXTCOPY">Mapping Associations With Multiplicity of Many</RBW-XREF
> describes the mapping of an ObjectTeam association with multiplicity of many. This section assumes that you are familiar with that information.</B.BODY
>This section describes how the Forté code generator implements the following ordered association between the Customer class and the Book class. </B.BODY
>The mapping of an ordered association, is similar to that of an association with an unordered multiplicity of many; however, the method that is generated for adding elements to the list is different.</B.BODY
><B.BODY>For ordered associations, the method <CX5FX5FINPUT>append</CX5FX5FINPUT
><CX5FX5FVARIABLE>class_name</CX5FX5FVARIABLE
> is generated. In the implementation of this method, the list is considered an array. For unordered associations, the method <CX5FX5FINPUT>add<RBWAUTO-0007>class_name </RBWAUTO-0007
></CX5FX5FINPUT
>is generated, which considers the list a set.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>Following is an excerpt from the code generated for the Customer class shown above. (This association is unidirectional; therefore, the Book class does not contain any code related to the association.)</B.BODY
><B.BODY><RBW-XREF REFID="14505" TYPE="XREF-TEXTCOPY">Mapping Associations With Multiplicity of Many</RBW-XREF
> describes the mapping of an ObjectTeam association with multiplicity of many. This section assumes that you are familiar with that information.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Qualified association</L.LABEL
><B.BODY>This section describes how the Forté code generator implements the following association between the Customer class and the Book class. </B.BODY
>The mapping of a qualified associations, is similar to that of an association with multiplicity of many; however, the type of the association attribute is different.</B.BODY
><B.BODY>For a qualified association, the type of the association attribute is the class Framework.HashTable. The qualifier (bookID, in the CD above) is used as a key into the hashtable for storage and retrieval.</B.BODY
>If the qualified association has a multiplicity greater than 1, you must initialize the hash table using the Setup method. A comment in the generated code reminds you to provide code for this method.</B.BODY
><B.BODY>For an example of such an initialization, see <RBW-XREF REFID="28842" TYPE="XREF-TEXTCOPY">The Init method in qualified associations</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role names at the side of the qualifier</L.LABEL
><B.BODY>In the example depicted above, every Book object keeps track of the Customer object it is associated with, or, if the multiplicity at the qualifier side is many, the <CX5FX5FEMPHASIS>set</CX5FX5FEMPHASIS
> of associated Customer objects. Hence, the associated Customer object(s) can always be retrieved from a Book object.</B.BODY
><B.BODY>Bear in mind, however, that if you put a role name at the side of the qualifier, Book objects do not keep track of the qualifier, or the set of qualifiers used to establish the association with Customer object(s). The attribute <CX5FX5FVARIABLE>roleName</CX5FX5FVARIABLE
> (or, in the case of a many association <CX5FX5FVARIABLE>roleNameSet</CX5FX5FVARIABLE
>) that is generated for Book will not contain the qualifier, and will return the same as in a non&truehy;qualified association.</B.BODY
><B.BODY>The only properties available for a qualifier are the data type and comments. You can, of course, also edit other properties of the association, as described in <RBW-XREF REFID="32778" TYPE="XREF-TEXTCOPY">Association attribute properties</RBW-XREF
><B.BODY>Following is an excerpt from the code generated for the Customer class shown above. (The association is unidirectional; therefore, the Book class does not contain any code related to the association.)</B.BODY
><B.BODY>The data type of the bookID qualifier is specified as integer, which is a Forté standard data type. The comment in the code reminds you to initialize the hash table for bookID.</B.BODY
><EWM.EXAMPLEW.MONO>has public method Init;</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>has public method getName: string;</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>has public method setName(input newName: string);</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO><CX5FX5FBULLET.EMPHASIS>has public method getBookSet(input bookIDKey: integer): Framework.Array of mySystem.Book;</CX5FX5FBULLET.EMPHASIS
></EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO><CX5FX5FBULLET.EMPHASIS>has public method addBook(input bookIDKey: integer,</CX5FX5FBULLET.EMPHASIS
>Mapping Link Attributes and Classes as Associations</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisite</L.LABEL
><B.BODY>This section assumes that you are familiar with the mapping of various types of associations, as described in the previous sections.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attributes and classes on associations</L.LABEL
><B.BODY>ObjectTeam allows you to specify information about an association by linking attributes, or a class, to the association. The following diagram shows a link attribute symbol; a class symbol could be used in the same location.</B.BODY
><B.BODY>An association that includes a link attribute or a class is transformed before code generation. The link attribute or class becomes a separate class, with appropriate associations to the original classes. The generated code is then based on the transformed association.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The code generated for the CD shown above is actually based on the following CD:</B.BODY
>If the association includes a link attribute, the new class is assigned the name of the association. Therefore, an association that has a link attribute must have an association name.</B.BODY
><RBW-IDXTERM TERM1="mapping" TERM2="class, as association"></RBW-IDXTERM
>If the association includes a class, that class is used as the third class. Therefore, an association that includes a class does not need an association name.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role names are required</L.LABEL
><B.BODY>As with all associations, role names are required. If a role name is omitted, the association attributes and methods that would map to that role name are not generated.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><BI.BODY.INTRO>Following is the code generated for each of the three Forté classes produced by the CD shown above.</BI.BODY.INTRO
>The Typedef class is a standard construct to specify the Forté derived C data type <CX5FX5FINPUT>typedef</CX5FX5FINPUT
>: a synonym for a specific data type or user&truehy;defined class.</B.BODY
><B.BODY>A Typedef class is a class with only one data attribute and no methods. It is generated into the following Forté typedef construction:</B.BODY
><B.BODY>For every class that has only one data attribute and no methods, the Forté code generator generates a typedef construction.</B.BODY
><B.BODY>However, you may have such classes in your model for which you do not want to generate a typedef. The way of getting around this is to add the following method to the class:</B.BODY
><EM.EXAMPLE.MONO>$create</EM.EXAMPLE.MONO
><B.BODY>This method signals the Forté generator to handle the class as a regular class, but does not appear in the generated code.</B.BODY
><B.BODY>Generic typedef constructions are typedefs through which you can define a synonym for the following data types that are supported by Forté:</B.BODY
><RBW-PARABODY>Draw an association between the class you have just drawn (class A) and the class for which you want to generate the generic typedef (class B).</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>The multiplicity at the side of class B determines which generic typedef is generated:</LT.LIST.TEXT
><B.BODY>The following Forté code is generated for the class GenTyEx3:</B.BODY
><EWM.EXAMPLEW.MONO>...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>typedef GenTyEx3 : <CX5FX5FBULLET.EMPHASIS>Framework.Array of mySystem.Ex3</CX5FX5FBULLET.EMPHASIS
>;</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>...</EWM.EXAMPLEW.MONO
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Maximum Volume specified</SL.SUBLABEL
><EM.EXAMPLE.MONO></EM.EXAMPLE.MONO
><B.BODY>If the association property Maximum Volume is set to anything beyond 255, the class Framework.LargeArray will be used instead of Framework.Array.</B.BODY
><B.BODY>If in the previous example the property Maximum Volume for role x is set to 300, for example, the following Forté code is generated for the class GenTyEx3:</B.BODY
><EWM.EXAMPLEW.MONO>...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>typedef GenTyEx3 : <CX5FX5FBULLET.EMPHASIS>Framework.LargeArray of mySystem.Ex3</CX5FX5FBULLET.EMPHASIS
><B.BODY>The following Forté code is generated for the class GenTyEx5, which is associated with an Enum class (see <RBW-XREF REFID="13941" TYPE="XREF-TEXTCOPY">Enum Class</RBW-XREF
> for details):</B.BODY
><EWM.EXAMPLEW.MONO>...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>typedef GenTyEx5 : <CX5FX5FBULLET.EMPHASIS>array[255] of mySystem.myEnumClass</CX5FX5FBULLET.EMPHASIS
>;</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>...</EWM.EXAMPLEW.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example (multiplicity: one)</L.LABEL
><B.BODY>If the multiplicity of the association at the side of class B is mandatory, a normal, non&truehy;generic typedef is created to class B (see <RBW-XREF REFID="24618" TYPE="XREF-TEXTCOPY">Typedef Class</RBW-XREF
><B.BODY>Besides pointer and array typedefs, you can model hash table typedefs in ObjectTeam. You must then specify a qualified association instead of a normal association, and the multiplicity must be optional (e.g. many).</B.BODY
><B.BODY>A constant is a literal string or numeric value that has a name. You can model the name and the value of a constant in ObjectTeam through a data attribute in a special Constant class.</B.BODY
><B.BODY>A class usually consists of a class definition and the code that implements the class, such as method bodies. An interface only consists of a definition; the method bodies are implemented somewhere else.</B.BODY
><B.BODY>Therefore, an interface does not have the following components:</B.BODY
><B.BODY>Interfaces are generally used as an aid for modeling multiple inheritance.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class hierarchy</L.LABEL
><B.BODY>An interface can be derived from at most one other interface. Make sure that if there are multiple interfaces in the class hierarchy of a user&truehy;defined class, all the methods from these interfaces are included in the user&truehy;defined class.</B.BODY
><RBW-PARABODY>Make sure the user&truehy;defined class is also derived from a Forté class. If it is not, the code generator assumes that Framework.Object is its super class.</RBW-PARABODY
> are generated for both the Interface class and the user&truehy;defined class that is derived from the Interface class. However, only the user&truehy;defined class will contain method <CX5FX5FEMPHASIS>bodies</CX5FX5FEMPHASIS
>. Therefore, the following comment line reminding you of implementing the method is only added to the user&truehy;defined class:</B.BODY
><EM.EXAMPLE.MONO>&truehy;&truehy; !! Implement this method !!</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The next figure shows an example of an interface and a user&truehy;defined class which is derived from this interface. The property Interface has been turned on for the class MyInterface.</B.BODY
><B.BODY>The next figure shows two classes conforming to the enumeration class construct guidelines. The first one has data attributes without default values, the second one has data attributes with default values:</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Data attributes without default values</SL.SUBLABEL
><B.BODY>A Service Object in Forté is an instance of a class that is located on a specific partition. All of the distributed services with which an application interacts are represented by service objects.</B.BODY
><B.BODY>A Service Object can be modeled in ObjectTeam by a special class with only one method.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to specify a service object class</L.LABEL
><B.BODY>To specify a service object class:</B.BODY
><RBW-PARABODY>Every parameter must have a default value, which can be provided through the Default Value property. Parameters without a default value are not generated.</RBW-PARABODY
><B.BODY>A Cursor in Forté is a row marker that is used for selecting and working with a set of rows from a database. It can be modeled in ObjectTeam by a special class with only one method.</B.BODY
><B.BODY>After you generate code for this class, a Forté cursor construction is generated. Comment lines remind you to fill in the body of the cursor.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The following properties have been set for this example class:</B.BODY
> Forté code makes the structures and functions of the code visible in ObjectTeam. This facilitates your understanding of the existing code, thus giving you more opportunity for reusing the code.</B.BODY
> updates the ObjectTeam model based on the changes you have made to the generated Forté source files. Use round&truehy;trip engineering to update the ObjectTeam model <CX5FX5FEMPHASIS>before</CX5FX5FEMPHASIS
> you regenerate the source files. If you add an attribute or operation to the generated source file, but do not add it to the ObjectTeam model, that attribute or operation is lost when you regenerate the source files.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Explanation</SL.SUBLABEL
><B.BODY>The code generator generates code based on the ObjectTeam model. When you regenerate the source file, only the attributes and operations defined in the model appear in the generated source file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><RBW-PARABODY>Helps you to understand the structure and functionality of classes.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Not an import utility</SL.SUBLABEL
><B.BODY>Reverse engineering is not designed to capture all the information in a Forté file. Therefore, do not use reverse engineering to import classes <CX5FX5FEMPHASIS>in order to maintain them in ObjectTeam</CX5FX5FEMPHASIS
><CX5FX5FEMPHASIS></CX5FX5FEMPHASIS
>. If you generate Forté files from the CDs and CDMs created by reverse engineering, they will not match the files you used to create those CDs and CDMs.</B.BODY
><RBW-PARABODY>It detects associations according to a heuristic process. The associations can be transformed either into graphical associations or into attributes and methods.</RBW-PARABODY
><RBW-PARABODY>It does not check data types; therefore, data types do not have to be known to the parser.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Identifiers</SL.SUBLABEL
><B.BODY>Reverse engineering assumes that the first character of an identifier is an alphabetic character of either case or one of the following special characters: _ “ $. It assumes each subsequent character in the identifier is an alphanumeric character or one of three special characters listed previously.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Mapping the elements<RBW-IDXTERM TERM1="C++" TERM2="reverse engineering"></RBW-IDXTERM
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Class with the Class Type property set to Class. Class hierarchy is created, if necessary.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Class with one or more attributes. All attributes have data type <CX5FX5FEMPHASIS>enum</CX5FX5FEMPHASIS
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Operation (and parameters) with Operation Type property set to Event. The following operation property is also set:</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Operation (and parameters) with Operation Type property set to Event Handler. The following operation property is also set:</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Operation (and parameters) with Operation Type property set to Method. The following operation properties are also set:</CELLBODY
> file in the Forté module defines the reverse engineering rules used to detect associations and attribute accessors. You can modify reverse engineering by editing this customization file, as described in the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><BI.BODY.INTRO>After mapping the Forté constructs to ObjectTeam elements, reverse engineering creates the CDs and CDMs that define the ObjectTeam elements. It creates the following CDs:</BI.BODY.INTRO
><RBW-PARABODY>One or more CDs to show the associations among the classes</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Naming conventions for CDs</SL.SUBLABEL
><B.BODY>Each CD is named for the primary class in the CD; for example, Class1. The word Tree is appended to the name of each CD that defines part of the class hierarchy; for example, ObjectTree.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How many diagrams are created</L.LABEL
><B.BODY>The number and complexity of the CDs created by reverse engineering depend largely on the following:</B.BODY
><RBW-PARABODY>The files that you select for reverse engineering, particularly the number and complexity of classes defined in the files.</RBW-PARABODY
><RBW-PARABODY>The reverse engineering options that you select, particularly whether you choose to reverse engineer associations.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="26227"></RBW-ANCHOR
>Options for reverse engineering</L.LABEL
><BI.BODY.INTRO>During reverse engineering, ObjectTeam displays the following dialog box prompting you to select the options that you want to use:</BI.BODY.INTRO
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>If selected, reverse engineering creates a separate reference CD for each class that exceeds the maximum size. The class is folded in all diagrams other than the reference diagram.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Max Class Width & Height</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a class. When a class exceeds this size, it is folded.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Max Tree Width & Height</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a class tree. When a class hierarchy exceeds this size, it is split.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a diagram. When a diagram exceeds this size, it is split.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Forté is not case sensitive; however, ObjectTeam is case sensitive. Use this field to specify which case should be used in ObjectTeam.</CELLBODY
><RBW-PARABODY>FirstCase. For each identifier, use the case that is first encountered. (When reverse engineering multiple files, use this option with caution.)</RBW-PARABODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>If selected, reverse engineering examines the attributes and accessor methods defined on each class to determine the associations among classes. It then creates CDs that show those associations.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>CDs that show the class hierarchy</L.LABEL
><B.BODY>Following are the guidelines used to draw the CDs that show the class hierarchy:</B.BODY
><RBW-PARABODY>Reverse engineering creates a CD for each top&truehy;level parent class. The CD contains the parent class and all subclasses.</RBW-PARABODY
><RBW-PARABODY>If a class has multiple parent classes, reverse engineering creates a CD for each parent. The CD for the first parent class contains the parent class, the child class, and all subclasses of the child class. The CD for each of the other parent classes contains only the parent class and the child class; in these diagrams, the child class is folded.</RBW-PARABODY
><B.BODY>If you select the Reverse Engineer Associations option in the Reverse Engineer dialog box, reverse engineering creates CDs that show the associations. How it creates these CDs depends on which Placement Algorithm option you selected in the Reverse Engineer dialog box. Both algorithms are described below.</B.BODY
><B.BODY>If you do not select the Reverse Engineer Associations option, reverse engineering shows associations only as attributes and accessor methods in the appropriate classes.</B.BODY
>Bidirectional associations are reverse engineered as two unidirectional associations.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Simple algorithm</L.LABEL
><BI.BODY.INTRO>If you select Simple in the Placement Algorithm field of the Reverse Engineer dialog box, reverse engineering draws the CDs as follows:</BI.BODY.INTRO
><RBW-PARABODY>Divides all classes into groups of <CX5FX5FEMPHASIS>n</CX5FX5FEMPHASIS
>, where <CX5FX5FEMPHASIS>n</CX5FX5FEMPHASIS
> is the number specified by the Number of Classes per CD field of the Reverse Engineer dialog box. The algorithm attempts to group associated classes.</RBW-PARABODY
><RBW-PARABODY>For each group of classes, creates a CD and adds the classes (unfolded) to the CD. To position the classes, reverse engineering uses a uniform grid whose squares are the size of the largest class in the group and its longest association.</RBW-PARABODY
><RBW-PARABODY>For each class in each CD, draws all associations from the class to all associated classes. If an associated class is not in the CD, reverse engineering adds it (folded) to the CD.</RBW-PARABODY
></LN.LIST.NUM
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><BI.BODY.INTRO>The following CD, created by the grid algorithm, shows all of the associations among three classes. (The classes in the generated CD were repositioned so this illustration would fit on the page.)</BI.BODY.INTRO
><RBW-PARABODY>Select the files (<CX5FX5FFILE.NAME>.cex</CX5FX5FFILE.NAME
> or <CX5FX5FFILE.NAME>.pex</CX5FX5FFILE.NAME
>) that you want to reverse engineer, then select OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>A second Reverse Engineer Forté dialog box appears (see <RBW-XREF REFID="26227" TYPE="XREF-TEXTCOPY">Options for reverse engineering</RBW-XREF
>), prompting you to select the options that you want to use. </LR.LIST.RESULT
><RBW-PARABODY>Select the options, then select OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam reverse engineers the selected file, reporting the results in a Monitoring window. The generated CDs display the class hierarchy defined in the selected files, as well as the attributes, operations, and (if the Reverse Engineer Associations option is selected) associations of each class.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="21197"></RBW-ANCHOR
>Files for reverse engineering</L.LABEL
><BI.BODY.INTRO>During reverse engineering, ObjectTeam prompts you to select the Forté files that you want to reverse engineer. The following illustrations show the Windows and UNIX dialog boxes.</BI.BODY.INTRO
>Reverse engineering creates CDs and CDMs based on the files that you select. Therefore, you generally want to reverse engineer all related files at the same time.</T.TIP
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Windows</SL.SUBLABEL
><BI.BODY.INTRO>In Windows, use the File Name and Files of Type fields to filter the list of files displayed.</BI.BODY.INTRO
><B.BODY>Round&truehy;trip engineering updates the ObjectTeam model based on the changes you have made to the generated source files. Use round&truehy;trip engineering to update the ObjectTeam model <CX5FX5FEMPHASIS>before</CX5FX5FEMPHASIS
> you regenerate the source files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose</L.LABEL
><B.BODY>The code generator generates code based on the ObjectTeam model. If you do not update the ObjectTeam model before regenerating the source files, the new source files do not include your changes. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>You generate Forté files. You then add a new method to a generated source file. If you do not update the ObjectTeam model, the model does not contain the operation that corresponds to the method. When you regenerate the source file, the code generator assumes that you <CX5FX5FEMPHASIS>deleted</CX5FX5FEMPHASIS
> the operation from ObjectTeam and, therefore, does not include the <CX5FX5FEMPHASIS>obsolete</CX5FX5FEMPHASIS
> method in the newly generated source file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes captured by round&truehy;trip engineering</L.LABEL
><B.BODY>If you have made the following types of changes to the generated source file, round&truehy;trip engineering updates the ObjectTeam model based on those changes:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>You select the generated (edited) source files that you are interested in and start round&truehy;trip engineering.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>ObjectTeam parses the selected files and compares the information in the files with the information in the ObjectTeam model.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>For each difference it finds, ObjectTeam proposes an action and prompts you for confirmation. For example:</CELLBODY
><CELLBODY><CX5FX5FINPUT>In class “Account”: delete attribute “Address”?</CX5FX5FINPUT
>Parsing the Generated (Edited) Source Files</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This section describes which changes to the generated source files are captured by round&truehy;trip engineering. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes to attributes</L.LABEL
><B.BODY>You can use Forté to add, delete, and modify attributes, virtual attributes, and constants in a generated Forté file. Round&truehy;trip engineering updates the attributes in the ObjectTeam model based on your changes. Do <CX5FX5FEMPHASIS>not</CX5FX5FEMPHASIS
> delete or modify the attributes that ObjectTeam generates to implement associations.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attribute Access property</SL.SUBLABEL
><B.BODY>Round&truehy;trip engineering sets an attribute’s Attribute Access property based on which attribute accessor methods are specified. When you add an attribute, no attribute accessor methods are specified; therefore, the round&truehy;trip engineering sets the Read and Write values of the attribute’s Attribute Access property to None.</B.BODY
><B.BODY>In ObjectTeam, change the Read and Write values of the attribute’s Attribute Access property to Public (or other appropriate values). When you regenerate the Forté file, ObjectTeam generates the attribute accessor methods.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Delete attribute accessors</SL.SUBLABEL
><B.BODY>If you delete an attribute, round&truehy;trip engineering identifies the attribute’s accessor methods as new methods and asks if you want to add them to the ObjectTeam model. Do <CX5FX5FEMPHASIS>not</CX5FX5FEMPHASIS
> add them to the model.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes to methods</L.LABEL
><BI.BODY.INTRO>You can add, delete, and modify the declarations of methods, events, and event handlers in Forté. Round&truehy;trip engineering updates the operations in the ObjectTeam model based on your changes. Do <CX5FX5FEMPHASIS>not</CX5FX5FEMPHASIS
> delete or modify the attribute accessor methods generated by ObjectTeam.</BI.BODY.INTRO
>You can change the code in the body of any method, event, or event handler. Such changes are ignored by round&truehy;trip engineering, but are preserved by the code generator when you regenerate the source files. </N.NOTE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Overloaded methods</SL.SUBLABEL
><B.BODY>If you have multiple methods with the same name, do not delete one and change the declaration of another at the same time. Delete one, run round&truehy;trip engineering, change the declaration of the other, and run round&truehy;trip engineering. This approach prevents potential errors in round&truehy;trip engineering.</B.BODY
> file in the Forté module defines the round&truehy;trip engineering rules used to identify attributes and methods during round&truehy;trip engineering. You can modify round&truehy;trip engineering by editing this customization file, as described in the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
> in the <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
>/etc directory controls what actions round&truehy;trip engineering proposes, as well as the default answers it supplies. To examine or modify the behavior of round&truehy;trip engineering, examine or modify the customization file. For more information, see the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to run round&truehy;trip engineering</L.LABEL
><LR.LIST.RESULT>ObjectTeam opens the Roundtrip Selected Files dialog box, compares the classes in the generated files to the classes in the Object Design phase, and then begins proposing actions and prompting you for confirmation.</LR.LIST.RESULT
><RBW-TEXTFLD TYPE="text">Code Generation Guide for Fort\x8e </RBW-TEXTFLD
></RBW-SYSOBJ
></C.CHAPTER.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Expert users can extend the Forté code generator by modifying the Tcl scripts that are supplied in the <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
>\<CX5FX5FFILE.NAME>tcl</CX5FX5FFILE.NAME
>\<CX5FX5FFILE.NAME>l_forte</CX5FX5FFILE.NAME
> directory. </B.BODY
><B.BODY>Editing these Tcl scripts, or writing new ones that add functionality to the code generator, requires a thorough knowledge of the OOPL model structure, Tcl commands, and the ObjectTeam Shell.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Modifying Tcl procedures</L.LABEL
><B.BODY>You can adapt existing methods of Object Tcl classes that are used in the code generation by redefining them in a user&truehy;defined Tcl file.</B.BODY
>Cayenne Software cannot support any provided Tcl scripts that you modify. Therefore, the scripts and their structures are not documented. If you choose to modify any Tcl scripts or procedures, you must have a thorough knowledge of the script’s structures to avoid introducing errors. </W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="22291" TYPE="XREF-TEXTCOPY">How Tcl is Used in the Code Generation&rbwtab;5–20</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="15580" TYPE="XREF-TEXTCOPY">Customizing Tcl Scripts Used for Code Generation&rbwtab;5–23</RBW-XREF
><B.BODY>This chapter provides information on the use of Tcl (Tool command language) in ObjectTeam. It does not provide an introduction to Tcl itself. If you want to become familiar with Tcl, try the following introductory book:</B.BODY
><LT.LIST.TEXT>John K. Ousterhout, <CX5FX5FTITLE>Tcl and the Tk Toolkit</CX5FX5FTITLE
><B.BODY>Tcl (Tool command language) is an interpretive command language that resembles C. By default all arguments are passed as strings. These strings are C&truehy;compatible. Tcl consists of:</B.BODY
><B.BODY>The Tcl core is a simple language that can be completely programmed. It provides a collection of commonly used features such as these:</B.BODY
><BI.BODY.INTRO>When the ObjectTeam shell executes a Tcl script file, it translates information from the repository, internal models, and <RBW-IDXTERM TERM1="code generation model" TERM2="and Tcl"></RBW-IDXTERM
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Refer to general Tcl documentation for details.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Calls to Tcl </CELLBODY
><CELLBODY>procedures</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>These procedures are stored in Tcl files. They become available when the file in which the procedure is defined is sourced.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Calls to methods of classes</CELLBODY
><CELLBODY>in the <RBWAUTO-0024>ObjectTeam</RBWAUTO-0024
><RBWAUTO-0024></RBWAUTO-0024
> </CELLBODY
><CELLBODY>models</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The classes of the ObjectTeam models (including the OOPL model and SQL model) are documented in <CX5FX5FTITLE>ObjectTeam Repository Interface Guide</CX5FX5FTITLE
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Besides methods of classes belonging to the <RBWAUTO-0024>ObjectTeam</RBWAUTO-0024
><RBWAUTO-0024></RBWAUTO-0024
> models, methods belonging to other built&truehy;in classes can also be called. Refer to the <CX5FX5FTITLE>ObjectTeam Repository Interface Guide</CX5FX5FTITLE
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>These commands are built&truehy;in to otsh and otk. You can use these commands, but you cannot edit or view them like Tcl procedures. Refer to the <CX5FX5FTITLE>ObjectTeam Repository Interface Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for details. </CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="35220"></RBW-ANCHOR
>Which Tcl files are used?</L.LABEL
><B.BODY>Tcl procedures used for code generation are stored in Object Tcl script files. During code generation, these scripts are interpreted and executed by the ObjectTeam shell (otsh). When you use Utilities | Import From Previous Phase in the Browser at the system level of the Implementation phase, otsh interprets the Object Tcl code in the Tcl file tcl\l_forte\forteimpor.tcl. In the implementation of these methods, Tcl methods from other classes are called.</B.BODY
><B.BODY>Most of the Tcl script files that the Forté code generator uses are located under the <CX5FX5FTERM>M4_home</CX5FX5FTERM
> directory in tcl\l_forte\*.tcl. The Tcl script files fstorage.tcl and caynutil.tcl in the tcl directory contain utility procedures that are also used.</B.BODY
>Customizing Tcl Scripts Used for <RBW-IDXTERM TERM1="code generation" TERM2="adapting"></RBW-IDXTERM
>Code Generation</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>User&truehy;defined Tcl files</L.LABEL
><B.BODY>Because of the open character of Tcl, you can redefine the existing Object Tcl methods of the Tcl scripts, if you want to adapt the code generation to your needs and circumstances. You can include your own properties, control flow keywords, and section keywords in the code generation this way. You can even build your own code generator by creating your own Tcl scripts. </B.BODY
>Note that existing Object Tcl classes cannot be redefined. However, you can add new, user&truehy;defined Object Tcl classes.</W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="37212"></RBW-ANCHOR
>Where to store user&truehy;defined Tcl procedures</L.LABEL
><B.BODY>The Tcl script files used for the default code generation are stored in the file system. They can be found in the following directory:</B.BODY
><B.BODY>If you want to adapt the default code generation, you can edit the Tcl files in this directory, but it is better to modify copies of the original files. There are several ways available to make otsh use user&truehy;defined files. These ways are briefly discussed in this section. </B.BODY
><B.BODY>You can overrule existing Tcl files or you can extend them by creating new Tcl files with new user&truehy;defined Tcl procedures and methods, or redefinitions of existing methods. The ways to do that are also covered in this section.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Storing Tcl files in the same System as where the code is generated</L.LABEL
><B.BODY>One of the available file types on the system level of the Implementation phase is Tcl. You can create new files of this type and redefine methods of existing Object Tcl classes in such a file. During code generation, otsh sources all files of the type Tcl in the current system, regardless of their names.</B.BODY
><RBW-PARABODY>Select Tcl as the file type, specify a name for the Tcl file (without the extension .tcl), and click OK.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>You can enter the name of an existing Tcl file used for code generation or any other name. If you enter an existing name, the original Tcl file is replaced by this new file during code generation.</LT.LIST.TEXT
><RBW-PARABODY>Edit and save the new Tcl file.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The next time you generate code (by using Utilities | Import From Previous Phase) the new Tcl file is sourced by otsh.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Storing Tcl files in a system Tcl</L.LABEL
><B.BODY>If you do not want to store user&truehy;defined Tcl files in the same system in which your code is generated, you can create a system called Tcl and store your user&truehy;defined Tcl files in there. Any Tcl file that is defined in such a system is sourced during code generation. You can use this mechanism for user&truehy;defined Tcl files or for user&truehy;defined Tcl files that are meant to replace existing ones.</B.BODY
><RBW-PARABODY>Select Tcl as the file type, specify a name for the Tcl file (without the extension <CX5FX5FFILE.NAME>.tcl</CX5FX5FFILE.NAME
>), and click OK.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>You can enter the name of an existing Tcl file used for code generation or any other name. If you enter an existing name, the original Tcl file is replaced by this new file during code generation.</LT.LIST.TEXT
><B.BODY>If you want to test a customized Tcl file before you add it to a system in ObjectTeam, you can create the Tcl file in your file system and feed it to otsh outside the ObjectTeam environment. </B.BODY
><B.BODY>See the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for details on how to start otsh from the command line.</B.BODY
><B.BODY>When the Tcl file has reached its final state, you can decide to add it to a system in ObjectTeam, as described above. </B.BODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="34064" TYPE="XREF-TEXTCOPY">Specifying Accessibility of Data Attributes</RBW-XREF
><CHAPTERNONUM><CN.CHAPTER.NOX23>About This Manual<RBW-SYSOBJ TYPE="MIFmarker"><RBW-DATAFLD TYPE="number">0</RBW-DATAFLD
><RBW-TEXTFLD TYPE="text">Code Generation Guide for Java</RBW-TEXTFLD
></RBW-SYSOBJ
></CN.CHAPTER.NOX23
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>About this manual</L.LABEL
><B.BODY>The <CX5FX5FTITLE>ObjectTeam Code Generation Guide for Java</CX5FX5FTITLE
> contains information specific to the Java<CX5FX5FSUPERSCRIPT>™</CX5FX5FSUPERSCRIPT
> programming language. This manual includes all the information that you need to generate Java code from ObjectTeam. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisites</L.LABEL
><B.BODY>This guide is intended for experienced users of ObjectTeam and the analysis and design method it supports. This guide explains how to map ObjectTeam diagrams to Java code; it does not teach you the Java language.</B.BODY
><B.BODY>To customize or extend the capabilities of the Java code generator, you must have a thorough understanding of the ObjectTeam Shell, the Object&truehy;Oriented Programming Language (OOPL) model structure, and the Tool Command Language (Tcl) commands.</B.BODY
> provides the menu items, the properties and the Tcl code required to use the Java Code Generator. Therefore, before moving to the Object Design phase, make sure this module is active.</B.BODY
><B.BODY>You can check if a module is active on a particular Browser level by selecting Utilities | Show Active Modules on that level.</B.BODY
> for details on how to activate a module.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Object Design and Implementation</L.LABEL
><B.BODY>This chapter describes the tasks of the Object Design phase. <RBW-XREF REFID="30750" TYPE="XREF-TEXTCOPY">Chapter 2, Generating Code</RBW-XREF
>, describes the tasks of the Implementation phase. You work iteratively in these two phases to generate code and complete your application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose of object design</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="Object Design" TERM2="activities in this phase"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Object Design" TERM2="development phase in ObjectTeam project"></RBW-IDXTERM
>In ObjectTeam, the CDs (and the objects defined in the CDs) provide all the source data needed for code generation. The goal of object design is to add to the CDs all the data required for successful code generation. For example, you add properties (such as the Attribute Access property, which establishes read/write access to an attribute) and incorporate language&truehy;specific syntax (such as data type specifications for attributes and the arguments of operations).</B.BODY
><B.BODY>You might also add data to diagrams other than CDs. The code generator does not use oter diagrams, but they are useful for describing the behavior of classes, their attributes and operations.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="36358" TYPE="XREF-TEXTCOPY">Refining the Class Diagrams&rbwtab;1–3</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="15189" TYPE="XREF-TEXTCOPY">Hints and Tips for Effective Code Generation&rbwtab;1–6</RBW-XREF
>Introduction<RBW-IDXTERM TERM1="Class Association Diagram"></RBW-IDXTERM
></L.LABEL
><B.BODY>The CDs and the objects defined in the CDs provide all the source data needed for code generation. <RBW-IDXTERM TERM1="Class Association Model"></RBW-IDXTERM
>These diagrams distinguish the classes in a system and describe their identities and their features. In the Object Design phase, you must add to the CDs sufficient detail for successful code generation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using data from diagrams other than CDs</L.LABEL
><B.BODY>Diagrams other than the CDs are not used as input for code generation. However, they contain valuable information that can help you to complete and verify the CDs. The following table summarizes how you can use these other diagrams to help you find important objects that are not yet in the CDs.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>STD state names (enumerated list as an attribute value)</CELLBODY
><CELLBODY>STD condition on an event</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Classes</L.LABEL
><B.BODY>When you work on CDs, you focus on the implementation of classes. The CD must include all classes and the associations (and inheritance) between classes. In the Object Design phase, you may introduce new classes to ease implementation and improve performance.</B.BODY
><B.BODY>You must include all attributes and operations for each class. The attributes of a class map to the attributes of the class type. The operations of the class map to functions and procedures of the class type. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>External classes</L.LABEL
><B.BODY>A class must have at least one attribute or one operation to generate code. Classes that have no attributes or operations are translated as external classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Associations</L.LABEL
><B.BODY>You must define the associations between all classes, including any constraints.</B.BODY
><B.BODY>Role names must also be defined. Every association needs at least one role name. Every mandatory association must have a role name. Without a role name, you cannot use the association.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role names in Analysis and System Design</SL.SUBLABEL
><B.BODY>In the Analysis and System Design phases, role names distinguish a class by showing the role the class is playing in a relationship with another class. Each role name defines the role of the class within the context of a single association. It also indicates the use and direction of the association toward the class that plays a role. For example, a manager can be both the boss of a coworker and an employee of a company.</B.BODY
>Role names in Object Design and Implementation</SL.SUBLABEL
><BI.BODY.INTRO>In the Object Design and Implementation phases, the use of role names is extended. The code generator creates access methods for an association if the class at the far end has a role name for the association. In the previous example, the code generated for Coworker includes access methods for Manager; the code generated for Manager does not include access methods for Coworker.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attributes</L.LABEL
><B.BODY>You must specify each attribute completely, including its data type. The way to specify a data type for an attribute is to include the type in the class symbol, for example:</B.BODY
><B.BODY>Data types of attributes and arguments can be standard ObjectTeam types, standard types for your target language, or class types and derived types. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Operations</L.LABEL
><BI.BODY.INTRO>You must specify each operation completely. This includes specifying such aspects as:</BI.BODY.INTRO
><RBW-PARABODY>Any parameters, as well as their data types</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Properties</L.LABEL
><BI.BODY.INTRO><RBW-IDXTERM TERM1="property" TERM2="using - to specify implementation details"></RBW-IDXTERM
>In the Object Design phase, a variety of properties allow you to specify many implementation details. <RBW-IDXTERM TERM1="property" TERM2="using - to specify implementation details"></RBW-IDXTERM
>These details are incorporated in the final code.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Checking</L.LABEL
><B.BODY>The last activity in object design is to use Check | Global Model to check the CDs. The CDs must be error&truehy;free before they can be used for code generation. See the <CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for more information about the Check utility.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</L.LABEL
><B.BODY><RBW-XREF REFID="10890" TYPE="XREF-TEXTCOPY">Chapter 3, Mapping Modeling Data to Java</RBW-XREF
>, describes how the ObjectTeam model is translated into code. You can use this information to help you complete the CDs in the Object Design phase.</B.BODY
>Hints and Tips for Effective Code Generation</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Following are a few tips for effective code generation. It may be helpful to be aware of these items as you prepare for code generation, and then again as you generate and regenerate your source files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Understanding the translations</L.LABEL
><B.BODY>Before generating code, read through this guide. It contains detailed information about the data that you must include in your CDs for successful code generation. It also explains how the code generator translates the ObjectTeam model into source code files, what changes you can make to the source code files, and how to regenerate them without losing your changes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Naming conventions</L.LABEL
><B.BODY>Agree upon and follow a naming convention for projects, configurations, systems, classes, special characters, and so on. In addition, bear in mind that spaces between words (in class names, for instance) are deleted by ObjectTeam code generators.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing code generation</L.LABEL
><B.BODY>The code generators execute Tcl scripts that translate a model into source code. You can modify these scripts or create your own.. Always use caution when customizing or creating scripts; such scripts are not supported.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using multiple languages in a single application</L.LABEL
><B.BODY>Each ObjectTeam code generator is designed to generate code for one language. You can create an application that uses multiple languages by using different code generators to generate code for different systems; however, the generated code is not integrated across systems. </B.BODY
><B.BODY>The ObjectTeam code generators are not designed to provide language integration. To build an application that uses multiple languages, you must do the following: </B.BODY
>When you create a separate ObjectTeam system for each language&truehy;specific subsystem, be sure to define your classes in the appropriate system. When ObjectTeam generates code for the current system, it generates code for the classes that are defined in that system. It does not generate code for classes referenced, but not defined in, the current system; such classes are treated as external classes.</N.NOTE
><RBW-TEXTFLD TYPE="text">Code Generation Guide for Java</RBW-TEXTFLD
></RBW-SYSOBJ
></C.CHAPTER.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>The ultimate goal of modeling an application is to produce code that implements it. In ObjectTeam, you can generate a significant portion of the code automatically, and then complete it by adding the details that are not specified in the model.</B.BODY
><RBW-PARABODY>Only the CDs (and the objects defined in the CDs) are used for code generation. Therefore, before code generation, it is critical that the CDs be fully defined, as described in <RBW-XREF REFID="31423" TYPE="XREF-TEXTCOPY">Chapter 1, Preparing Your ObjectTeam Model for Code Generation</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Conversion from previous versions</L.LABEL
><B.BODY>If you have systems in the Object Design phase that have been used with version 5.x of the Java code generator, you can use them with version 6.x also. No conversion is necessary.</B.BODY
><B.BODY>If you have systems in the Object Design phase that have been used with version 4.x , you must upgrade them to version 5.x. You can then use them with either version 5.x or version 6.x. The upgrade utility is available with version 5.x of the Java code generator and is described in the documentation for that version.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Steps in code generation</L.LABEL
><B.BODY>The following table provides an overview of the code generation process. This chapter describes each step in greater detail.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Generate Java files. During this step, ObjectTeam generates Java source files on System level in the Implementation phase. </CELLBODY
> System level in the Implementation phase is fundamentally different than system level in other phases. The system files in the Implementation phase are source files, not diagram files.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Configure the Java environment, copying required source files from the ObjectTeam installation directories to the appropriate user environment directories.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Edit the source files. ObjectTeam generates a large portion of your application code, but not all of it. In this stage, you finish writing the application code.</CELLBODY
><CELLBODY>Changes you make to the source files are not lost. When you regenerate the source files, the code generator recognizes your changes and transfers them to the newly generated files. </CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Run the application and test it. If necessary, correct the source files, the model, or both; regenerate the files and return to step 3.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Illustration of code generation</L.LABEL
><BI.BODY.INTRO>The following illustration shows how ObjectTeam generates code, including the names of the Tcl scripts that it uses. The CDs and CDMs shown at the top are in the Object Design phase. The .class files shown at the bottom can be run as Java applications or applets.</BI.BODY.INTRO
><B.BODY>The scripts written for code generation retrieve information from the code generation models, format this information, and write the results to source code files. Code generation models are built from the CDs in the Object Design phase.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Code regeneration</L.LABEL
><B.BODY>Code generation is an automated process that generates Java source files. ObjectTeam ensures that </B.BODY
><RBW-PARABODY>Changes that you make to the generated files are preserved when you regenerate the files.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>For more information, see <RBW-XREF REFID="12832" TYPE="XREF-TEXTCOPY">Regenerating Code</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Java program structure </L.LABEL
><B.BODY>You can control the structure of your Java program by editing class properties in ObjectTeam. This allows you to import from external Java packages such as those included in the Java Development Kit (JDK) 1.1.</B.BODY
><B.BODY>For more information, see <RBW-XREF REFID="38413" TYPE="XREF-TEXTCOPY">Defining Java Program Structure</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Compiling and running Java code</L.LABEL
><B.BODY>After generating and editing your Java source files, you can compile and run them from within ObjectTeam. You can run the compiled Java files as either applications or applets.</B.BODY
><B.BODY>For more information, see <RBW-XREF REFID="39005" TYPE="XREF-TEXTCOPY">Compiling and Running Generated Files</RBW-XREF
><B.BODY>When you generate source files, the code generator uses the CDs and CDMs that are in the Object Design phase to create Java source files in the Implementation phase. At System level of the Implementation phase, you can then refine the source code and complete the application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Implementation Phase is different</L.LABEL
><B.BODY>The System level of the Implementation phase is fundamentally different from System level of any other phase. In the Implementation phase, the System files are Java files. In other phases, the System files are ObjectTeam diagrams.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generate code on Phase or System level</L.LABEL
><B.BODY>You can generate code on the Implementation Phase level or on the System level of the Implementation phase.</B.BODY
><RBW-PARABODY>On the <CX5FX5FBULLET.EMPHASIS>Implementation Phase level</CX5FX5FBULLET.EMPHASIS
>, you can generate code for one or more systems. This creates a matching system in the Implementation Phase that contains the generated source files. To regenerate code for an existing system, use System level.</RBW-PARABODY
><RBW-PARABODY>On the <CX5FX5FBULLET.EMPHASIS>System level of the Implementation phase</CX5FX5FBULLET.EMPHASIS
>, you can (re)generate code for the entire system, or regenerate selected source files.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>Typically, you use Implementation Phase level to generate code for a system initially and System level to regenerate code subsequently.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to generate code on Implementation Phase level</L.LABEL
> to generate code for one or more systems in the Object Design phase. You can select only systems that do not yet exist in the Implementation phase.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>ObjectTeam opens a Monitor window for displaying log messages, then generates the source files.</LR.LIST.RESULT
> to (re)generate code for all classes that are defined in this system.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>ObjectTeam opens a Monitor window for displaying log messages, then generates the source files. The following illustration shows the Monitor window after importing a system.</LR.LIST.RESULT
> directory, where <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
> is the file path for your generated files. For more information on the user environment, see the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
><B.BODY>The following illustration shows how the source files appear in the Browser.</B.BODY
><RBW-IDXTERM TERM1="Update User Environment (Utilities menu)"></RBW-IDXTERM
>Update user environment</SL.SUBLABEL
><B.BODY>Utilities | Update User Environment synchronizes your user environment with the repository. This can be particularly useful if you are working on two machines, and the user environment of each is set to a local drive. When you move between machines, you can use Utilities | Update User Environment to update the local drive of the current machine.</B.BODY
> describes how to generate code for systems in the Implementation phase.</B.BODY
><B.BODY>When you generate code for a system in the Implementation phase, the Java code generator imports the Object Oriented Programming Language (OOPL) model and translates the information into Java source code files. This section describes that process.<RBW-IDXTERM TERM1="code" TERM2="generating"></RBW-IDXTERM
><B.BODY>The OOPL Model, which is generated from the CDs in the Object Design phase, contains information used to generate code. The objects in this model are organized in such a way that code can be generated easily.</B.BODY
> provides a detailed description of the classes in the OOPL Model.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How ObjectTeam converts the OOPL Model</L.LABEL
><B.BODY>To convert an OOPL Model, the ObjectTeam Shell (otsh) executes the Tcl script <RBW-IDXTERM TERM1="import.tcl"></RBW-IDXTERM
>import.tcl. It loads the OOPL model into memory and translates the information into source code. The ObjectTeam shell recognizes elements such as classes, data types, associations and methods. </B.BODY
><B.BODY>The Tcl script import.tcl activates, the Tcl script javimport.tcl, which contains Tcl procedures to retrieve information from the OOPL model and other internal models, format the file, and write it to the appropriate source files. javimport.tcl uses other Tcl scripts that use other Tcl scripts as well, and so on.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated files</L.LABEL
><B.BODY>By default, the Java code generator generates a classname<CX5FX5FFILE.NAME>.</CX5FX5FFILE.NAME
>java file for each class imported into the Implementation phase. You can override this default using ObjectTeam’s class properties, as described in <RBW-XREF REFID="26371" TYPE="XREF-TEXTCOPY">Mapping Classes</RBW-XREF
><RBW-PARABODY>Configuring your Java development environment, which ensures that you can compile and run Java applications on your machine.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>User environment files<RBW-IDXTERM TERM1="Queue class" TERM2="copying to user environment"></RBW-IDXTERM
><RBW-IDXTERM TERM1="example.html" TERM2="copying to user environment"></RBW-IDXTERM
></L.LABEL
><B.BODY>Configuring your user environment copies the following files into the user_environment folder (this is the path for generated files, as described in the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
>. The Java code generated for an ordered association in ObjectTeam references the Queue class. The Queue.java file contains the source code for the Queue class.</RBW-PARABODY
>. To run a compiled Java file as an applet, you need an HTML file that invokes the Java file. The example.html file provides the necessary HTML code.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to configure the user environment<RBW-IDXTERM TERM1="user environment" TERM2="configuring"></RBW-IDXTERM
><RBW-PARABODY>Any Integrated Development Environment (IDE) for the Java programming language, such as Symantec Cafe, Sun’s Java WorkShop (JWS), and Borland C++</RBW-PARABODY
><RBW-PARABODY>Setting the variable to include your current working directory and the directory containing the JAVA API packages allows you to use any of the classes you have designed in the current system with the JAVA API packages. </RBW-PARABODY
><RBW-PARABODY>If you have created your own classes in other folders or want to access classes in other ObjectTeam systems, you must also add these directory paths to the CLASSPATH variable. Setting these paths enables the Java class loader to access and import these classes. </RBW-PARABODY
><B.BODY>When code generation is successful, you can relate each generated Java file to a specific class in a CD of the Object Design phase.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing .java files</L.LABEL
><B.BODY>The generated .java files serve as framework files. They contain the code that implements the classes as defined in the ObjectTeam model. However, the ObjectTeam model does not define the application completely, so you must edit the .java files to complete the application.</B.BODY
>A method declaration is generated for each operation defined for the ObjectTeam class. The method body is empty and a regeneration marker appears at the end of the method. Code that you enter in the method body is preserved when you regenerate the .java file.</RBW-PARABODY
><RBW-PARABODY>A default constructor is generated for each class. The method body may contain generated statements, as well as the following comments:</RBW-PARABODY
></LB.LIST.BULLET
><EM.EXAMPLE.MONO>//Start user code section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>//End user code section</EM.EXAMPLE.MONO
><LT.LIST.TEXT>Code that you enter between the comments is preserved when you regenerate the .java file.</LT.LIST.TEXT
><RBW-PARABODY>In the information area, double&truehy;click the source file that you want to edit, or select the source file and then select File | Edit.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam creates a temporary file containing the <CX5FX5FTITLE>working</CX5FX5FTITLE
> version of the selected .java file and opens that file in your default text editor. After you have edited, saved, and closed the text file, ObjectTeam stores the updated text file back in the repository and the user environment, and then deletes the temporary file.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Update diagrams</L.LABEL
><B.BODY>Depending on the type of additions you have made to the source files, you may need to edit the CDs to reflect your changes. For example, if you add a method to the code, you must add the same operation to the class in the ObjectTeam model. If you modify the model, be sure to use Check | Global Model to check the updated diagrams before regenerating the source files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>You can generate code for a Java application or applet. This section provides examples of edited code for each.</B.BODY
>The following ObjectTeam class generates a simple Java application that displays a “Hello World” text string. A Java application requires a static method named main, as defined in this class.</B.BODY
>The following ObjectTeam CD generates a simple Java applet that displays a “Hello World” text string. A Java applet requires that the class being executed be a subclass of the Applet class, as shown here.</B.BODY
><B.BODY>The Applet class is an external class; it is defined in the Java Development Kit (JDK) 1.0. Therefore, you edit the Applet class properties to indicate that it is an external class.</B.BODY
><RBW-PARABODY>Make sure that the environment is properly configured for Java. see <RBW-XREF REFID="27027" TYPE="XREF-TEXTCOPY">Configuring the Java Environment</RBW-XREF
><RBW-PARABODY>Target | Compile With Options | All (or Target | Compile With Options | Selected), and then specify the compiler options in the dialog box that appears</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>ObjectTeam opens an execution window and compiles the files.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Two ways to run a compiled file</L.LABEL
><B.BODY>You can run a compiled file in two ways:</B.BODY
>To run an applet, you edit and run the file example.html provided with ObjectTeam. (This file is copied into your user environment when you configure your ObjectTeam environment for Java, as described in <RBW-XREF REFID="27027" TYPE="XREF-TEXTCOPY">Configuring the Java Environment</RBW-XREF
>If the file is empty, you may have forgotten to configure your Java environment for this system. See the instructions in <RBW-XREF REFID="27027" TYPE="XREF-TEXTCOPY">Configuring the Java Environment</RBW-XREF
><RBW-PARABODY>Edit the following line to specify the name of the class that is in the compiled Java file (a compiled .java file is a .class file).</RBW-PARABODY
><RBW-PARABODY>Select Target | Run | Applet Viewer. </RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam opens an execution window and starts the appletviewer with the selected html file, which runs your compiled .java file.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Sample example.html file</L.LABEL
><B.BODY>Following is the text of the file example.html. The highlighted text shows the changes you would make.</B.BODY
><EW.EXAMPLEW><HTML></EW.EXAMPLEW
><EW.EXAMPLEW><HEAD></EW.EXAMPLEW
><EW.EXAMPLEW><TITLE> A simple program </TITLE></EW.EXAMPLEW
><B.BODY>ObjectTeam supports incremental development. You can generate code from your models, edit that code, and regenerate the code without losing your changes. You can work with models during design and with code during implementation, shifting your focus between the two as necessary.</B.BODY
><B.BODY>It is important that you make changes where appropriate.</B.BODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Change the code</CX5FX5FBULLET.EMPHASIS
> when you are adding code that is not generated by ObjectTeam (for example, method bodies) or when you are making local changes to the code (for example, adding a missing attribute or operation to a class).</RBW-PARABODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Change the model</CX5FX5FBULLET.EMPHASIS
> when you are changing the structure of the model (for example, changing the class hierarchy or class associations) or when you are making global changes to the code (for example, changing the name of a class, attribute, or operation).</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing generated files</L.LABEL
><B.BODY>The generated Java files are framework files that need some additions before they can be compiled and run. Comments in the file indicate where to add code, as described in <RBW-XREF REFID="25511" TYPE="XREF-TEXTCOPY">Editing Generated Source Files</RBW-XREF
>. When you regenerate a Java file, the code generator transfers the user&truehy;edited sections from the old file to the newly generated file. </B.BODY
>The code generator preserves only the comment&truehy;delimited areas of the generated Java file. Changes you make to other areas of the generated Java file are lost when you regenerate the file.</N.NOTE
>If you modify the ObjectTeam model, you typically regenerate the Java source files. As described above, regenerating the files preserves your changes to the original file.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Obsolete code sections</SL.SUBLABEL
><B.BODY>If you rename, delete, or change the signature of an operation in the model, the matching method in the generated Java file is no longer correct. When you regenerate the file, ObjectTeam displays a message warning you that the method is being moved to the obsolete code section. It then appends the original method to the end of the generated file, as shown in the following example:</B.BODY
><EW.EXAMPLEW>// Start obsolete code section &truehy;&truehy; Remove this line</EW.EXAMPLEW
><EW.EXAMPLEW> public void paint(Graphics g) {</EW.EXAMPLEW
>Modeling Data to Java<RBW-SYSOBJ TYPE="MIFmarker"><RBW-DATAFLD TYPE="number">0</RBW-DATAFLD
><RBW-TEXTFLD TYPE="text">Code Generation Guide for Java</RBW-TEXTFLD
></RBW-SYSOBJ
></C.CHAPTER.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This chapter describes how ObjectTeam model information maps to Java code. It provides examples of CDs and the results produced when you generate Java code.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><B.BODY>An ObjectTeam class symbol represents a compilation unit and declares a class. The class is also used to map a Java class or interface. The attributes of the class map to the Java class variables or instance variables. The operations of the class map to Java methods.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>.java files</L.LABEL
><B.BODY>You can use ObjectTeam class properties to determine the program structure of the generated Java code. By default, when you import your object designs into the Implementation phase, the Java code generator produces a separate classname.java file for each class symbol that you define in a CD. It then lists these files under the Type heading in the information area of the Browser.</B.BODY
><B.BODY>You can repackage the Java code into a smaller number of files, combining code for several classes into a single file. To do so, set the appropriate class properties, as described in <RBW-XREF REFID="38413" TYPE="XREF-TEXTCOPY">Defining Java Program Structure</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Constructors</L.LABEL
><B.BODY>Generated Java classes can have one or more constructors. By default, each generated Java class includes a default constructor.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class properties</L.LABEL
><B.BODY>You use class properties to provide input to the code generator. This section describes how to edit class properties and the effect of each property.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section contains the following topics:</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="17596" TYPE="XREF-TEXTCOPY">Specifying Class or Interface Generation&rbwtab;3–7</RBW-XREF
>When you map an ObjectTeam class to a Java class, you also need a constructor for the class. You can generate a class constructor in the following ways:</B.BODY
><RBW-PARABODY>Specify a $create operation without parentheses or parameters. The code generator creates a default constructor for the class. (This is useful if you want to generate both a default constructor and one or more user&truehy;defined constructors for a class.)</RBW-PARABODY
><RBW-PARABODY>Specify a $create operation with parameters of your choice. The code generator creates a user&truehy;defined constructor for the class.</RBW-PARABODY
> describes code generation for operations other than $create.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Parameter list</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Default constructor</SL.SUBLABEL
><B.BODY>If a class has no $create operation or has a $create operation without parentheses or parameters, the code generator creates a default constructor. The parameter list of the default constructor contains the following:</B.BODY
>If the association has a qualifier at the far end, and both ends of the association have role names, the qualifier is also included in the parameter list. See the examples.</N3.NOTE.3
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>User&truehy;defined constructor</SL.SUBLABEL
><B.BODY>If a class has a $create operation that includes a parameter list, the code generator creates a user&truehy;defined constructor even if the parameter list is empty. The parameter list of a user&truehy;defined constructor is the one specified for the $create operation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><BI.BODY.INTRO>The following code excerpt shows a default constructor and a user&truehy;defined constructor.</BI.BODY.INTRO
><RBW-PARABODY>A typedef class is any ObjectTeam class that has exactly one attribute, no associations that generate code, no operations, and no superclasses.</RBW-PARABODY
><RBW-PARABODY>A generic typedef class is any ObjectTeam class that has exactly one association that generates code, no data attributes, no operations, no superclasses, and no subclasses.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>The Java code generator does not automatically generate a default constructor for typedef and generic typedef classes. To generate a default constructor for such a class, add a $create() operation to the class.</B.BODY
><B.BODY>In the Object Design phase, you define properties of a class that control its implementation and accessibility within its own Java package. The code generated for a class is based on its properties. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to edit class properties<RBW-IDXTERM TERM1="Edit Properties (Item menu)" TERM2="for class"></RBW-IDXTERM
><RBW-PARABODY>Use the Class or Interface box on the Class tab to specify whether the class maps to Java class or interface, or whether the code generator should ignore it.</RBW-PARABODY
>Use the Text tab of the Edit Properties dialog box to insert a comment in the generated code. The comment appears immediately before the class or interface declaration.</B.BODY
>. ObjectTeam does not generate code for this class. A class in ObjectTeam represents classes or interfaces that exist outside of the system; for example, the Java Applet class or Runnable interface in the JDK 1.0.</RBW-PARABODY
>. ObjectTeam generates a Java class, which extends the Object class and its implementation. The Object class is the root class from which all other Java classes are derived. Java also uses the extends statement to implement generalization, as described in <RBW-XREF REFID="12952" TYPE="XREF-TEXTCOPY">Mapping Inheritance</RBW-XREF
><B.BODY>Assign one of the following access properties to a class or an interface using the Access box on the Class tab of the Edit Properties dialog box.</B.BODY
>Modifier properties alter the behavior of classes. To assign a modifier to a class or an interface, choose one of the values listed below from the Modifier list on the Class tab of the Edit Properties dialog box. (If you are not familiar with editing class properties, see <RBW-XREF REFID="21544" TYPE="XREF-TEXTCOPY">Editing Class Properties</RBW-XREF
>Java uses packages to organize collections of classes that work as a unit to perform a service. A package is the highest level of the Java program structure, followed by one or more compilation units (a collection of classes, one of which must be public), followed by class at the lowest level of the structure.</B.BODY
><B.BODY>A compilation unit must contain one class declaration that is accessible publicly. A compilation unit may contain other class declarations that are not public and that have file scope only. For each ObjectTeam class symbol, one compilation unit that has public accessibility is generated. </B.BODY
>Use the following fields on the Package tab on the Edit Properties dialog box to define the Java program structure. (If you are not familiar with editing class properties, see <RBW-XREF REFID="21544" TYPE="XREF-TEXTCOPY">Editing Class Properties</RBW-XREF
>. If this field is empty or contains the name of the current class, the generated code for this class is written to the source file classname.java, where classname is the name of the current class.</RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>If this field contains a class name other than the name of the current class, the generated code for this class is written to the source file classname.java, where classname is the name specified in this field. This allows you to include the generated code for multiple classes in a single compilation unit (a single Java source file). </LT.LIST.TEXT
>The Import Packages, Import Types, and Import On&truehy;Demands properties are obsolete. They are provided for compatibility with previous releases, as described in <RBW-XREF REFID="10552" TYPE="XREF-TEXTCOPY">Obsolete boxes</RBW-XREF
>.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Import statements</L.LABEL
><B.BODY>The Java code generator also uses the Package Statement property to generate the required Import statements for the generated .java file. </B.BODY
><B.BODY>When generating a .java file for the current class, the code generator checks the Package Statement property of each external class (or interface) that is used directly by the current class. If the Package Statement of the external class contains a text string, the code generator uses that text string to generate an Import statement in the .java file of the current class. If the Package Statement of the external class does not contain a text string, no Import statement is generated.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Reverse engineering</SL.SUBLABEL
><B.BODY>Reverse engineering populates the Package Statement property of the classes that it creates. If you use the following technique, ObjectTeam generates most of the Import statements that you need:</B.BODY
><RBW-PARABODY>Create an ObjectTeam system for each Java package that you need. Use reverse engineering, as described in <RBW-XREF REFID="26044" TYPE="XREF-TEXTCOPY">Reverse Engineering</RBW-XREF
>, to populate the ObjectTeam system with the classes defined in the Java package.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>For each class in the Java package, reverse engineering creates an ObjectTeam class and sets its Package Statement property appropriately.</LR.LIST.RESULT
><RBW-PARABODY>Create one or more ObjectTeam systems for the application that you are developing. When necessary, reference the ObjectTeam classes that represent the classes defined in the Java packages.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>Because the referenced classes are not defined in the current system, the code generator includes the appropriate Import statements.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>User&truehy;defined Import statements</L.LABEL
><B.BODY>Occasionally, you may want to add more Import statements to a generated .java file. To do so, place them beneath the following comment in the generated file:</B.BODY
><EM.EXAMPLE.MONO>// User import section</EM.EXAMPLE.MONO
><B.BODY>The code generator preserves these Import statements when you regenerate the .java file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="10552"></RBW-ANCHOR
>Obsolete boxes</L.LABEL
><B.BODY>The current release of the Java code generator generates Import statements automatically. In previous releases, you used the following properties to generate Import statements:</B.BODY
>. If this box contains a text string, the generated code for this class includes statement that imports all classes in the specified package: </RBW-PARABODY
><B.BODY>The current release of the Java code generator uses these properties to generate user&truehy;defined Import statements. These properties will not be supported in future releases.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><BI.BODY.INTRO>To generate the Page class in the same source file as the Document class, edit properties for the Page class. Enter the class name Document in the Source File box, as shown in the following dialog box.</BI.BODY.INTRO
>ObjectTeam maps data attributes to Java variables or class variables.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="29666"></RBW-ANCHOR
>Attribute syntax</L.LABEL
><B.BODY>In ObjectTeam, you use the following syntax to specify data attributes for a class:</B.BODY
><E.EXAMPLE>[ $ | / ] name : type = initial&truehy;value</E.EXAMPLE
><B.BODY>where</B.BODY
><LT.LIST.TEXT>$ indicates a class attribute</LT.LIST.TEXT
><LT.LIST.TEXT>/ indicates a derived attribute</LT.LIST.TEXT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attribute maps to instance variable</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="variable, in Java"></RBW-IDXTERM
>By default, a data attribute maps to an instance variable. A distinct variable known by that name is associated with every instance of the class or its subclasses.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The following code excerpt shows the translation of the Account.Amount attribute:</B.BODY
>A class attribute maps to a Java class variable. There is exactly one variable of that name, no matter how many instances (possibly zero) of the class are created. In Java, a class variable is indicated by the <CX5FX5FPROCEDURE.NAME>static</CX5FX5FPROCEDURE.NAME
> modifier.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The following code excerpt shows the translation of the Account.$Amount attribute:</B.BODY
><RBW-IDXTERM TERM1="default value, for attribute"></RBW-IDXTERM
><RBW-IDXTERM TERM1="initial value, for attribute"></RBW-IDXTERM
>You can specify a default value for any attribute. You must specify a default value for any attribute that has the Final modifier property. See <RBW-XREF REFID="18563" TYPE="XREF-TEXTCOPY">Specifying Modifiers for Data Attributes</RBW-XREF
> for more information.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attribute properties</L.LABEL
><B.BODY>You use attribute properties to provide input to the code generator. This section describes how to edit attribute properties and the effect of each property.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section contains the following topics:</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="29648" TYPE="XREF-TEXTCOPY">Specifying Comments for Data Attributes&rbwtab;3–18</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="35486" TYPE="XREF-TEXTCOPY">Specifying Accessibility of Data Attributes&rbwtab;3–19</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="21279" TYPE="XREF-TEXTCOPY">Specifying Access Methods for Data Attributes&rbwtab;3–21</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="18563" TYPE="XREF-TEXTCOPY">Specifying Modifiers for Data Attributes&rbwtab;3–22</RBW-XREF
><B.BODY>The standard data types are defined by the <RBW-IDXTERM TERM1="stand_types customization file"></RBW-IDXTERM
>stand_types customization file. These data types are valid in the Object Design phase.</B.BODY
><B.BODY>The translation between standard data types and Java data types is defined in <RBW-IDXTERM TERM1="lang_types customization file"></RBW-IDXTERM
>lang_types customization file. The Java code generator uses these.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing the standard data types</L.LABEL
><B.BODY>You can add data types to the list of standard types in the stand_types customization file. If you do, you must also provide translations for those data types in the lang_types customization file.</B.BODY
><B.BODY>By default, the stand_types and lang_types customization files are defined on the corporate level. You can edit the customization files at the corporate level, or create and edit them at a lower level, such as the project level. (The customization files at the lower level override those at the higher level.)</B.BODY
> describes how to create and edit customization files. The stand_types and lang_types customization files are ASCII files that can be edited using any text editor.</B.BODY
><B.BODY>In the Object Design phase, you define properties of the data attributes. These properties define the accessibility of the attribute with respect to classes and packages, as well as the behavior of the attributes. The code generated for a data attribute is based on its properties.</B.BODY
><RBW-IDXTERM TERM1="Java, generated" TERM2="comment, for attribute"></RBW-IDXTERM
>Use the Text tab of the Edit Properties dialog box to insert a comment in the generated code. The comment appears immediately before the data attribute declaration.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Type of comment</L.LABEL
><B.BODY>Use the Comment Type field to select the type of comment to insert:</B.BODY
>. The attribute is accessible throughout the package that contains the class in which the attribute is declared. The attribute is also accessible within the body of any subclass of that class unless it is shadowed (overridden in the subclass).</RBW-PARABODY
>. The attribute is accessible in the class in which it is declared and in all subclasses of that class. The attribute is accessible in subclasses, even if they are in a different package; the attribute is not accessible to classes that are not subclasses, even if they are in the same package.</RBW-PARABODY
>. The attribute is accessible only within its current package. If a subclass of the data attribute’s class is declared in another package, the data attribute is not accessible in the body of that subclass. </RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The code excerpts below show how this property affects code generation for the Amount attribute of the Account class.</B.BODY
>An attribute access method is a special type of method that gets (reads) and sets (writes) an attribute’s value. Use the Attribute Access Methods group box on the Access tab of the Edit Properties dialog box to specify what accessors to generate for the data attribute.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Read and Write boxes</L.LABEL
><B.BODY>The Attribute Access Methods group box allows you to specify the access method for both read and write. The setting you specify in the Read box affects the Get attribute access method. The setting you specify in the Write box affects the Set attribute access method.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Access methods</L.LABEL
><B.BODY>The following values are allowed for both Read and Write boxes. You can enter the same or different values in the two fields.</B.BODY
>. The generated method is accessible throughout the package that contains the class in which the method is declared. The method is also accessible within the body of any subclass of that class unless it is shadowed (overridden in the subclass).</RBW-PARABODY
><B.BODY>The code excerpt that follows shows the code generated for the Account class, which has one attribute, Amount. The attribute’s Read and Write access methods are both specified as Public (the default).</B.BODY
><EM.EXAMPLE.MONO>public class Account extends Object {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> // Data attributes</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> private int amount;</EM.EXAMPLE.MONO
>Use the Modifier tab in the Edit Properties dialog box to set the attribute modifier properties, which modify the behavior of the generated Java variables. You can select one or more modifiers. By default, none are selected.</B.BODY
>. Typically used to represent constants. If you specify this modifier for an attribute, you must also specify an initial value for the attribute; otherwise, the code generator produces an error. Specify the initial value on the CD (see <RBW-XREF REFID="29666" TYPE="XREF-TEXTCOPY">Attribute syntax</RBW-XREF
>. Causes the attribute to be marked indicating to low&truehy;level parts of the Java virtual machine that they are not part of the persistent state of the object. It is a compile&truehy;time error if a transient variable is also declared final or static.</RBW-PARABODY
>Operations defined for an ObjectTeam class map to Java instance methods. An instance method can be invoked only relative to an instance of the method’s class or one of its subclasses.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The following code excerpt shows the translation of the Print() operation on the Document class:</B.BODY
><EM.EXAMPLE.MONO>public class Document extends Object {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> // Methods</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> public boolean Print() {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> } // method Print &truehy;&truehy; regeneration end marker</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>} // class Document</EM.EXAMPLE.MONO
>In ObjectTeam, you indicate a class operation by prefixing the operation name with a dollar sign ($). Class operations map to Java class methods. A class method is regarded as belonging to the class rather than operating within instances of the class.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The following code excerpt shows the translation of the $Print() operation on the Document class. In Java, the <CX5FX5FPROCEDURE.NAME>static</CX5FX5FPROCEDURE.NAME
> modifier indicates a class method.</B.BODY
><EM.EXAMPLE.MONO>public class Document extends Object {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> // Methods</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> public static boolean Print() {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> } // method Print &truehy;&truehy; regeneration end marker</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>} // class Document</EM.EXAMPLE.MONO
>Abstract methods can be used only in an abstract class.</N.NOTE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The following code excerpt shows the translation of the Print () {abstract} method on the Document class. In Java, the <CX5FX5FINPUT>{abstract}</CX5FX5FINPUT
> modifier indicates a class method.</B.BODY
><EM.EXAMPLE.MONO>public class Document extends Object {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> // Methods</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> public abstract boolean Print();</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>} // class Document</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Operation properties</L.LABEL
><B.BODY>You use operation properties to provide input to the code generator. This section describes how to edit operation properties and the effect of each property.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Special methods</L.LABEL
><B.BODY>The Java code generator also generates the following special methods, which you do not have to specify as operations in an ObjectTeam class:</B.BODY
><RBW-PARABODY>Attribute access methods, as described in <RBW-XREF REFID="21279" TYPE="XREF-TEXTCOPY">Specifying Access Methods for Data Attributes</RBW-XREF
>. Access methods are never specified as operations on an ObjectTeam class.</RBW-PARABODY
><B.BODY>In the Object Design phase, you define properties of operations. These properties define the accessibility of an operation with respect to classes and packages, as well as the behavior of the operation. The code generated for an operation is based on its properties.</B.BODY
><RBW-IDXTERM TERM1="Java, generated" TERM2="comment, for method"></RBW-IDXTERM
>Use the Text tab of the Edit Properties dialog box to insert a comment in the generated code. The comment appears immediately before the method declaration in the generated code.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Type of comment</L.LABEL
><B.BODY>Use the Comment Type field to select the type of comment to insert:</B.BODY
>In the Object Design phase, use the Method tab of the Edit Properties dialog box to define the extent to which other classes can access a method of a class. </B.BODY
>. The method is accessible throughout the package that contains the class in which the method is declared. The method is also accessible within the body of any subclass of that class unless it is shadowed (overridden in the subclass). </RBW-PARABODY
>. The method is accessible in the class in which it is declared and in all subclasses of that class. The method is accessible in subclasses, even when they are in a different package; the method is not accessible to classes that are not subclasses, even when they are in the same package.</RBW-PARABODY
>. The method is accessible only within its current package. If a subclass of the method’s class is declared in another package, the method is not accessible in the body of that subclass.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The code excerpts below show how this property affects code generation for the Get_Employee_ID method of the Employee class.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Public</SL.SUBLABEL
><B.BODY></B.BODY
><EWM.EXAMPLEW.MONO>public class Employee extends Object {</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> //Methods</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> public int Get_Employee_Id() {</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> } // method Get_Employee_Id &truehy;&truehy; regeneration end marker</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>} // class Employee</EWM.EXAMPLEW.MONO
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Protected</SL.SUBLABEL
><B.BODY></B.BODY
><EWM.EXAMPLEW.MONO>public class Employee extends Object {</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> //Methods</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> protected int Get_Employee_Id() {</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> } // method Get_Employee_Id &truehy;&truehy; regeneration end marker</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>} // class Employee</EWM.EXAMPLEW.MONO
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Private </SL.SUBLABEL
><B.BODY></B.BODY
><EWM.EXAMPLEW.MONO>public class Employee extends Object {</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> //Methods</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> private int Get_Employee_Id() {</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> } // method Get_Employee_Id &truehy;&truehy; regeneration end marker</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>} // class Employee</EWM.EXAMPLEW.MONO
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Private Protected</SL.SUBLABEL
><B.BODY></B.BODY
><EWM.EXAMPLEW.MONO>public class Employee extends Object {</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> //Methods</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> private protected int Get_Employee_Id() {</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> } // method Get_Employee_Id &truehy;&truehy; regeneration end marker</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>} // class Employee</EWM.EXAMPLEW.MONO
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>None</SL.SUBLABEL
><B.BODY></B.BODY
><EWM.EXAMPLEW.MONO>public class Employee extends Object {</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> //Methods</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> int Get_Employee_Id() {</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> } // method Get_Employee_Id &truehy;&truehy; regeneration end marker</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>} // class Employee</EWM.EXAMPLEW.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="31329"></RBW-ANCHOR
>Visibility</L.LABEL
><B.BODY>You can display the access level of methods in your diagram by checking Options | Show Visibility in the Class Diagram Editor. Method names will then be displayed with the following leading characters indicating the method’s access level:</B.BODY
><B.BODY>These special characters can also be used to <CX5FX5FEMPHASIS>set</CX5FX5FEMPHASIS
> the access level of methods. Typing a hatch sign (#) before a method name will set the access level of the method to Protected, for example. </B.BODY
>The special characters only work if the menu entry Options | Show Visibility in the Class Diagram Editor has been checked. Otherwise, they will just be regarded as part of the method name.</W.WARNING
>Use the Modifier tab in the Edit Properties dialog box to set the operation modifier properties, which modify the behavior of the generated Java methods. You can select one or more modifiers. By default, none are selected.</B.BODY
>. Indicates that the method is to be implemented in a platform&truehy;dependent way, for example in C or in assembly language. Because the method is not to be implemented in Java, no body is generated for it.</RBW-PARABODY
>. Causes the method to acquire a monitor lock before it executes. If the method is also static, it acquires the lock per class. If not, it acquires the lock per object.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The code excerpts below show how this property affects code generation for the Print method of the Document class.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Final</SL.SUBLABEL
><B.BODY></B.BODY
><EM.EXAMPLE.MONO>public class Document extends Object {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> // Methods</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> public final boolean Print() {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> } // method Print &truehy;&truehy; regeneration end marker</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>} // class Document</EM.EXAMPLE.MONO
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Native</SL.SUBLABEL
><B.BODY></B.BODY
><EM.EXAMPLE.MONO>public class Document extends Object {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> // Methods</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> public native boolean Print();</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>} // class Document</EM.EXAMPLE.MONO
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Synchronized</SL.SUBLABEL
><B.BODY></B.BODY
><EM.EXAMPLE.MONO>public class Document extends Object {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> // Methods</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> public synchronized boolean Print();</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>} // class Document</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Static modifier</L.LABEL
><B.BODY>Java uses the static modifier to indicate a class method. <RBW-XREF REFID="31230" TYPE="XREF-TEXTCOPY">Mapping Operations</RBW-XREF
> describes the mapping of class operations to class methods.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>{abstract} modifier</L.LABEL
><B.BODY>Java uses the {abstract} modifier to indicate an abstract method. <RBW-XREF REFID="31230" TYPE="XREF-TEXTCOPY">Mapping Operations</RBW-XREF
> describes the mapping of abstract operations to abstract methods.</B.BODY
><RBW-IDXTERM TERM1="throw property, for method"></RBW-IDXTERM
><RBW-IDXTERM TERM1="exception property, for method"></RBW-IDXTERM
>Use the Throws tab in the Edit Properties dialog box to specify exceptions to be included in the generated method declaration.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Multiple exceptions</L.LABEL
><B.BODY>If you are entering multiple exceptions, use spaces to separate them.</B.BODY
><B.BODY>You can also generate throw clauses in method declarations using the Edit Properties dialog box. An example of generating throw clauses is shown below for the Document class.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The following dialog box shows how multiple exceptions are specified. The code excerpt that follows the dialog box shows the format and location of the exceptions in the generated code.</B.BODY
><RBW-PARABODY>If the class properties of the ObjectTeam base class indicate that the class maps to a Java class, the code generator generates class inheritance. </RBW-PARABODY
><RBW-PARABODY>If the class properties of the ObjectTeam base class indicate that the class maps to a Java interface, the code generator generates interface inheritance.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY><RBW-XREF REFID="17596" TYPE="XREF-TEXTCOPY">Specifying Class or Interface Generation</RBW-XREF
> describes how to indicate whether an ObjectTeam class maps to a Java class or interface.</B.BODY
>In ObjectTeam, you can specify either disjoint or overlapping inheritance. When using the Java code generator, always use disjoint inheritance.</B.BODY
>In Java, a class may extend (or inherit from) another class. This behavior is called subclassing. Subclassing is a means by which new and enhanced objects can be created from existing objects.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Multiple inheritance is not permitted</L.LABEL
><B.BODY>Java permits a class to inherit from one class only. Therefore, the code generator displays an error if an ObjectTeam class inherits from more than one other class.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>In the following CD, Rectangle extends (inherits from) Shape and Circle extends (inherits from) Shape. </B.BODY
><B.BODY>In the following generated code excerpt, Rectangle extends Shape and Circle extends Shape. Shape extends the Object class, which is the root class of all Java classes.</B.BODY
><EM.EXAMPLE.MONO>public class Shape extends Object {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>...</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>} // class Shape</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO></EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>public class Rectangle extends Shape {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>...</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>} // class Rectangle</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO></EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>public class Circle extends Shape {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>...</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>} // class Circle</EM.EXAMPLE.MONO
>In Java, an interface may extend one or more other interfaces. The interface being declared extends the other named interfaces. It implicitly includes the methods and constants (unless shadowed) of each of the other interfaces. </B.BODY
><B.BODY>Any class that implements the declared interface is also considered to implement the interfaces that the declared interface extends.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Single and multiple inheritance</L.LABEL
><B.BODY>Single inheritance occurs when an interface extends one other interface. Multiple inheritance occurs when an interface extends to more than one other interface. The examples in this section show multiple inheritance, but could as easily show single inheritance.</B.BODY
>If you are using multiple inheritance, make sure that every ObjectTeam base class is marked as an interface. If a single ObjectTeam class inherits from multiple base classes and exactly one of those base classes is marked as a class, the Java code generator generates class inheritance with respect to that one base class and interface inheritance with respect to the other base classes.</W.WARNING
>You must declare any attributes in an interface as class attributes (Java static modifier), final attributes (Java final modifier), or both. In addition, every attribute in an interface must have an initial value that is a constant expression.</B.BODY
><B.BODY>For more information, see the following:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="18563" TYPE="XREF-TEXTCOPY">Specifying Modifiers for Data Attributes</RBW-XREF
><BI.BODY.INTRO>In the following CD, Radio extends (inherits from) both Receiver and Transmitter. The class properties of both Receiver and Transmitter indicate that these class map to Java interfaces.</BI.BODY.INTRO
><B.BODY>Following are generated code excerpts for all three classes. The Radio interface extends both the Receiver and Transmitter interfaces. The attributes and methods of the Receiver and Transmitter interfaces are implemented in Radio interface.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated code for Radio interface</SL.SUBLABEL
><BI.BODY.INTRO></BI.BODY.INTRO
><EWM.EXAMPLEW.MONO>public class Radio extends Object implements Transmitter, Receiver {</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> // Data attributes</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> private int state;</EWM.EXAMPLEW.MONO
><B.BODY>The Java code generator ignores n&truehy;ary associations. Code is generated for the classes involved, but no code is generated for the n&truehy;ary association.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Optional Multplicity</L.LABEL
><B.BODY>The optional multiplicity of an association does not affect the code generated for it. Instead, if a class has a mandatory association, the constructor for the class ensures that it is related to an instance of the associated class.</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="37751" TYPE="XREF-TEXTCOPY">Mapping Link Attributes and Classes as Associations&rbwtab;3–51</RBW-XREF
><B.BODY>This section describes how the Java code generator implements the following simple associations between the Customer class and the Book class.</B.BODY
>The direction of an association is defined by the role names on it. A role name at the far end of the association indicates an association from the class at the near end to the class at the far end.</B.BODY
><B.BODY>If an association has a role name at only one end, it is a unidirectional association (implemented in one direction). If an association has role names at both ends, it is a bidirectional association (implemented in both directions).</B.BODY
>The Java code generator implements a unidirectional association by adding an association attribute and a set of association attribute accessor methods to the code generated for the class at the near end of the association. Creating this association allows the class at the near of the association (Customer) to access the class at the far end (Book); the class at the far end of the association cannot access the class at the near end.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Mapping a bidirectional association</L.LABEL
><B.BODY>The Java code generator implements a bidirectional association by adding an association attribute and a set of association attribute accessor methods<CX5FX5FEMPHASIS> </CX5FX5FEMPHASIS
> to the code generated for both classes. This allows each class to access the other. To ensure integrity of a bidirectional association, the update method for a bidirectional association always maintains the association in both directions.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example of a unidirectional association</L.LABEL
><B.BODY>Following is an excerpt from the code generated for the Customer class in the unidirectional association. Because this is a unidirectional association, the Book class does not contain any code related to the association.</B.BODY
><EM.EXAMPLE.MONO>public class Customer extends Object {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> // Data attributes</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> public String getName() {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> return name;</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> }</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> public void setName(String name_) {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> name = name_;</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> }</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO></EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> // Association accessors</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> public Book getBook() {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> return book;</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> }</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> public void setBook(Book book_) {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> book = book_;</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> }</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>} // class Customer</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example of a bidirectional association</L.LABEL
><B.BODY>Following is an excerpt from the code generated for the Customer class in the bidirectional association. Because this is a bidirectional association, the Book class contains similar code to implement the association in the other direction.</B.BODY
><EM.EXAMPLE.MONO>public class Customer extends Object {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> // Data attributes</EM.EXAMPLE.MONO
>The ObjectTeam documentation and generated Java code use the term association attribute to refer to data attributes generated to support ObjectTeam associations (as opposed to data attributes generated from ObjectTeam attributes). In Java, an association attribute is simply another data attribute and association accessors are simply data attribute accessors.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to edit association attribute properties<RBW-IDXTERM TERM1="Edit Properties (Item menu)" TERM2="for association"></RBW-IDXTERM
><B.BODY>Association attributes and accessors, like data attributes and accessors, have associated ObjectTeam properties. In ObjectTeam, you edit these properties by editing the properties of the association.</B.BODY
><RBW-IDXTERM TERM1="Java, generated" TERM2="comment, for association"></RBW-IDXTERM
>Use the Text tab to insert comments in the generated code, as described in <RBW-XREF REFID="29648" TYPE="XREF-TEXTCOPY">Specifying Comments for Data Attributes</RBW-XREF
>. For association attributes, the comments appear immediately before the association attribute declaration in the generated code.</RBW-PARABODY
><RBW-IDXTERM TERM1="access property" TERM2="for association attribute"></RBW-IDXTERM
>Use the Attribute Access box on the Access tab to specify the accessibility of the association attribute, as described in <RBW-XREF REFID="35486" TYPE="XREF-TEXTCOPY">Specifying Accessibility of Data Attributes</RBW-XREF
>Association attributes for bidirectional associations are always Public. For these attributes, the code generator ignores the setting of the Attribute Access field.</N3.NOTE.3
><RBW-IDXTERM TERM1="access property" TERM2="for association attribute access method"></RBW-IDXTERM
>Use the Attribute Access Methods box on the Access tab to specify the access methods for the association attribute, as described in <RBW-XREF REFID="21279" TYPE="XREF-TEXTCOPY">Specifying Access Methods for Data Attributes</RBW-XREF
><RBW-IDXTERM TERM1="Transient modifier property" TERM2="for association attribute"></RBW-IDXTERM
><RBW-IDXTERM TERM1=""></RBW-IDXTERM
><RBW-IDXTERM TERM1="static modifier property" TERM2="for association attribute"></RBW-IDXTERM
>Use the Modifiers tab to specify modifiers that affect the behavior of the data attribute, as described in <RBW-XREF REFID="18563" TYPE="XREF-TEXTCOPY">Specifying Modifiers for Data Attributes</RBW-XREF
>.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LT2.LIST.TEXT.2>Association attributes have only two modifiers: static and transient. Static makes the association attribute a class attribute. Transient marks the attribute as not part of the persistent state of the object.</LT2.LIST.TEXT.2
> describes the mapping of an ObjectTeam association with multiplicity of one. This section assumes that you are familiar with that information.</B.BODY
>The mapping of an association with a multiplicity of many is similar to that of an association with a multiplicity of one; however, the type of the association attribute is different. </B.BODY
>. For an association with a multiplicity of many, the type of the association attribute is the Vector class. </RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>The Vector class uses a slightly different set of attribute access methods. For read access, it uses a get method. For write access, however, it uses two methods: add and remove. All three methods are shown in the following example.</LT.LIST.TEXT
>The Vector class is in the <CX5FX5FPROCEDURE.NAME>util</CX5FX5FPROCEDURE.NAME
> package shipped with the Java Development Kit (JDK) 1.0.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>Following is an excerpt from the code generated for the Customer class shown above. Because this association is unidirectional, the Book class does not contain any code related to the association.</B.BODY
><EM.EXAMPLE.MONO>public class Customer extends Object {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> // Data attributes</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>} // class Customer</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Association attribute properties</L.LABEL
><B.BODY>You can affect the code generated for any association by specifying the properties of the association, as described in <RBW-XREF REFID="21964" TYPE="XREF-TEXTCOPY">Mapping Simple Associations</RBW-XREF
><B.BODY><RBW-XREF REFID="19864" TYPE="XREF-TEXTCOPY">Mapping Associations With Multiplicity of Many</RBW-XREF
> describes the mapping of an ObjectTeam association with multiplicity of many. This section assumes that you are familiar with that information.</B.BODY
>This section describes how the Java code generator implements the following ordered association between the Customer class and the Book class. </B.BODY
>The mapping of an ordered association is similar to that of an association with an unordered multiplicity of many; however, the type of the association attribute is different. </B.BODY
><B.BODY>For an ordered association, the type of the association attribute is the Queue class. The Queue class uses a slightly different set of attribute access methods. For read access, it uses a get method. For write access, it uses two methods: append and remove. All three methods are shown in the following example.</B.BODY
>The Queue class is shipped with ObjectTeam’s Java code generator. Configuring the Java environment, as described in <RBW-XREF REFID="27027" TYPE="XREF-TEXTCOPY">Configuring the Java Environment</RBW-XREF
>, makes the Queue class available. You do not need the Queue class to generate the Java code, but you do need it to run the code.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>Following is an excerpt from the code generated for the Customer class shown above. Because this association is unidirectional, the Book class does not contain any code related to the association.</B.BODY
><EM.EXAMPLE.MONO>public class Customer extends Object {</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> // Data attributes</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>} // class Customer</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Association attribute properties</L.LABEL
><B.BODY>You can affect the code generated for any association by specifying the properties of the association, as described in <RBW-XREF REFID="21964" TYPE="XREF-TEXTCOPY">Mapping Simple Associations</RBW-XREF
><B.BODY><RBW-XREF REFID="19864" TYPE="XREF-TEXTCOPY">Mapping Associations With Multiplicity of Many</RBW-XREF
> describes the mapping of an ObjectTeam association with multiplicity of many. This section assumes that you are familiar with that information.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Qualified association</L.LABEL
><B.BODY>This section describes how the Java code generator implements the following association between the Customer class and the Book class. </B.BODY
>The mapping of a qualified association is similar to that of an association with multiplicity of many; however, the type of the association attribute is different.</B.BODY
><B.BODY>For a qualified association, the type of the association attribute is the Hashtable class. The qualifier (bookID, in the CD above) is used as a key into the hashtable for storage and retrieval.</B.BODY
>If the qualified association has a multiplicity greater than 1, you must supply both a hashCode method and an equals methods for the qualifier. A comment in the generated code reminds you to supply these methods.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>Each data type supplied in the Java Development Kit (JDK) 1.0 includes the hashCode and equals methods. For examples, see the hashCode and equals methods declared for the String object in the JDK file <JDK&truehy;install>\java\src\java\lang\String.java.</B.BODY
>If you specify a JDK data type as the data type of the qualifier, you do not have to supply the hashCode and equals methods. The JDK supplies them for you.</T.TIP
><B.BODY>The only properties available for a qualifier are the data type and comments. You can also edit other properties of the association, as described in <RBW-XREF REFID="21964" TYPE="XREF-TEXTCOPY">Mapping Simple Associations</RBW-XREF
><RBW-IDXTERM TERM1="Java, generated" TERM2="comment, for qualifier"></RBW-IDXTERM
>Use the Text tab to insert comments in the generated code, as described in <RBW-XREF REFID="29648" TYPE="XREF-TEXTCOPY">Specifying Comments for Data Attributes</RBW-XREF
>. For qualifiers, the comments appear immediately before the qualifier declaration in the generated code.</RBW-PARABODY
><B.BODY>Following is an excerpt from the code generated for the Customer class shown above. Because the association is unidirectional, the Book class does not contain any code related to the association.</B.BODY
><B.BODY>The data type of the bookID qualifier is specified as String, which is a data type contained in the Java Development Kit (JDK) 1.0. The comment in the code reminds you that you must supply hashCode and equals methods for bookID. In this case, the methods are supplied in the JDK.</B.BODY
><EWM.EXAMPLEW.MONO>public class Customer extends Object {</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> // Data attributes</EWM.EXAMPLEW.MONO
>Mapping Link Attributes and Classes as Associations</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisite</L.LABEL
><B.BODY>This section assumes that you are familiar with the mapping of various types of associations, as described in the previous sections.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attributes and classes on associations</L.LABEL
><B.BODY>ObjectTeam allows you specify information about an association by linking attributes, or a class, to the association. The following diagram shows a link attribute symbol; a class symbol can be used in the same location.</B.BODY
><B.BODY>An association that includes a link attribute or a class is transformed before code generation. The link attribute or class becomes a separate class, with appropriate associations to the original classes. The generated code is then based on the transformed association.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The code generated for the CD shown above is based on the following CD:</B.BODY
>If the association includes a link attribute, the new class is assigned the name of the association. Therefore, an association that has a link attribute must have an association name.</B.BODY
><RBW-IDXTERM TERM1="mapping" TERM2="class, as association"></RBW-IDXTERM
>If the association includes a class, that class is used as the third class. Therefore, an association that includes a class does not need an association name.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role names are required</L.LABEL
><B.BODY>As with all associations, role names are required. If a role name is omitted, the association attributes and methods that would map to that role name are not generated.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><BI.BODY.INTRO>Following is the code generated for each of the three Java classes produced by the CD shown above.</BI.BODY.INTRO
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated code for the purchase class</SL.SUBLABEL
><BI.BODY.INTRO></BI.BODY.INTRO
><EWM.EXAMPLEW.MONO>public class purchase extends Object {</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> // Data attributes</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>} // class Book</EWM.EXAMPLEW.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Association attribute properties</L.LABEL
><B.BODY>As for all associations, you can affect the code generated for the association attributes and association attribute access methods by editing the properties for the association, as shown in <RBW-XREF REFID="21964" TYPE="XREF-TEXTCOPY">Mapping Simple Associations</RBW-XREF
>Reverse and Round&truehy;Trip Engineering<RBW-SYSOBJ TYPE="MIFmarker"><RBW-DATAFLD TYPE="number">0</RBW-DATAFLD
><RBW-TEXTFLD TYPE="text">Code Generation Guide for Java</RBW-TEXTFLD
></RBW-SYSOBJ
></C.CHAPTER.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="project" TERM2="using data from other sources"></RBW-IDXTERM
>This chapter describes how to use reverse engineering and round&truehy;trip engineering with the Java code generator.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Reverse engineering</L.LABEL
><B.BODY>Reverse engineering Java code makes the structures and functions of the code visible in ObjectTeam. This process facilitates your understanding of the existing code, which gives you more opportunity to reuse it. The code that you reverse&truehy;engineer may come from other projects or from third parties, such as public domain software sites.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Round&truehy;trip engineering</L.LABEL
><B.BODY>Round&truehy;trip engineering updates the ObjectTeam model based on the changes you have made to the generated Java source files. Use round&truehy;trip engineering to update the ObjectTeam model before you regenerate the source files. If you add an attribute or operation to the generated source file, but not to the ObjectTeam model, that attribute or operation is lost when you regenerate the source files.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Explanation</SL.SUBLABEL
><B.BODY>The code generator generates code based on the ObjectTeam model. When you regenerate the source file, only the attributes and operations defined in the model appear in the generated source file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><RBW-PARABODY>Helps you to understand the structure and functionality of classes</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Not an import utility</SL.SUBLABEL
><B.BODY>Reverse engineering is not designed to capture all the information in a .java file. Do not use reverse engineering to import classes so that you can maintain them in ObjectTeam. If you generate .java files from the CDs and CDMs created by reverse engineering, they will not match the files you used to create those CDs and CDMs.</B.BODY
>The package mechanism in Java allows you to define name spaces. You can define such name spaces in ObjectTeam. Classes with the same name that are defined in multiple packages can cause errors during reverse engineering.</N2.NOTE.2
><RBW-PARABODY>It detects associations according to a heuristic process. The associations can be transformed either into graphical associations or into attributes and methods.</RBW-PARABODY
><B.BODY>The customization file tcl\rev_assoc.tcl in the Java module defines the reverse engineering rules used to detect associations and attribute accessors. You can modify reverse engineering by editing this file, as described in the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><BI.BODY.INTRO>After mapping the Java constructs to ObjectTeam elements, reverse engineering creates the CDs and CDMs that define the ObjectTeam elements. It creates the following CDs:</BI.BODY.INTRO
><RBW-PARABODY>One or more CDs to show the associations among the classes</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Naming conventions for CDs</SL.SUBLABEL
><B.BODY>Each CD is named for the primary class in it, for example, Class1. The word Tree is appended to the name of each CD that defines part of the class hierarchy, for example, TestClass1Tree.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How many diagrams are created</L.LABEL
><B.BODY>The number and complexity of the CDs created by reverse engineering depend largely on the following:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>If selected, ObjectTeam creates a separate reference CD for each class that exceeds the maximum size. The class is folded in all diagrams other than the reference diagram.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Max Class Width & Height</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a class. When a class exceeds this size, it is folded.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Max Tree Width & Height</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a class tree. When a class hierarchy exceeds this size, it is split.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a diagram. When a diagram exceeds this size, it is split.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>If Reverse Engineering Associations is selected, specifies the algorithm reverse engineering uses to create the CDs that show the associations:</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>If selected, reverse engineering examines the attributes and accessor methods defined on each class to determine the associations among classes. It then creates CDs that show those associations.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>CDs that show the class hierarchy</L.LABEL
><B.BODY>Following are the guidelines used to draw the CDs that show the class hierarchy:</B.BODY
><RBW-PARABODY>If a class has multiple parent classes, ObjectTeam creates a CD for each parent. The CD for the first parent class contains the parent class, the child class, and all subclasses of the child class. The CD for each of the other parent classes contains only the parent class and the child class; in these diagrams, the child class is folded.</RBW-PARABODY
><B.BODY>If you select the Reverse Engineer Associations option in the Reverse Engineer dialog box, ObjectTeam creates CDs that show the associations. How it creates these CDs depends on which Placement Algorithm option you selected in the Reverse Engineer dialog box. Both algorithms are described in the sections following.</B.BODY
><B.BODY>If you do not select the Reverse Engineer Associations option, ObjectTeam shows associations only as attributes and accessor methods in the appropriate classes.</B.BODY
><RBW-PARABODY>Unfolds the main class in each CD and folds all associated classes.</RBW-PARABODY
></LN.LIST.NUM
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><BI.BODY.INTRO>Reverse engineering the MolecureViewer example from the JDK 1.1 creates a number of CDs and CDMs. The following CDs, created by the simple algorithm, show the associations among classes:</BI.BODY.INTRO
><RBW-PARABODY>Divides all classes into groups of <CX5FX5FEMPHASIS>n</CX5FX5FEMPHASIS
>, where <CX5FX5FEMPHASIS>n</CX5FX5FEMPHASIS
> is the number specified by the Number of Classes per CD field of the Reverse Engineer dialog box. The algorithm attempts to group associated classes.</RBW-PARABODY
><RBW-PARABODY>For each group of classes, creates a CD and adds the classes (unfolded) to the CD. To position the classes, ObjectTeam uses a uniform grid whose squares are the size of the largest class in the group and its longest association.</RBW-PARABODY
><RBW-PARABODY>For each class in each CD, draws all associations from the class to all associated classes. If an associated class is not in the CD, ObjectTeam adds it (folded) to the CD.</RBW-PARABODY
></LN.LIST.NUM
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><BI.BODY.INTRO>Reverse engineering the MoleculeViewer example from the JDK 1.1 creates a number of CDs and CDMs. The following CD, created by the grid algorithm, shows the associations among classes. (The classes in the generated CD were repositioned so that the illustration would fit on one page.)</BI.BODY.INTRO
>The Atom class is not associated with any other class. However, during reverse engineering, the Number of Classes per CD box in the Reverse Engineering dialog box was set to 7. The Atom class was added to the diagram as the seventh class.</N.NOTE
>Typically, you reverse engineer into an empty system. However, name conflicts can still occur because classes are created with scope Phase.</N2.NOTE.2
><RBW-PARABODY>Select the files that you want to reverse engineer, and then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>A second Reverse Engineer Java dialog box appears (see <RBW-XREF REFID="10252" TYPE="XREF-TEXTCOPY">Options for reverse engineering</RBW-XREF
>), prompting you to select the options that you want to use. </LR.LIST.RESULT
><RBW-PARABODY>Select the options and, then click OK.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam reverse&truehy;engineers the selected file, reporting the results in a Monitoring window. The generated CDs display the class hierarchy defined in the selected files. Each class includes its attributes, operations, and (if the Reverse Engineer Associations option is selected) associations.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="16372"></RBW-ANCHOR
>Files for reverse engineering</L.LABEL
><BI.BODY.INTRO>ObjectTeam prompts you to select the .java files to reverse&truehy;engineer. The following illustrations show the Windows and UNIX dialog boxes.</BI.BODY.INTRO
>Reverse engineering creates CDs and CDMs based on the files that you select. Therefore, it is good practice to reverse&truehy;engineer all related files at the same time. For example, when reverse engineering a class library, select all .java files used to define the class library.</T.TIP
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Windows</SL.SUBLABEL
><BI.BODY.INTRO>In Windows, use the File Name and Files of Type boxes to filter the list of files displayed.</BI.BODY.INTRO
><B.BODY>Round&truehy;trip engineering updates the ObjectTeam model based on the changes you have made to the generated source files. Use round&truehy;trip engineering to update the ObjectTeam model before you regenerate the source files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose</L.LABEL
><B.BODY>The code generator generates code based on the ObjectTeam model. If you do not update the ObjectTeam model before regenerating the source files, the new source files do not include your changes. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>You generate Java files and then add a new method to a generated source file. If you do not update the ObjectTeam model, it does not contain the operation that corresponds to the method. When you regenerate the source file, the code generator assumes that you deleted the operation from ObjectTeam and does not include the now obsolete method in the newly generated source file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes captured by round&truehy;trip engineering</L.LABEL
><B.BODY>If you have made the following types of changes to the generated source file, ObjectTeam updates the model based on those changes:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>You select the generated (edited) source files that you are interested in and start round&truehy;trip engineering.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>ObjectTeam parses the selected files and compares the information in the files with the information in the ObjectTeam model.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>For each difference it finds, ObjectTeam proposes an action and prompts you for confirmation. For example:</CELLBODY
><CELLBODY><CX5FX5FINPUT>In class “Account”: delete attribute “Address”?</CX5FX5FINPUT
><SUBSECTION><SS.SUBSEC.HEAD>Parsing the Generated (Edited) Source Files</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This section describes which changes to the generated source files that round&truehy;trip engineering captures. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="27501"></RBW-ANCHOR
>Changes to attributes</L.LABEL
><B.BODY>You can add, delete, and modify variable declarations in a generated .java file. However, all variable declaration statements must be specified beneath the following comment in the generated source file:</B.BODY
><EM.EXAMPLE.MONO>// Data attributes</EM.EXAMPLE.MONO
><B.BODY>Attribute declarations not in this section of the generated source file are ignored by.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attribute Access property</SL.SUBLABEL
><B.BODY>ObjectTeam determines the value of an attribute’s Attribute Access property based on the methods specified beneath the following comment in the generated source file:</B.BODY
><B.BODY>For example, if you add an attribute declaration to the source file but do not add attribute access methods, ObjectTeam sets the Read and Write values of the attribute’s Attribute Access property to None.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Delete attribute accessors</SL.SUBLABEL
><B.BODY>If you delete an attribute, delete the attribute accessors for that method also. ObjectTeam does not delete them when it deletes an attribute.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="34671"></RBW-ANCHOR
>Changes to methods</L.LABEL
><BI.BODY.INTRO>You can add, delete, and modify method declaration statements in a generated <CX5FX5FFILE.NAME>.java</CX5FX5FFILE.NAME
> file. However, these statements must be specified beneath the following comment in the generated source file:</BI.BODY.INTRO
><EM.EXAMPLE.MONO>// Methods</EM.EXAMPLE.MONO
><B.BODY>Method declarations not specified in this section of the generated source file are ignored by round&truehy;trip engineering.</B.BODY
><B.BODY>You can change the code in the body of any method. Such changes are ignored by round&truehy;trip engineering, but are preserved by the code generator when you regenerate the source files.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Overloaded methods</SL.SUBLABEL
><B.BODY>If you have multiple methods with the same name, do not delete one and change the declaration of another at the same time. Delete one, run round&truehy;trip engineering, change the declaration of the other, and run round&truehy;trip engineering. This approach prevents potential errors.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes to constructors</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Default constructor</SL.SUBLABEL
><B.BODY>The default constructor appears beneath the following comment in the generated source file:</B.BODY
><B.BODY>You can add and remove key attributes from the parameter list of the default constructor. </B.BODY
><B.BODY>In the CD, a key attribute is prefixed with an asterisk. If you remove an attribute from the parameter list of the default constructor, ObjectTeam removes the asterisk from the attribute name in the CD. If you add an attribute to the parameter list of the default constructor, ObjectTeam adds an asterisk to the attribute name in the CD.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>User&truehy;defined constructor</SL.SUBLABEL
><B.BODY>User&truehy;defined constructors appear beneath the following comment in the generated source file:</B.BODY
><EM.EXAMPLE.MONO>// User defined constructors</EM.EXAMPLE.MONO
><B.BODY>You can add, delete, and edit user&truehy;defined constructors as you can any other method (see <RBW-XREF REFID="34671" TYPE="XREF-TEXTCOPY">Changes to methods</RBW-XREF
><B.BODY>The customization file roundtrip.roundtrip in the M4_home/etc directory controls what actions ObjectTeam proposes, as well as the default answers it supplies. To examine or modify the current behavior of round&truehy;trip engineering, examine or modify the customization file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to run round&truehy;trip engineering</L.LABEL
><LR.LIST.RESULT>ObjectTeam opens the Roundtrip Selected Files dialog box, compares the classes in the generated files to the classes in the Object Design phase, and then begins proposing actions and prompting you for confirmation.</LR.LIST.RESULT
><RBW-TEXTFLD TYPE="text">Code Generation Guide for Java</RBW-TEXTFLD
></RBW-SYSOBJ
></C.CHAPTER.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Expert users can extend the Java code generator by modifying the Tcl scripts that are supplied in the <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
>\<CX5FX5FFILE.NAME>tcl</CX5FX5FFILE.NAME
>\<CX5FX5FFILE.NAME>l_java</CX5FX5FFILE.NAME
> directory. </B.BODY
><B.BODY>Editing these Tcl scripts, or writing new ones that add functionality to the code generator, requires a thorough knowledge of the OOPL model structure, Tcl commands, and the ObjectTeam Shell.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Modifying Tcl procedures</L.LABEL
><B.BODY>You can adapt existing methods of Object Tcl classes that are used in the code generation by redefining them in a user&truehy;defined Tcl file.</B.BODY
>Cayenne Software cannot support any provided Tcl scripts that you modify. Therefore, the scripts and their structures are not documented. If you choose to modify any Tcl scripts or procedures, you must have a thorough knowledge of the script’s structures to avoid introducing errors. </W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="22291" TYPE="XREF-TEXTCOPY">How Tcl is Used in the Code Generation&rbwtab;5–20</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="15580" TYPE="XREF-TEXTCOPY">Customizing Tcl Scripts Used for Code Generation&rbwtab;5–23</RBW-XREF
><B.BODY>This chapter provides information on the use of Tcl (Tool command language) in ObjectTeam. It does not provide an introduction to Tcl itself. If you want to become familiar with Tcl, try the following introductory book:</B.BODY
><LT.LIST.TEXT>John K. Ousterhout, <CX5FX5FTITLE>Tcl and the Tk Toolkit</CX5FX5FTITLE
><B.BODY>Tcl (Tool command language) is an interpretive command language that resembles C. By default all arguments are passed as strings. These strings are C&truehy;compatible. Tcl consists of:</B.BODY
><B.BODY>The Tcl core is a simple language that can be completely programmed. It provides a collection of commonly used features such as these:</B.BODY
><BI.BODY.INTRO>When the ObjectTeam shell executes a Tcl script file, it translates information from the repository, internal models, and <RBW-IDXTERM TERM1="code generation model" TERM2="and Tcl"></RBW-IDXTERM
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Refer to general Tcl documentation for details.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Calls to Tcl </CELLBODY
><CELLBODY>procedures</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>These procedures are stored in Tcl files. They become available when the file in which the procedure is defined is sourced.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Calls to methods of classes</CELLBODY
><CELLBODY>in the <RBWAUTO-0024>ObjectTeam</RBWAUTO-0024
><RBWAUTO-0024></RBWAUTO-0024
> </CELLBODY
><CELLBODY>models</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The classes of the ObjectTeam models (including the OOPL model and SQL model) are documented in <CX5FX5FTITLE>ObjectTeam Repository Interface Guide</CX5FX5FTITLE
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Besides methods of classes belonging to the <RBWAUTO-0024>ObjectTeam</RBWAUTO-0024
><RBWAUTO-0024></RBWAUTO-0024
> models, methods belonging to other built&truehy;in classes can also be called. Refer to the <CX5FX5FTITLE>ObjectTeam Repository Interface Guide</CX5FX5FTITLE
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>These commands are built&truehy;in to otsh and otk. You can use these commands, but you cannot edit or view them like Tcl procedures. Refer to the <CX5FX5FTITLE>ObjectTeam Repository Interface Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for details. </CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="35220"></RBW-ANCHOR
>Which Tcl files are used?</L.LABEL
><B.BODY>Tcl procedures used for code generation are stored in Object Tcl script files. During code generation, these scripts are interpreted and executed by the ObjectTeam shell (otsh). When you use Utilities | Import From Previous Phase in the Browser at the system level of the Implementation phase, otsh interprets the Object Tcl code in the Tcl file tcl\l_java\javimport.tcl. In the implementation of these methods, Tcl methods from other classes are called.</B.BODY
><B.BODY>Most of the Tcl script files that the Java code generator uses are located under the <CX5FX5FTERM>M4_home</CX5FX5FTERM
> directory in tcl\l_java\*.tcl. The Tcl script files fstorage.tcl and caynutil.tcl in the tcl directory contain utility procedures that are also used.</B.BODY
>Customizing Tcl Scripts Used for <RBW-IDXTERM TERM1="code generation" TERM2="adapting"></RBW-IDXTERM
>Code Generation</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>User&truehy;defined Tcl files</L.LABEL
><B.BODY>Because of the open character of Tcl, you can redefine the existing Object Tcl methods of the Tcl scripts, if you want to adapt the code generation to your needs and circumstances. You can include your own properties, control flow keywords, and section keywords in the code generation this way. You can even build your own code generator by creating your own Tcl scripts. </B.BODY
>Note that existing Object Tcl classes cannot be redefined. However, you can add new, user&truehy;defined Object Tcl classes.</W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="37212"></RBW-ANCHOR
>Where to store user&truehy;defined Tcl procedures</L.LABEL
><B.BODY>The Tcl script files used for the default code generation are stored in the file system. They can be found in the following directory:</B.BODY
><B.BODY>If you want to adapt the default code generation, you can edit the Tcl files in this directory, but it is better to modify copies of the original files. There are several ways available to make otsh use user&truehy;defined files. These ways are briefly discussed in this section. </B.BODY
><B.BODY>You can overrule existing Tcl files or you can extend them by creating new Tcl files with new user&truehy;defined Tcl procedures and methods, or redefinitions of existing methods. The ways to do that are also covered in this section.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Storing Tcl files in the same System as where the code is generated</L.LABEL
><B.BODY>One of the available file types on the system level of the Implementation phase is Tcl. You can create new files of this type and redefine methods of existing Object Tcl classes in such a file. During code generation, otsh sources all files of the type Tcl in the current system, regardless of their names.</B.BODY
><RBW-PARABODY>Select Tcl as the file type, specify a name for the Tcl file (without the extension .tcl), and click OK.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>You can enter the name of an existing Tcl file used for code generation or any other name. If you enter an existing name, the original Tcl file is replaced by this new file during code generation.</LT.LIST.TEXT
><RBW-PARABODY>Edit and save the new Tcl file.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The next time you generate code (by using Utilities | Import From Previous Phase) the new Tcl file is sourced by otsh.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Storing Tcl files in a system Tcl</L.LABEL
><B.BODY>If you do not want to store user&truehy;defined Tcl files in the same system in which your code is generated, you can create a system called Tcl and store your user&truehy;defined Tcl files in there. Any Tcl file that is defined in such a system is sourced during code generation. You can use this mechanism for user&truehy;defined Tcl files or for user&truehy;defined Tcl files that are meant to replace existing ones.</B.BODY
><RBW-PARABODY>Select Tcl as the file type, specify a name for the Tcl file (without the extension <CX5FX5FFILE.NAME>.tcl</CX5FX5FFILE.NAME
>), and click OK.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>You can enter the name of an existing Tcl file used for code generation or any other name. If you enter an existing name, the original Tcl file is replaced by this new file during code generation.</LT.LIST.TEXT
><B.BODY>If you want to test a customized Tcl file before you add it to a system in ObjectTeam, you can create the Tcl file in your file system and feed it to otsh outside the ObjectTeam environment. </B.BODY
><B.BODY>See the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for details on how to start otsh from the command line.</B.BODY
><B.BODY>When the Tcl file has reached its final state, you can decide to add it to a system in ObjectTeam, as described above. </B.BODY
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="35486" TYPE="XREF-TEXTCOPY">Specifying Accessibility of Data Attributes</RBW-XREF
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="17596" TYPE="XREF-TEXTCOPY">Specifying Class or Interface Generation</RBW-XREF
><ENTRY COLNAME="4" VALIGN="TOP" MOREROWS="0"><CELLBODY><RBW-XREF REFID="18563" TYPE="XREF-TEXTCOPY">Specifying Modifiers for Data Attributes</RBW-XREF
><CHAPTERNONUM><CN.CHAPTER.NOX23>About This Manual<RBW-SYSOBJ TYPE="MIFmarker"><RBW-DATAFLD TYPE="number">0</RBW-DATAFLD
><RBW-TEXTFLD TYPE="text">Code Generation Guide for NewEra</RBW-TEXTFLD
></RBW-SYSOBJ
></CN.CHAPTER.NOX23
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>About this manual</L.LABEL
><B.BODY>ObjectTeam provides code generation tools that enable you to generate object&truehy;oriented code for a range of object&truehy;oriented programming languages. This guide focuses on NewEra as the target language. </B.BODY
><B.BODY>Business experts, application designers, and system developers can work together using these tools to efficiently analyze, design, and identify solutions to business problems. The NewEra Code Generator simplifies implementation and programming by automatically converting design data from Class Diagrams that you’ve previously created and specified with NewEra&truehy;specific properties into NewEra source code.</B.BODY
>contains information specific to Version 2.11 of the NewEra programming language. This includes information for setting up, configuring, and specifying code generation details in Class Diagrams that you will use to generate NewEra code. Refer to the <CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for general information about the code generation process and for installation instructions.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisites</L.LABEL
><B.BODY>This guide is intended for experienced users of ObjectTeam and the analysis and design method it supports. It is also intended for experienced C++ programmers who have some familiarity with NewEra programming. This guide gives you information on how to map ObjectTeam diagrams to NewEra code; it does not teach you the NewEra language.</B.BODY
><B.BODY>To customize or extend the capabilities of the NewEra code generator, you must have a thorough understanding of the ObjectTeam Shell, the Object&truehy;Oriented Programming Language (OOPL) model structure, and the Tool Command Language (Tcl) commands.</B.BODY
> provides the menu items, the properties and the Tcl code required to use the NewEra Code Generator. Therefore, before moving to the Object Design phase, make sure this module is active.</B.BODY
><B.BODY>You can check if a module is active on a particular Browser level by selecting Utilities | Show Active Modules on that level.</B.BODY
> for details on how to activate a module.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Object Design and Implementation</L.LABEL
><B.BODY>This chapter describes the tasks of the Object Design phase. <RBW-XREF REFID="15740" TYPE="XREF-TEXTCOPY">Chapter 2, Building NewEra Applications</RBW-XREF
>, describes the tasks of the Implementation phase. You work iteratively in these two phases to generate code and complete your application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose of object design</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="Object Design" TERM2="activities in this phase"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Object Design" TERM2="development phase in ObjectTeam project"></RBW-IDXTERM
>In ObjectTeam, the CDs (and the objects defined in the CDs) provide all the source data needed for code generation. The goal of object design is to add to the CDs all the data required for successful code generation. For example, you add properties (such as the Attribute Access property, which establishes read/write access to an attribute) and incorporate language&truehy;specific syntax (such as data type specifications for attributes and the arguments of operations).</B.BODY
><B.BODY>You might also add data to diagrams other than CDs. The code generator does not use oter diagrams, but they are useful for describing the behavior of classes, their attributes and operations.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="15756" TYPE="XREF-TEXTCOPY">Refining the Class Diagrams&rbwtab;1–3</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="24561" TYPE="XREF-TEXTCOPY">Hints and Tips for Effective Code Generation&rbwtab;1–6</RBW-XREF
>Introduction<RBW-IDXTERM TERM1="Class Association Diagram"></RBW-IDXTERM
></L.LABEL
><B.BODY>The CDs and the objects defined in the CDs provide all the source data needed for code generation. <RBW-IDXTERM TERM1="Class Association Model"></RBW-IDXTERM
>These diagrams distinguish the classes in a system and describe their identities and their features. In the Object Design phase, you must add to the CDs sufficient detail for successful code generation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using data from diagrams other than CDs</L.LABEL
><B.BODY>Diagrams other than the CDs are not used as input for code generation. However, they contain valuable information that can help you to complete and verify the CDs. The following table summarizes how you can use these other diagrams to help you find important objects that are not yet in the CDs.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>STD state names (enumerated list as an attribute value)</CELLBODY
><CELLBODY>STD condition on an event</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Classes</L.LABEL
><B.BODY>When you work on CDs, you focus on the implementation of classes. The CD must include all classes and the associations (and inheritance) between classes. In the Object Design phase, you may introduce new classes to ease implementation and improve performance.</B.BODY
><B.BODY>You must include all attributes and operations for each class. The attributes of a class map to the attributes of the class type. The operations of the class map to functions and procedures of the class type. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>External classes</L.LABEL
><B.BODY>A class must have at least one attribute or one operation to generate code. Classes that have no attributes or operations are translated as external classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Associations</L.LABEL
><B.BODY>You must define the associations between all classes, including any constraints.</B.BODY
><B.BODY>Role names must also be defined. Every association needs at least one role name. Every mandatory association must have a role name. Without a role name, you cannot use the association.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role names in Analysis and System Design</SL.SUBLABEL
><B.BODY>In the Analysis and System Design phases, role names distinguish a class by showing the role the class is playing in a relationship with another class. Each role name defines the role of the class within the context of a single association. It also indicates the use and direction of the association toward the class that plays a role. For example, a manager can be both the boss of a coworker and an employee of a company.</B.BODY
>Role names in Object Design and Implementation</SL.SUBLABEL
><BI.BODY.INTRO>In the Object Design and Implementation phases, the use of role names is extended. The code generator creates access methods for an association if the class at the far end has a role name for the association. In the previous example, the code generated for Coworker includes access methods for Manager; the code generated for Manager does not include access methods for Coworker.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attributes</L.LABEL
><B.BODY>You must specify each attribute completely, including its data type. The way to specify a data type for an attribute is to include the type in the class symbol, for example:</B.BODY
><B.BODY>Data types of attributes and arguments can be standard ObjectTeam types, standard types for your target language, or class types and derived types. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Operations</L.LABEL
><BI.BODY.INTRO>You must specify each operation completely. This includes specifying such aspects as:</BI.BODY.INTRO
><RBW-PARABODY>Any parameters, as well as their data types</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Properties</L.LABEL
><BI.BODY.INTRO><RBW-IDXTERM TERM1="property" TERM2="using - to specify implementation details"></RBW-IDXTERM
>In the Object Design phase, a variety of properties allow you to specify many implementation details. <RBW-IDXTERM TERM1="property" TERM2="using - to specify implementation details"></RBW-IDXTERM
>These details are incorporated in the final code.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Checking</L.LABEL
><B.BODY>The last activity in object design is to use Check | Global Model to check the CDs. The CDs must be error&truehy;free before they can be used for code generation. See the <CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for more information about the Check utility.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</L.LABEL
><B.BODY><RBW-XREF REFID="27879" TYPE="XREF-TEXTCOPY">Chapter 3, Mapping Modeling Data to NewEra Non&truehy;Persistent Code</RBW-XREF
>, <RBW-XREF REFID="23603" TYPE="XREF-TEXTCOPY">Chapter 4, Mapping Modeling Data to NewEra Persistent Code</RBW-XREF
>, and <RBW-XREF REFID="16738" TYPE="XREF-TEXTCOPY">Chapter 5, Modeling the User Interface</RBW-XREF
>, describe how the ObjectTeam model is translated into code. You can use this information to help you complete the CDs in the Object Design phase.</B.BODY
>Hints and Tips for Effective Code Generation</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Following are a few tips for effective code generation. It may be helpful to be aware of these items as you prepare for code generation, and then again as you generate and regenerate your source files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Understanding the translations</L.LABEL
><B.BODY>Before generating code, read through this guide. It contains detailed information about the data that you must include in your CDs for successful code generation. It also explains how the code generator translates the ObjectTeam model into source code files, what changes you can make to the source code files, and how to regenerate them without losing your changes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Naming conventions</L.LABEL
><B.BODY>Agree upon and follow a naming convention for projects, configurations, systems, classes, special characters, and so on. In addition, bear in mind that spaces between words (in class names, for instance) are deleted by ObjectTeam code generators.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing code generation</L.LABEL
><B.BODY>The code generators execute Tcl scripts that translate a model into source code. You can modify these scripts or create your own.. Always use caution when customizing or creating scripts; such scripts are not supported.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using multiple languages in a single application</L.LABEL
><B.BODY>Each ObjectTeam code generator is designed to generate code for one language. You can create an application that uses multiple languages by using different code generators to generate code for different systems; however, the generated code is not integrated across systems. </B.BODY
><B.BODY>The ObjectTeam code generators are not designed to provide language integration. To build an application that uses multiple languages, you must do the following: </B.BODY
>When you create a separate ObjectTeam system for each language&truehy;specific subsystem, be sure to define your classes in the appropriate system. When ObjectTeam generates code for the current system, it generates code for the classes that are defined in that system. It does not generate code for classes referenced, but not defined in, the current system; such classes are treated as external classes.</N.NOTE
>Typically, the ultimate goal of modeling an application is to produce code that implements the application. In ObjectTeam, you can generate a significant portion of the code automatically, then complete the code by adding the details that not specified in the model.</B.BODY
><RBW-PARABODY>Only the CDs (and the objects defined in the CDs) are used for code generation. Therefore, before code generation, it is critical that the CDs be fully defined, as described in <RBW-XREF REFID="19722" TYPE="XREF-TEXTCOPY">Chapter 1, Preparing Your ObjectTeam Model for Code Generation</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Steps in building a NewEra application</L.LABEL
><B.BODY>The following table provides an overview of the application development process. This chapter describes each step in greater detail.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Generate NewEra files. During this step, ObjectTeam generates the application source code files on System level in the Implementation phase.</CELLBODY
> System level in the Implementation phase is fundamentally different from System level in other phases. The System files in the Implementation phase are source files, not diagram files.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Configure the NewEra environment, ensuring proper installation of the NewEra environment (Application Builder, Window Painter, and so on).</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Edit the source files. ObjectTeam generates a large portion of your application code, but not all of it. In this stage, you finish writing the application code.</CELLBODY
><CELLBODY>Changes you make to the source files are not lost. When you regenerate the source files, the code generator recognizes your changes and transfers them to the newly generated files.<RBW-IDXTERM TERM1="code regeneration"></RBW-IDXTERM
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Define the target database. This step is only necessary if your CDs contain persistent classes. Persistent classes are created as tables in a relational database. In this step, you create or select the database.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Complete the generated wif template files using the NewEra Window Painter. This step is only necessary if your CDs contain GUI classes</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Build the executable or library using the NewEra Application Builder. If you built an executable, you can now run it.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Test the executable or library. If necessary: correct the source files, the model, or both; regenerate the files; and return to step 6.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Illustration of code generation</L.LABEL
><BI.BODY.INTRO>The following illustration shows how ObjectTeam generates code, including the names of the Tcl scripts that it uses. The CDs and CDMs shown at the top are in the Object Design phase.</BI.BODY.INTRO
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="37228" TYPE="XREF-TEXTCOPY">Defining a Target Database&rbwtab;2–20</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="30084" TYPE="XREF-TEXTCOPY">Building the Executable or Library&rbwtab;2–23</RBW-XREF
><B.BODY>The scripts written for code generation retrieve information from the code generation models, format this information and write the results to source code files. Code generation models are built from the CDs in the Object Design phase.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Persistent and non&truehy;persistent and code</L.LABEL
><BI.BODY.INTRO>Objects can be persistent or non&truehy;persistent:</BI.BODY.INTRO
><RBW-PARABODY>The data of a <CX5FX5FBULLET.EMPHASIS>persistent</CX5FX5FBULLET.EMPHASIS
> object survives the execution of its related program; that is, the object persists beyond the lifetime of a single program execution. The data for persistent objects is stored in a <RBW-IDXTERM TERM1="data store" TERM2="permanent"></RBW-IDXTERM
>permanent data store, such as a Relational Database Management System (RDBMS).</RBW-PARABODY
><RBW-PARABODY>The data of a <CX5FX5FBULLET.EMPHASIS>non&truehy;persistent</CX5FX5FBULLET.EMPHASIS
> object exists only during the execution of its related program.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Terminology</SL.SUBLABEL
><B.BODY>Classes and code are not persistent or non&truehy;persistent. However, to simplify references to classes and code that are related to persistent and non&truehy;persistent objects, the ObjectTeam documentation uses the terms <CX5FX5FTERM>persistent classes</CX5FX5FTERM
> and <CX5FX5FTERM>non&truehy;persistent code</CX5FX5FTERM
>. For example, <CX5FX5FEMPHASIS>non&truehy;persistent code</CX5FX5FEMPHASIS
> refers to object&truehy;oriented language code (NewEra), and <CX5FX5FEMPHASIS>persistent code</CX5FX5FEMPHASIS
> refers to the Data Definition Language (SQL) and the Data Manipulating Language (NewEra) code. <RBW-IDXTERM TERM1="code generation" TERM2="persistent"></RBW-IDXTERM
><B.BODY>Besides persistent and non&truehy;persistent code ObjectTeam can generate templates with wifl code. Wifl is the Window Intermediate Format Language that is used to define the Graphical User Interface of a NewEra application. These templates serve as initial wif files, which should be completed further in NewEra.</B.BODY
><RBW-PARABODY>Changes that you make to the generated files are preserved when you regenerate the files.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>For more information, see <RBW-XREF REFID="33638" TYPE="XREF-TEXTCOPY">Regenerating Code</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-IDXTERM TERM1="class library" TERM2="including in code generation"></RBW-IDXTERM
>Class library integration</L.LABEL
><B.BODY>You can include external class libraries in your design. Such an external class library is automatically included during the code generation. In addition, ObjectTeam helps you to understand and reuse existing class libraries through reverse engineering.</B.BODY
><B.BODY>For more information, see <RBW-XREF REFID="32714" TYPE="XREF-TEXTCOPY">Chapter 6, Reverse Engineering</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Configuration</L.LABEL
><B.BODY>The non&truehy;persistent code that ObjectTeam generates could be any object&truehy;oriented programming language, but this guide focuses on NewEra. You can configure the settings of the default values that are applied when the design is transformed into the NewEra code.</B.BODY
><B.BODY>For more information, see <RBW-XREF REFID="40480" TYPE="XREF-TEXTCOPY">Configuring Your NewEra Environment</RBW-XREF
><B.BODY>When you generate source files, the code generator uses the CDs and CDMs that are in the Object Design phase to create NewEra source files in the Implementation phase. At System level of the Implementation phase, you can then refine the source code and complete the application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Implementation Phase is different</L.LABEL
><B.BODY>The System level of the Implementation phase is fundamentally different from System level of any other phase. In the Implementation phase, the System files are NewEra files. In other phases, the System files are ObjectTeam diagrams.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generate code on Phase or System level</L.LABEL
><B.BODY>You can generate code on the Implementation Phase level or on the System level of the Implementation phase.</B.BODY
><RBW-PARABODY>On the <CX5FX5FBULLET.EMPHASIS>Implementation Phase level</CX5FX5FBULLET.EMPHASIS
>, you can generate code for one or more systems. This creates a matching system in the Implementation Phase that contains the generated source files. For each system that you select, ObjectTeam imports both the OOPL and SQL Models. To regenerate code for an existing system, use System level.</RBW-PARABODY
><RBW-PARABODY>On the <CX5FX5FBULLET.EMPHASIS>System level of the Implementation phase</CX5FX5FBULLET.EMPHASIS
>, you can (re)generate code for the entire system, or regenerate selected source files. On System level, you can select whether to import the OOPL or SQL Model.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>Typically, you use Implementation Phase level to generate code for a system initially and System level to regenerate code subsequently.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to generate code on Implementation Phase level</L.LABEL
> to generate code for one or more systems in the Object Design phase. You can select only systems that do not yet exist in the Implementation phase.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>ObjectTeam opens a Monitor window for displaying log messages, then generates the source files. For each system, ObjectTeam generates both the OOPL and SQL Models. (These models are described later in this section.)</LR.LIST.RESULT
> to generate code for all classes that are defined in this system and that have not yet been generated into code. The Import New dialog box appears.</RBW-PARABODY
> to (re)generate code for all classes that are defined in this system.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>ObjectTeam opens a Monitor window for displaying log messages, then generates the source files. The following illustration shows the Monitor window after generating the OOPL Model.</LR.LIST.RESULT
> directory, where <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
> is the file path for your generated files. For more information on the user environment, see the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
><B.BODY>The following illustrations show how the source files appear in the Browser. The first illustration shows the source files after generating the OOPL Model and the second shows the source files after generating the SQL Model.</B.BODY
><RBW-IDXTERM TERM1="Update User Environment (Utilities menu)"></RBW-IDXTERM
>Update user environment</SL.SUBLABEL
><B.BODY>Utilities | Update User Environment synchronizes your user environment with the repository. This can be particularly useful if you are working on two machines, and the user environment of each is set to a local drive. When you move between machines, you can use Utilities | Update User Environment to update the local drive of the current machine.</B.BODY
> describes how to generate source files for systems in the Implementation phase. This section describes how ObjectTeam converts the OOPL model. <RBW-IDXTERM TERM1="generating code" TERM2="import OOPL model"></RBW-IDXTERM
><B.BODY>The OOPL Model, which is generated from the CDs in the Object Design phase, contains information used to generate code. The objects in this model are organized in such a way that code can be generated easily.</B.BODY
> provides a detailed description of the classes in the OOPL Model.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How ObjectTeam converts the OOPL Model</L.LABEL
><B.BODY>To convert the OOPL Model, the ObjectTeam Shell (otsh) executes the Tcl script <CX5FX5FFILE.NAME><RBW-IDXTERM TERM1="import.tcl"></RBW-IDXTERM
>import.tcl</CX5FX5FFILE.NAME
>. It loads the OOPL model into memory and translates the information into NewEra source code. The ObjectTeam shell recognizes elements such as classes, data types, associations and methods. </B.BODY
> activates, among other things, the Tcl script <CX5FX5FFILE.NAME><RBW-IDXTERM TERM1="genne.tcl"></RBW-IDXTERM
>genne.tcl</CX5FX5FFILE.NAME
>, which contains Tcl procedures to retrieve information from the OOPL model and other internal models, format it and write it to the appropriate source files. <CX5FX5FFILE.NAME>genne.tcl</CX5FX5FFILE.NAME
> uses other Tcl scripts that use other Tcl scripts as well, and so on.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>For an overview of the Tcl scripts used for code generation, see <RBW-XREF REFID="36160" TYPE="XREF-TEXTCOPY">Chapter 7, Customizing Code Generation</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Non&truehy;persistent code</L.LABEL
><B.BODY>The NewEra code generator generates the following files for every non&truehy;persistent class in the CDs of the Object Design phase:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>NewEra header file containing the class definition</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See <RBW-XREF REFID="27879" TYPE="XREF-TEXTCOPY">Chapter 3, Mapping Modeling Data to NewEra Non&truehy;Persistent Code</RBW-XREF
>, for more details.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Persistent code</L.LABEL
><B.BODY>If the CDs of the Object Design phase contain persistent classes, the NewEra code generator generates files with the same extension as for non&truehy;persistent classes, but with persistent code.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See <RBW-XREF REFID="23603" TYPE="XREF-TEXTCOPY">Chapter 4, Mapping Modeling Data to NewEra Persistent Code</RBW-XREF
>, for more details.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Wifl code</L.LABEL
><B.BODY>If the CDs of the Object Design phase contain GUI classes, the NewEra code generator generates the following file for every GUI class:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Window Intermediate File template containing initial code for the definition of graphical objects</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See <RBW-XREF REFID="16738" TYPE="XREF-TEXTCOPY">Chapter 5, Modeling the User Interface</RBW-XREF
>, for more details.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The following example shows a non&truehy;persistent class from the CD and the matching NewEra 4gl and 4gh files that would be generated. Notice that the function <CX5FX5FTITLE>PrintAmount</CX5FX5FTITLE
> describes how to generate source files for systems in the Implementation phase. This section describes how ObjectTeam converts the SQL Model.<RBW-IDXTERM TERM1="generating code" TERM2="import SQL model"></RBW-IDXTERM
><B.BODY>The SQL Model, which is generated from the CDs in the Object Design phase, contains information used to generate code. It serves as the data model interface to the repository.</B.BODY
> provides a detailed description of the classes in the SQL Model.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How ObjectTeam converts the SQL model</L.LABEL
><B.BODY>To convert the SQL Model, the ObjectTeam Shell (otsh) generates SQL statements for all persistent classes in the CDs in the Object Design phase. It writes these statements to the following SQL script files:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>SQL statements to create procedures that insert tuples in and delete tuples from the target database</CELLBODY
>Configuring Your NewEra Environment</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What is the NewEra environment<RBW-IDXTERM TERM1="NewEra" TERM2="configuring - environment"></RBW-IDXTERM
></L.LABEL
><B.BODY>Configuring your NewEra environment means effectively that the source files of the class library lw4omtne (see <RBW-XREF REFID="18476" TYPE="XREF-TEXTCOPY">Class Library lw4omtne</RBW-XREF
>) are copied over to your user environment. You need to compile these source files using the NewEra Application Builder.</B.BODY
><B.BODY>While building your application, the NewEra Application Builder needs to link the classes of the class library lw4omtne with the classes in your application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What happens when you configure your NewEra environment</L.LABEL
><B.BODY>When you configure your NewEra environment, ObjectTeam carries out the following tasks:</B.BODY
><RBW-PARABODY>The required source files for the specified class libraries are copied to the user_environment<CX5FX5FFILE.NAME>/src/lw4omtne</CX5FX5FFILE.NAME
> directory, where </RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>user_environment is the file path for generated files, as described in the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><RBW-PARABODY>Select the desired option.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>After you press the return key, the next question appears.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to compile the required class libraries</L.LABEL
><B.BODY>After ObjectTeam has copied all the required files, you must compile the libraries. (These libraries are used to compile the source files generated by ObjectTeam.)</B.BODY
><LR.LIST.RESULT>On Windows&truehy;based platforms, an MS&truehy;DOS window appears. </LR.LIST.RESULT
><LR.LIST.RESULT>On Unix&truehy;based platforms, start a new C&truehy;shell by entering the following command in the dialog box that appears: </LR.LIST.RESULT
>Application Builder and compile the class library.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The selected class library is now compiled if your environment is set up properly. The compiled class library is stored in the current directory.</LR.LIST.RESULT
><RBW-PARABODY>Copy the compiled class library to the directory user_environment<CX5FX5FFILE.NAME>/lib</CX5FX5FFILE.NAME
>.</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Adding new options</L.LABEL
><B.BODY>ObjectTeam uses the Tcl script <CX5FX5FFILE.NAME><RBW-IDXTERM TERM1="config_ne.tcl"></RBW-IDXTERM
>config_ne.tcl</CX5FX5FFILE.NAME
> to configure the NewEra environment. You can add new configuration options by creating a customization file with the name <CX5FX5FFILE.NAME>config_ne.tcl</CX5FX5FFILE.NAME
>, as described in <RBW-XREF REFID="23768" TYPE="XREF-TEXTCOPY">Adapting NewEra Configuration Files</RBW-XREF
><B.BODY>When code generation is successful, you can relate each generated source file to a specific class in a CD of the Object Design phase.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>4gh header files</L.LABEL
><B.BODY>The generated header files contain all the necessary include statements and do not need editing. Therefore, when you regenerate a modified model, the 4gh files are overwritten.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>4gl source files for non&truehy;persistent classes</L.LABEL
><B.BODY>The generated 4gl files serve as framework files. They contain a signature for each function (generated from the methods of the classes in the CDs), but the function bodies are empty. You need to fill in the following:</B.BODY
>The bodies of the functions that are defined in the classes. No function is generated for the method, instead, the following line is generated:</RBW-PARABODY
></LB.LIST.BULLET
><EM.EXAMPLE.MONO>&truehy;&truehy; Implement this function!</EM.EXAMPLE.MONO
>You can fill in the function bodies manually or generate them automatically. To generate them automatically, in the CD, specify the method body as the value for the class property Tcl Method Implementation, as described in <RBW-XREF REFID="18195" TYPE="XREF-TEXTCOPY">Tcl Method Implementation Procedure</RBW-XREF
><EM.EXAMPLE.MONO><CX5FX5FFILE.NAME> DISPLAY “The amount is”, amount</CX5FX5FFILE.NAME
> </EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>END FUNCTION</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO></EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>&truehy;&truehy; Start user added source code section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>&truehy;&truehy; End user added source code section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO></EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>&truehy;&truehy; Do not delete this line &truehy;&truehy; regeneration end marker</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>...</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>4gl source file for persistent classes</L.LABEL
><B.BODY>In case of persistent classes, the 4gl source file contains functions that access and manipulate database tables. These functions contain all the necessary statements and do not need editing. When you regenerate a modified model, these source files are overwritten.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Wif template file</L.LABEL
><B.BODY>Wif template files contain Window Intermediate File Language code. You use the NewEra Window Painter to complete and beautify the Graphical User Interface of your application. </B.BODY
><B.BODY>SuperField objects are generated for every attribute defined in a GUI class. You have to supply the function bodies for user&truehy;defined SuperTable Buttons yourself. You can do that using the NewEra Window Painter.</B.BODY
><B.BODY>Whenever you save a wif file in the Window Painter, 4gh and 4gl files are generated by NewEra. These files are used by the Application Builder to build an application. Wif files are not used; they are just intermediate files.</B.BODY
><RBW-PARABODY>In the Information area, double&truehy;click on the source file that you want to edit, or select the source file and then select File | Edit.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The default Text Editor starts up with the corresponding file in the user environment.</LR.LIST.RESULT
>You should edit generated wif template files with the NewEra Window Painter.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Update diagrams</L.LABEL
><B.BODY>Depending on the type of additions you have made to the source files, you may need to edit the CDs to reflect your changes. If you do so, be sure to use Check | Global Model to check the updated diagrams before regenerating the source files.</B.BODY
><B.BODY>If your CDs contain persistent classes, the persistent classes must be defined as database tables in a Relational Database Management System (RDBMS). That database must then be selected when you execute the generated SQL scripts (see <RBW-XREF REFID="37874" TYPE="XREF-TEXTCOPY">SQL Generation</RBW-XREF
>).</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Defining a target database</L.LABEL
><B.BODY>The steps for defining a target database depend on whether you already have the database defined:</B.BODY
><RBW-PARABODY>If you do not have a database defined, you must create the database, select it, then execute the generated SQL scripts to create the database tables. (The SQL scripts are generated when you generate the SQL Model in the Implementation phase.)</RBW-PARABODY
><RBW-PARABODY>If you have a database, but it does not contain the required database tables, you must select the database and execute the generated SQL scripts to create the database tables.</RBW-PARABODY
>Unlike on WindowsNT, you cannot create a new database on Windows95 using Database | Create Database... on the System level of the Implementation phase.</W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated SQL scripts</L.LABEL
><B.BODY>When you generate the SQL Model in the Implementation phase, a number of SQL scripts are generated (<RBW-XREF REFID="32911" TYPE="XREF-TEXTCOPY">Generating SQL Code</RBW-XREF
> provides a list of the scripts). The SQL script to build the target database is <CX5FX5FPROCEDURE.NAME>create</CX5FX5FPROCEDURE.NAME
>. This script activates other SQL scripts containing statements to create tables, procedures and rules.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Database tables that are created</L.LABEL
><B.BODY>When you execute the SQL script <CX5FX5FPROCEDURE.NAME>create</CX5FX5FPROCEDURE.NAME
>, database tables are created for the following persistent objects:</B.BODY
><RBW-PARABODY>To create the database, select Database | Create Database.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The ObjectTeam shell interprets the Tcl script <CX5FX5FFILE.NAME>tdbop.tcl</CX5FX5FFILE.NAME
>, which creates the new database on the specified server if the RDBMS is configured properly. When you create a database, some initial actions are executed, such as the creation of empty system tables for the database and the registration of the database in the Relational Database Management System. </LR.LIST.RESULT
><RBW-PARABODY>All procedural code in the source files must be completely defined for the implementation of methods resulting from messages sent to a class (such as those that change attribute values, perform computations, or send messages to other classes); see <RBW-XREF REFID="19708" TYPE="XREF-TEXTCOPY">Editing (Generated) Source Files</RBW-XREF
><RBW-PARABODY>The environment properly configured for your chosen language; see <RBW-XREF REFID="40480" TYPE="XREF-TEXTCOPY">Configuring Your NewEra Environment</RBW-XREF
>How to compile a library or an executable</L.LABEL
><B.BODY>For building an application you have to use the tools offered by NewEra, such as the Application Builder. The input for the Application Builder are 4gl and 4gh files. </B.BODY
><B.BODY>For details on the Application Builder, refer to your NewEra documentation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Conduct a final check for errors</L.LABEL
><B.BODY>As always, before you distribute anything, conduct a quality check of your work. If necessary, fix the source files, fix the ObjectTeam model, regenerate the code, and retest the executable.</B.BODY
><B.BODY>ObjectTeam supports incremental development. You can generate code from your models, edit that code, and regenerate the code without losing your changes. You can work with models during design and with code during implementation, shifting your focus between the two as necessary.</B.BODY
><B.BODY>It is, however, important that you make changes where appropriate.</B.BODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Change the model</CX5FX5FBULLET.EMPHASIS
> when you are changing the structure of the model (for example, if you are changing the class hierarchy or class associations), or when you are making global changes to the code (for example, if you are changing the name of a class, attribute, or operation).</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing generated 4gh files</L.LABEL
><B.BODY>The generated header files are complete and do not need editing. Therefore, when you regenerate a 4gh file, the new 4gh file overwrites the existing one. Any changes you made to the original 4gh file are lost.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing generated 4gl files</L.LABEL
><B.BODY>The generated 4gl files are framework files that need some additions before they can be turned into an executable or library. Comments in the file indicate where you should add code, as described in <RBW-XREF REFID="19708" TYPE="XREF-TEXTCOPY">Editing (Generated) Source Files</RBW-XREF
>. When you regenerate a 4gl file, the code generator transfers the user&truehy;edited sections from the old file to the newly generated file. </B.BODY
>The code generator preserves only the comment&truehy;delimited areas of the generated 4gl file. Changes you make to other areas of the generated 4gl file are lost when you regenerate the file.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing the ObjectTeam model</L.LABEL
><B.BODY>If you modify the ObjectTeam model, you typically regenerate the 4gh and 4gl source files. As described above, regenerating the 4gh file overwrites the original file and regenerating the 4gl file preserves your changes to the original file. Changes to generated wif files are also preserved.</B.BODY
><B.BODY>If, in the ObjectTeam model, you rename, delete, or change the signature of an operation, the matching function in the generated 4gl file is no longer correct. ObjectTeam preserves the original function, however, you must edit the generated file to correct the code. </B.BODY
><RBW-PARABODY>When you rename or delete an operation, the function in the generated 4gl file is marked as <CX5FX5FBULLET.EMPHASIS>OBSOLETE_CODE</CX5FX5FBULLET.EMPHASIS
>. In this way, the code generator preserves the function in case you want to rename it or move it to another class.</RBW-PARABODY
><RBW-PARABODY>When you change the signature of an operation, the function in the generated 4gl file is marked as <CX5FX5FBULLET.EMPHASIS>OLD_CODE</CX5FX5FBULLET.EMPHASIS
>. This allows you to easily find and edit the affected functions.</RBW-PARABODY
>This chapter explains how particular classes and class specifications result in particular parts of code. </B.BODY
><B.BODY>The first section of the chapter explains some principles of the code generation process. The next sections describe the relationship between class specifications and the generated code. The final section describes generating code for special classes, which follows a different pattern.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
>What is non&truehy;persistent code generation</L.LABEL
><B.BODY>Code generation in ObjectTeam is the process of translating diagrams into program code. The ObjectTeam Shell (otsh) translates the CDs and their related CDMs into source and header files. Code generation involves the following steps:</B.BODY
><RBW-PARABODY>The Tcl interpreter otsh (ObjectTeam Shell) translates the CDs and the CDMs that are stored in the repository into a Code Generation model.</RBW-PARABODY
><B.BODY>You can specify a number of properties for classes that influence the (non&truehy;persistent) code generation. Properties are specified in CDs.</B.BODY
><RBW-PARABODY>Select the object whose properties (class, data attribute, operation, data type, generalization, association) you want to edit.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>If all the following conditions are true, you must click on Define Item to proceed:</LT.LIST.TEXT
><RBW-PARABODY>Select the Text tab to edit the property Free Text or select the Misc tab to edit all the other available properties. For some objects even more tab pages exist.</RBW-PARABODY
><B.BODY>Use this property to specify a class as being a persistent class. By default, a class is non&truehy;persistent. The generated code discussed in this chapter only applies to non&truehy;persistent classes. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information:</SL.SUBLABEL
><B.BODY>Persistent code is discussed in <RBW-XREF REFID="23603" TYPE="XREF-TEXTCOPY">Chapter 4, Mapping Modeling Data to NewEra Persistent Code</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-IDXTERM TERM1="external include list" TERM2="property"></RBW-IDXTERM
><RBW-ANCHOR ID="12344"></RBW-ANCHOR
>External Include List</L.LABEL
><B.BODY>By default, a generated 4gl file contains an INCLUDE statement for the 4gh file generated for the same class. However, if you want to include another header file in the source file, you can specify it through the property External Include List. If you want to specify more than one header file, separate the list of files with commas:</B.BODY
><RBW-IDXTERM TERM1="external class source" TERM2="property"></RBW-IDXTERM
><RBW-ANCHOR ID="18549"></RBW-ANCHOR
>External Class Source</L.LABEL
><B.BODY>It can be useful to model classes for which source files and header files are already available.</B.BODY
><B.BODY>With the property External Class Source, you can specify the name of a 4gh file (and the name of a 4gl file), separated by commas. During code generation, the contents of these files are copied to the files <CX5FX5FFILE.NAME>class_name.4gh</CX5FX5FFILE.NAME
> and <CX5FX5FFILE.NAME>class_name.4gl</CX5FX5FFILE.NAME
>, respectively. If you specify only one file name, the contents of this file is copied to the file <CX5FX5FFILE.NAME>class_name.4gh</CX5FX5FFILE.NAME
>.</B.BODY
><B.BODY>The following figure shows an example of a value for the property External Class Source:</B.BODY
>The contents of the first file is always copied over into the file <CX5FX5FFILE.NAME>classname.4gh</CX5FX5FFILE.NAME
>, the contents of the second, if specified, into <CX5FX5FFILE.NAME>classname.4gl</CX5FX5FFILE.NAME
>. So if you specify a 4gh file after a 4gl file, the contents of the 4gh file is copied into <CX5FX5FFILE.NAME>classname.4gl</CX5FX5FFILE.NAME
> and the contents of the 4gl file into <CX5FX5FFILE.NAME>classname.4gh</CX5FX5FFILE.NAME
>.</W.WARNING
><B.BODY>You can specify the entire path of the file name(s), but you can also specify only the file names and include the directory these files are stored in in the search path. You can customize this search path by editing the value for the global variable <CX5FX5FOBJECT.NAME>exsrc_searchpath</CX5FX5FOBJECT.NAME
> in the customization file <CX5FX5FFILE.NAME>ne_config.tcl</CX5FX5FFILE.NAME
><RBW-PARABODY>Edit the following line:</RBW-PARABODY
></LN.LIST.NUM
><EM.EXAMPLE.MONO># set exsrc_searchpath "c:;c:\\temp"</EM.EXAMPLE.MONO
><LT.LIST.TEXT>Remove the hatch mark, used for comments in Tcl, and specify your own search path. If you are including more than one search directory, use semicolons to separate them.</LT.LIST.TEXT
><B.BODY>You can now specify any file that resides in the specified search directory ss External Class Source property, without having to specify its absolute path.</B.BODY
><B.BODY>A dollar sign ($) before a data attribute name indicates a class feature. This results in the generation of an attribute with the leading NewEra keyword SHARED, indicating it is a shared data member.</B.BODY
><B.BODY>The header file generated for a class containing one class feature looks like this:</B.BODY
><B.BODY>A forward slash (/) before a data attribute name indicates a derived attribute. However, these forward slashes are ignored by the NewEra code generator.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Data types</L.LABEL
><B.BODY>You can <RBW-IDXTERM TERM1="data attribute" TERM2="specifying data type"></RBW-IDXTERM
>specify two kinds of data types:<RBW-IDXTERM TERM1="data type" TERM2="standard"></RBW-IDXTERM
><RBW-PARABODY>Other types defined as classes in a CD.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Initial value</L.LABEL
><B.BODY>The initial value of a data attribute is used to assign a value to the data member. If the object initialization parameters of the constructor are automatically generated (see <RBW-XREF REFID="24711" TYPE="XREF-TEXTCOPY">Constructor</RBW-XREF
>) this assignment is generated in the body of the constructor:</B.BODY
><EM.EXAMPLE.MONO> LET att1 = <CX5FX5FFILE.NAME>60</CX5FX5FFILE.NAME
> </EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> &truehy;&truehy; Start constructor user section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> &truehy;&truehy; End constructor user section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>END FUNCTION</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>...</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section describes the properties that can be specified for data attributes, then provides examples of how data attributes are translated into NewEra code:</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="25712" TYPE="XREF-TEXTCOPY">Examples: Data Attributes and NewEra&rbwtab;3–15</RBW-XREF
><B.BODY>This section describes data attribute properties that affect the (non&truehy;persistent) code generation. For instructions on how to specify properties, see <RBW-XREF REFID="10851" TYPE="XREF-TEXTCOPY">How to specify properties</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Data Attribute properties</L.LABEL
><B.BODY>The following figure shows part of an Edit Properties dialog box:</B.BODY
><B.BODY>When this property is set, a constant data member for the class is generated instead of a variable data member. A constant data member needs an initializing value. No <CX5FX5FPROCEDURE.NAME>get</CX5FX5FPROCEDURE.NAME
> and <CX5FX5FPROCEDURE.NAME>set</CX5FX5FPROCEDURE.NAME
> functions are generated for a constant attribute.</B.BODY
><B.BODY>When the data type of the attribute is another class you can control the action of the NewEra COPY operator by supplying the appropriate copy qualification.</B.BODY
><B.BODY>NewEra copies the values of normal data members from the source object to the created object using the COPY operator. The copy qualification is post fixed to the variable declaration.</B.BODY
><B.BODY>You can select the following qualifications:</B.BODY
>nullable attribute is an attribute that doesn’t necessarily have a value. In NewEra, the attribute is added to the <RBW-IDXTERM TERM1="constructor" TERM2="not nullable attribute"></RBW-IDXTERM
>parameter list of the constructor, if it is not nullable. </B.BODY
><B.BODY>The following nullability values are available:</B.BODY
> (=read) and <CX5FX5FPROCEDURE.NAME>set</CX5FX5FPROCEDURE.NAME
> (=write) member functions that are generated from the data attributes can be specified as <RBW-IDXTERM TERM1="public section" TERM2="accessibility"></RBW-IDXTERM
>Examples: Data Attributes and NewEra</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>The following table shows various data attributes you can specify in classes and the most significant part of the resulting code. The Attribute Access property determines the accessibility of the <CX5FX5FFILE.NAME>get</CX5FX5FFILE.NAME
> and <CX5FX5FFILE.NAME>set</CX5FX5FFILE.NAME
> member functions: public, protected or private.</B.BODY
><B.BODY>All classes in the examples have a <CX5FX5FOBJECT.NAME>$create</CX5FX5FOBJECT.NAME
> operator so that code can be generated for them. Without this operator the classes would have been special classes.</B.BODY
><B.BODY>A dollar sign ($) before an operation name indicates a class feature. This results in the generation of an operation with the leading NewEra keyword SHARED, indicating it is a shared function of the class.</B.BODY
><B.BODY>The header file generated for a class containing such a class feature looks like this:</B.BODY
><EM.EXAMPLE.MONO> PUBLIC <CX5FX5FFILE.NAME>SHARED</CX5FX5FFILE.NAME
> FUNCTION opr() RETURNING VOID</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> ...</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Parameters</L.LABEL
><B.BODY>A parameter in the parameter list of an operation must be specified according to the following syntax:</B.BODY
><E.EXAMPLE>name:type</E.EXAMPLE
><B.BODY>This results in a function argument in both the function declaration (4gh) and in the function definition (4gl). The <CX5FX5FTERM>type</CX5FX5FTERM
> must either be a standard type (see <RBW-XREF REFID="42656" TYPE="XREF-TEXTCOPY">Customizing Data Types</RBW-XREF
>) or a class modeled in a CD.</B.BODY
><B.BODY>The following example shows how an operation with two specified parameters is generated:</B.BODY
><B.BODY>The function definition generated in the 4gl file of the class has no contents besides the comment lines, prompting you to implement the function.</B.BODY
><B.BODY>For certain general purpose functions, you can use the operation property Tcl Method Implementation Procedure, which is discussed in <RBW-XREF REFID="18195" TYPE="XREF-TEXTCOPY">Tcl Method Implementation Procedure</RBW-XREF
> and further.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Inclusion of header files</L.LABEL
><B.BODY>When the implementation of a (generated) function requires inclusion of certain header files, you can enter the include statement in the user include file section at the top of the 4gl file. This section is marked by the following two comment lines:</B.BODY
><EM.EXAMPLE.MONO>&truehy;&truehy; Start user added include file section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>&truehy;&truehy; End user added include file section</EM.EXAMPLE.MONO
>These edits are preserved when you regenerate the file.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Return type</L.LABEL
><B.BODY>The return type for an operation must be either a standard type (see <RBW-XREF REFID="42656" TYPE="XREF-TEXTCOPY">Customizing Data Types</RBW-XREF
>) or a class modeled in a CD.</B.BODY
><B.BODY>The following example shows how an operation with two parameters and a return type specified is generated:</B.BODY
><B.BODY>Abstract operations are not supported in NewEra. The ObjectTeam code generator therefore ignores <CX5FX5FINPUT>{abstract}</CX5FX5FINPUT
> specified for operations other than <CX5FX5FINPUT>$create</CX5FX5FINPUT
>. </B.BODY
><B.BODY>When you use <CX5FX5FINPUT>{abstract}</CX5FX5FINPUT
> in combination with a <CX5FX5FINPUT>$create</CX5FX5FINPUT
> operation, the generated constructor does not get access control qualification PUBLIC, even when the property Method Access is set to Public (see <RBW-XREF REFID="29834" TYPE="XREF-TEXTCOPY">Method Access</RBW-XREF
>).</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section provides examples of how operations are translated into NewEra and what effect the properties have.</B.BODY
><B.BODY>This section describes operation properties that affect non&truehy;persistent code generation. For instructions on how to specify properties, see <RBW-XREF REFID="10851" TYPE="XREF-TEXTCOPY">How to specify properties</RBW-XREF
>.</B.BODY
><B.BODY>The following figure shows part of the Edit Properties dialog box for the class Product:</B.BODY
>Method Access to indicate in which section the member function must be placed.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="31329"></RBW-ANCHOR
>Visibility</SL.SUBLABEL
><B.BODY>You can display the access level of methods in your diagram by checking Options | Show Visibility in the Class Diagram Editor. Method names will then be displayed with the following leading characters indicating the method’s access level:</B.BODY
><B.BODY>These special characters can also be used to <CX5FX5FEMPHASIS>set</CX5FX5FEMPHASIS
> the access level of methods. Typing a minus sign (&truehy;) before a method name will set the access level of the method to Private, for example. </B.BODY
>The special characters only work if the menu entry Options | Show Visibility in the Class Diagram Editor has been checked. Otherwise, the special characters will just be regarded as part of the method name.</W.WARNING
><RBW-PARABODY>Make sure the current browser level is the System level of the Implementation phase. The current system must be the system you are generating the code in.</RBW-PARABODY
><LT.LIST.TEXT>This procedure generates the source code for a particular function with a very general purpose such as a <CX5FX5FPROCEDURE.NAME>printOn</CX5FX5FPROCEDURE.NAME
><LT.LIST.TEXT>Such a <CX5FX5FPROCEDURE.NAME>printOn</CX5FX5FPROCEDURE.NAME
> function prints all the data members of a class to standard output. You can use this kind of function for any class. The contents of the function is the same for every class; only the class differs.</LT.LIST.TEXT
><LT.LIST.TEXT>Use the following syntax when creating the Tcl procedure:</LT.LIST.TEXT
><RBW-PARABODY>Specify the value of the property Tcl Method Implementation Procedure as the name that you specified for the Tcl procedure (without <CX5FX5FINPUT>operation::</CX5FX5FINPUT
><RBW-PARABODY>Select Utilities | Import From Previous Phase | OOPL on the System level of the Implementation phase.</RBW-PARABODY
></LN.LIST.NUM
><B.BODY>Now the body of the method is automatically generated every time you generate code for the class. The ObjectTeam Shell calls this procedure and inserts the code generated by the procedure as the body of the method:</B.BODY
><RBW-IDXTERM TERM1="Event" TERM2="property for a method"></RBW-IDXTERM
><RBW-ANCHOR ID="33377"></RBW-ANCHOR
>Event</L.LABEL
><B.BODY>Set this property to indicate that an operation models an event rather than a function.</B.BODY
><B.BODY>If this property is set, an EVENT statement is generated in the header file instead of a FUNCTION statement. No code is generated in the source file, but you can place one or more event handlers between the following markers in the generated source file:</B.BODY
><EM.EXAMPLE.MONO>&truehy;&truehy;start user added source code section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>&truehy;&truehy;end user added source code section</EM.EXAMPLE.MONO
><B.BODY>The following example shows various operations you can specify in classes and the most significant part of the resulting source code. The Method Access property determines the accessibility of the method: public, protected or private.</B.BODY
>Specify only one constructor for a class. As NewEra does not support function overloading, it is not possible for a class to have multiple constructors.</W.WARNING
><B.BODY>The constructor, together with the parameters required for initializing an object of the class correctly, is automatically generated if the class meets the following requirements:</B.BODY
><RBW-PARABODY>A link attribute box is linked to a (qualified) association</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>Examples of generated constructors in these particular situations can be found on the following pages.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Sub class</L.LABEL
><B.BODY>In the following example, sub class classA2 is derived from the super class classA1. The super class is initialized in the constructor of classA2:</B.BODY
>Linked attributes in a qualified association</L.LABEL
><B.BODY>The following example includes a qualified association with a link attribute box containing one attribute (<CX5FX5FOBJECT.NAME>attE3</CX5FX5FOBJECT.NAME
>). This link attribute box results in the generation of a class with the name of the association (<CX5FX5FOBJECT.NAME>assoc</CX5FX5FOBJECT.NAME
>). The same elements are included in the parameter list of the constructor of class <CX5FX5FOBJECT.NAME>assoc</CX5FX5FOBJECT.NAME
> as for the linked class in the previous example.</B.BODY
><B.BODY>The following example shows the (empty) constructor generated for a class with a class operation <CX5FX5FOBJECT.NAME>$create()</CX5FX5FOBJECT.NAME
>. There is one parameter specified for this operation:</B.BODY
><EM.EXAMPLE.MONO> &truehy;&truehy; Start destructor user section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> &truehy;&truehy; End destructor user section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>END FUNCTION</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>...</EM.EXAMPLE.MONO
><B.BODY>The destructor may contain more statements, since the destructor is tightly coupled with the constructor. If the generated constructor contains several statements for initialization, the destructor contains the corresponding statements to remove these initializations.</B.BODY
><B.BODY>Only the standard generalization is supported by NewEra. If an overlapping generalization is encountered by the ObjectTeam code generator, a warning is issued and no code is generated.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Discriminator</L.LABEL
><B.BODY>The discriminator that you can specify for a generalization in a CD is not used in the NewEra code generation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="40575"></RBW-ANCHOR
>Generalization Properties</L.LABEL
><B.BODY>There are no generalization properties that affect non&truehy;persistent code generation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="22032"></RBW-ANCHOR
>Examples: Generalizations and NewEra</L.LABEL
><B.BODY>The following examples show a generalization with standard inheritance: one super class and one sub class.</B.BODY
><RBW-PARABODY>There is a role name specified at the far end of the association joined to the class or there is a qualifier specified at the near end</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>The following two types of features are generated for an association:</B.BODY
><B.BODY>An association between two classes in a CD results in the generation of data members in one or both classes. These data members are referred to as <CX5FX5FTERM>association attributes</CX5FX5FTERM
>. They always have public access in order to keep the association up&truehy;to&truehy;date.</B.BODY
><B.BODY>An association attribute implements one side of the association. Its type depends on:</B.BODY
>For qualified associations, different association attributes are generated. See <RBW-XREF REFID="33064" TYPE="XREF-TEXTCOPY">Qualified Associations</RBW-XREF
> for details.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Member functions</L.LABEL
><B.BODY>To manipulate the association attributes, the following member functions are generated in the class containing the association attribute.</B.BODY
> and <CX5FX5FPROCEDURE.NAME>remove</CX5FX5FPROCEDURE.NAME
> functions are derived from the role name at the other side. Bear in mind that, in case of a mandatory association at the side of the other class, the <CX5FX5FPROCEDURE.NAME>remove</CX5FX5FPROCEDURE.NAME
> function is not generated.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section describes associations, association properties and it gives examples of how different types of associations are generated into NewEra code.</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="17049" TYPE="XREF-TEXTCOPY">Association with Link Objects&rbwtab;3–39</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="38082" TYPE="XREF-TEXTCOPY">Examples: Associations and NewEra&rbwtab;3–40</RBW-XREF
><B.BODY>This section describes properties that can be specified for role starts and role ends in associations to influence the (non&truehy;persistent) code generation. For instructions on how to specify properties, see <RBW-XREF REFID="10851" TYPE="XREF-TEXTCOPY">How to specify properties</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Which association properties can you specify</L.LABEL
><B.BODY>The following association property affects non&truehy;persistent code generation:</B.BODY
><B.BODY>Use this property to determine the access control qualification of the association. You can set it for role start and role end elements.</B.BODY
><B.BODY>The NewEra code generator interprets an association between two classes with a link object as two associated classes both having an association with a third class representing the link object. The normal rules for associations apply to these (qualified) associations.</B.BODY
><B.BODY>Data members and <RBW-IDXTERM TERM1="member function"></RBW-IDXTERM
>member functions are generated for each of the two <RBW-IDXTERM TERM1="class" TERM2="association attribute"></RBW-IDXTERM
>classes if there is a role name specified at the other end of the association. Association attributes are always generated for the third class, i.e. two get functions, one for each class.</B.BODY
>Examples: Associations and NewEra</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>On the following pages you can find three examples of associations with different multiplicity and the 4gh code that is generated. The multiplicities are:</B.BODY
><B.BODY>For an example of how you can use the generated code for an association with a multiplicity of many, refer to <RBW-XREF REFID="22344" TYPE="XREF-TEXTCOPY">Using the Code Generated from an Association</RBW-XREF
></B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Multiplicity: many (mandatory)</L.LABEL
><B.BODY>The following example CD contains an association with a multiplicity of many (mandatory).</B.BODY
><B.BODY>The following association contains a link attribute box which is attached to the association between two classes. Three classes are generated for this association:</B.BODY
><RBW-IDXTERM TERM1="libwmt4omt" TERM2="generation of associations"></RBW-IDXTERM
><RBW-ANCHOR ID="22344"></RBW-ANCHOR
>Using the Code Generated from an Association</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This section contains an example of an association with a multiplicity of <CX5FX5FOBJECT.NAME>many</CX5FX5FOBJECT.NAME
>. It gives you some examples of the NewEra code you could write that uses the generated non&truehy;persistent NewEra code for this association. The following actions are involved:</B.BODY
><RBW-PARABODY>retrieve class occurences</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example CD</L.LABEL
><BI.BODY.INTRO>The following picture shows an example of an association with a multiplicity of many (zero or more) at one side, together with a sample of the generated header file. The class at the side of the many association end acts as detail (<CX5FX5FINPUT>classB</CX5FX5FINPUT
>), the class at the other side as master (<CX5FX5FINPUT>classA</CX5FX5FINPUT
><B.BODY>In our example, the name of this <CX5FX5FPROCEDURE.NAME>get</CX5FX5FPROCEDURE.NAME
> function is: <CX5FX5FINPUT>getDetailSet</CX5FX5FINPUT
>. </B.BODY
><B.BODY>The type of this member function getDetailSet is <CX5FX5FOBJECT.NAME><RBW-IDXTERM TERM1="PtrSet"></RBW-IDXTERM
>RefSet</CX5FX5FOBJECT.NAME
>. <CX5FX5FOBJECT.NAME>RefSet</CX5FX5FOBJECT.NAME
> is one of the storage structure classes that are included in the class library <CX5FX5FOBJECT.NAME><RBW-IDXTERM TERM1="libwmt4omt"></RBW-IDXTERM
><RBW-IDXTERM TERM1="class library" TERM2="used to generate associations"></RBW-IDXTERM
>lw4omtne</CX5FX5FOBJECT.NAME
> (see <RBW-XREF REFID="18476" TYPE="XREF-TEXTCOPY">Class Library lw4omtne</RBW-XREF
>). It is used for Reference Sets. Typical member functions of the class <CX5FX5FOBJECT.NAME>RefSet</CX5FX5FOBJECT.NAME
> are first() and next(). These functions return the references to the detail class occurrences that participate in the association.</B.BODY
><B.BODY>Before you are able to retrieve (<CX5FX5FPROCEDURE.NAME>get</CX5FX5FPROCEDURE.NAME
>) class occurrences from a RefSet class, these occurrences first have to be added to the association. The master class contains member functions which allow adding (and removing) detail class occurrences. Bear in mind that the class <CX5FX5FINPUT>RefSet</CX5FX5FINPUT
> only stores the <CX5FX5FTERM>references</CX5FX5FTERM
> to the class. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example code</L.LABEL
><B.BODY>In the following example main.4gl file, constructions typical for the following actions are included:</B.BODY
>Data members / Qualified Association attributes</L.LABEL
><B.BODY>A qualified association between two classes in a CD results in the generation of data members and member functions in one or both classes. The data members are referred to as qualified association attributes. These association attributes always have public access in order to keep the qualified association up&truehy;to&truehy;date.</B.BODY
><B.BODY>A qualified association attribute is generated if the following conditions are met:</B.BODY
><RBW-PARABODY>the multiplicity at the side of the other class (one, many, optional)</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>The table below lists the name and the type of the association attribute generated for these qualified associations in the header file:</B.BODY
><B.BODY>To manipulate the association attributes, the following member functions are generated in the class containing the qualified association attribute:</B.BODY
> and <CX5FX5FPROCEDURE.NAME>remove</CX5FX5FPROCEDURE.NAME
> functions are derived from the role name at the other side. Bear in mind that, in case of a mandatory association at the side of the other class, the remove function is not generated.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section describes qualified associations, qualified association properties and it gives examples of how different types of qualified associations are generated into NewEra code.</B.BODY
><B.BODY>For instructions on how to specify properties, see <RBW-XREF REFID="10851" TYPE="XREF-TEXTCOPY">How to specify properties</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Which qualified association properties can you specify</L.LABEL
><B.BODY>For qualified associations, the same properties can be specified as for non&truehy;qualified associations (see <RBW-XREF REFID="40839" TYPE="XREF-TEXTCOPY">Association Properties</RBW-XREF
>).</B.BODY
><B.BODY>The following additional can be specified for the qualifier in qualified associations:</B.BODY
><B.BODY>The data type of a qualifier must be the same as the type of the key in the data structure that implements the qualified association. In case of the data structures RefDict and RSetDict (see <RBW-XREF REFID="28529" TYPE="XREF-TEXTCOPY">Data members / Qualified Association attributes</RBW-XREF
>) the type is ixObject, so that any NewEra class could serve as qualifier type.</B.BODY
><B.BODY>Examples of valid NewEra class names are: ixInteger and ixString.</B.BODY
><B.BODY>The following example CD contains an association with a multiplicity of many (optional). For association with a mandatory multiplicity, similar code is generated.</B.BODY
><B.BODY>NewEra does not support special classes.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>For more information on special classes in C++, refer to the <CX5FX5FTITLE>ObjectTeam Code Generation Guide for C++</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Why should I care about special classes</L.LABEL
><B.BODY>If NewEra does not support special classes, why should you care about them? Well, if you model a class the same way as you would in C++ to generate a special class, the constructor function is not generated.</B.BODY
><B.BODY>For example, for the following class, no constructor is generated:</B.BODY
>class is a class whose instances persists beyond the lifetime of a single program execution. The public interface of the persistent class is similar to that of the non&truehy;persistent classes. The implementation however, is completely different because of the storage of the data members in a relational database. </B.BODY
><B.BODY>The persistent code generation process involves the generation of two types of code:</B.BODY
><RBW-PARABODY>Persistent NewEra code, as described in <RBW-XREF REFID="13730" TYPE="XREF-TEXTCOPY">Persistent NewEra Code Generation</RBW-XREF
></RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="11158"></RBW-ANCHOR
>How do you create a persistent class</L.LABEL
><B.BODY>You create a persistent class in a CD by setting the property Persistent for the class. For instructions on specifying properties, see <RBW-XREF REFID="10851" TYPE="XREF-TEXTCOPY">How to specify properties</RBW-XREF
>.</B.BODY
><B.BODY>A persistent class needs at least one key attribute. You can specify a key attribute by entering a leading asterisk (*) in the name of the attribute. You cannot specify key attributes for sub classes in a generalization, however: sub classes inherit key attributes from their super class.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>Key attributes are further discussed in <RBW-XREF REFID="24397" TYPE="XREF-TEXTCOPY">Key attributes</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>In the following example, the attribute <CX5FX5FOBJECT.NAME>name</CX5FX5FOBJECT.NAME
> is the key attribute in the persistent class Patient:</B.BODY
><B.BODY>Apart from setting the property Persistent and specifying a key attribute, the same rules apply for modeling persistent classes as for non&truehy;persistent classes. (see <RBW-XREF REFID="27879" TYPE="XREF-TEXTCOPY">Chapter 3, “Mapping Modeling Data to NewEra Non&truehy;Persistent Code”</RBW-XREF
>).</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What code is generated for a persistent class</L.LABEL
><B.BODY>In persistent code generation, ObjectTeam uses a Relational Data Base Management System (RDBMS) to store data for persistent class objects.</B.BODY
><B.BODY>So besides NewEra classes, the NewEra code generator generates SQL scripts for creating and destroying database tables and procedures. A runtime system takes care of the mapping of generated NewEra classes onto the target RDBMS.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>For details on the runtime system in combination with NewEra classes, see <RBW-XREF REFID="17255" TYPE="XREF-TEXTCOPY">The Runtime System</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Which RDBMSs are supported</L.LABEL
><B.BODY>At the moment Informix is the only supported RDBMS for NewEra persistent code generation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><B.BODY>SQL code is generated for every persistent class in the CDs residing in the same system of the Object Design phase.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Where does SQL fit in</L.LABEL
><B.BODY>The mapping of persistent classes on a relational database is carried out through the runtime system (see <RBW-XREF REFID="17255" TYPE="XREF-TEXTCOPY">The Runtime System</RBW-XREF
>). The Data Definition Language (DDL) used to create this runtime system in ObjectTeam is SQL. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated SQL files</L.LABEL
><B.BODY>The following SQL script files are generated during SQL generation:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Contains SQL code for procedure creation. For every database table that is defined, the database operations <CX5FX5FTERM>delete</CX5FX5FTERM
>, <CX5FX5FTERM>insert</CX5FX5FTERM
> and <CX5FX5FTERM>update</CX5FX5FTERM
> are generated. These procedures also handle referential integrity</CELLBODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="21074" TYPE="XREF-TEXTCOPY">Association with a Link Object&rbwtab;4–16</RBW-XREF
><B.BODY>In the simplest situation one persistent class maps to one table. Each persistent class is mapped to an SQL table, and the table rows are instances of the class. The user&truehy;defined key attribute(s) together with the automatically generated class_type attribute serve as a system wide unique identification.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The following CREATE TABLE statements are generated for one persistent class:</B.BODY
><B.BODY>You specify a data attribute as being a key attribute by putting a leading asterisk in the name. You can specify multiple key attributes. All the key attributes, together with the attribute <CX5FX5FOBJECT.NAME>class_type</CX5FX5FOBJECT.NAME
> (see <RBW-XREF REFID="24933" TYPE="XREF-TEXTCOPY">The attribute class_type</RBW-XREF
>), make up the primary key of the class.</B.BODY
><B.BODY>As key attributes always need a value, the keywords NOT NULL are generated for every key attribute in a class, e.g.:</B.BODY
><B.BODY>The data attribute <CX5FX5FOBJECT.NAME>name</CX5FX5FOBJECT.NAME
> is the only key attribute in this example.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Standard Types</L.LABEL
><B.BODY>In CDs, standard data types are used to define the data type of an attribute. These data types are mapped to target&truehy;dependent database types during persistent code generation. </B.BODY
><B.BODY>The standard data types can be found in the customization file:</B.BODY
><B.BODY>The setting of this property determines whether or not an attribute is allowed to have a NULL value. The <CX5FX5FOBJECT.NAME>default</CX5FX5FOBJECT.NAME
> value of this property is <CX5FX5FOBJECT.NAME>yes</CX5FX5FOBJECT.NAME
>.</B.BODY
><B.BODY>If you set the property Nullable to <CX5FX5FOBJECT.NAME>no</CX5FX5FOBJECT.NAME
>, the keywords NOT NULL are generated after the data type of the column. Key attributes and the attribute <CX5FX5FOBJECT.NAME>class_type</CX5FX5FOBJECT.NAME
> always have these keywords generated.</B.BODY
><B.BODY>In the following example the property Nullable is set to <CX5FX5FOBJECT.NAME>no</CX5FX5FOBJECT.NAME
> for the attribute <CX5FX5FOBJECT.NAME>address</CX5FX5FOBJECT.NAME
><EM.EXAMPLE.MONO> address CHAR(50) NOT NULL,</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> ...</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>);</EM.EXAMPLE.MONO
><B.BODY>The effect the property values <CX5FX5FOBJECT.NAME>yes</CX5FX5FOBJECT.NAME
> and <CX5FX5FOBJECT.NAME>default</CX5FX5FOBJECT.NAME
> have are the same. If you want attributes to be non&truehy;nullable by default, you have to adapt the NewEra code generator. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="24933"></RBW-ANCHOR
>The attribute class_type</L.LABEL
><B.BODY>For every persistent class a data attribute <CX5FX5FOBJECT.NAME>class_type</CX5FX5FOBJECT.NAME
> is generated in the SQL code. This attribute is part of the primary key of every table.The main function of the attribute <CX5FX5FOBJECT.NAME>class_type</CX5FX5FOBJECT.NAME
> is to handle classes in generalizations. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>More information on generalizations can be found in <RBW-XREF REFID="23357" TYPE="XREF-TEXTCOPY">Generalization</RBW-XREF
>Generalization<RBW-IDXTERM TERM1="generalization" TERM2="example of generated SQL code"></RBW-IDXTERM
></SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Master&truehy;detail pairs</L.LABEL
><B.BODY>In a generalization, the super class acts as master and the subclass as detail. In the following example diagram, the master&truehy;detail pairs are:</B.BODY
><B.BODY>Referential Integrity is further discussed in <RBW-XREF REFID="24352" TYPE="XREF-TEXTCOPY">Customizing Referential Integrity Policies</RBW-XREF
><B.BODY>Which SQL code is generated for persistent classes in an association depends on the multiplicity of the association. This subsection contains some examples of associations with a different multiplicity.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Properties</L.LABEL
><B.BODY>The following association properties affect SQL code generation:</B.BODY
><B.BODY>Referential Integrity is further discussed in <RBW-XREF REFID="24352" TYPE="XREF-TEXTCOPY">Customizing Referential Integrity Policies</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Multiplicity: one (optional)</L.LABEL
><B.BODY>In relationships that meet the following multiplicity requirements, it does not matter which table acts as master and which as detail:</B.BODY
><RBW-PARABODY>a multiplicity that is not <CX5FX5FTERM>many</CX5FX5FTERM
> at the other side</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>However, since there has to be a master and a detail, the rule is that the destination class becomes master. The destination class is the class <CX5FX5FTERM>to</CX5FX5FTERM
> which the association was drawn in the CD. The class <CX5FX5FTERM>from</CX5FX5FTERM
> which the association was drawn becomes the detail. </B.BODY
><B.BODY>The association in the diagram below meets the requirements. The master&truehy;detail pair is:</B.BODY
><B.BODY>although it could have been B(master) &truehy; A(detail) too. Which class is destination class cannot be detected in the diagram. You could detect this, though, using the Properties dialog box. The role name at the side of the the source class is called <CX5FX5FTERM>Association Role At Start</CX5FX5FTERM
> and the one at the side of the destination class <CX5FX5FTERM>Association At Role End</CX5FX5FTERM
>If you draw an association with a multiplicity of one (mandatory) at both sides no sql scripts will be generated because of insert policy conflicts. The following error message is issued:</W.WARNING
><E.EXAMPLE>ERROR [340023]: Conflict in the insert policies between detail table ‘classC2’ and master table ‘classC1’. They are excluding each other.</E.EXAMPLE
><B.BODY>Refer to <RBW-XREF REFID="31513" TYPE="XREF-TEXTCOPY">SQL types</RBW-XREF
> for details.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Multiplicity: many (optional)</L.LABEL
><B.BODY>In relationships that meet the following requirements, the class at the end of the <CX5FX5FTERM>many</CX5FX5FTERM
> multiplicity acts as detail in the master&truehy;detail pair:</B.BODY
>Association with a <RBW-IDXTERM TERM1="link attribute" TERM2="in persistent (SQL) code generation"></RBW-IDXTERM
>Link Object</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Master&truehy;detail pairs</L.LABEL
><B.BODY>In associations that have a class or a link attribute box associated to them, the associative object acts as detail in the master&truehy;detail&truehy;pairs. In the example diagrams depicted below, the master&truehy;detail pairs are:</B.BODY
><B.BODY>The SQL code generated for qualified associations is similar to the code generated for non&truehy;qualified associations (see <RBW-XREF REFID="21782" TYPE="XREF-TEXTCOPY">Association</RBW-XREF
>). </B.BODY
><B.BODY>Additionally, an extra table with the same name as the association is generated for qualified associations. The association must not have a class or link attribute associated to it. </B.BODY
><B.BODY>The NewEra code generator generates NewEra classes from persistent classes in CDs. A runtime system takes care of the mapping of these generated classes onto the target RDBMS.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section contains a description of the runtime system used to map NewEra classes onto the target RDBMS. It contains the following subsections, and it discusses how certain constructions are generated into NewEra code:</B.BODY
><B.BODY>The runtime system takes care of the mapping of persistent classes onto the target database. One of the main elements in the runtime system is the class DBObject, which is part of the class library <CX5FX5FOBJECT.NAME>lw4omtne</CX5FX5FOBJECT.NAME
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information:</L.LABEL
><B.BODY>The functions the class DBObject offers are discussed in <RBW-XREF REFID="14975" TYPE="XREF-TEXTCOPY">The Class DBObject</RBW-XREF
>. </B.BODY
><B.BODY>The generated member functions for persistent classes for the purpose of the runtime system are discussed in <RBW-XREF REFID="22004" TYPE="XREF-TEXTCOPY">Generated Functions</RBW-XREF
>.</B.BODY
><B.BODY>The generation of SQL scripts, which is also part of the runtime system, is discussed elsewhere in this manual, in <RBW-XREF REFID="37874" TYPE="XREF-TEXTCOPY">SQL Generation</RBW-XREF
>. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Root class</L.LABEL
><B.BODY>In this sub section, the term <CX5FX5FOBJECT.NAME>persistent root class</CX5FX5FOBJECT.NAME
> is used. It refers to a persistent class that has no super class. Persistent sub classes in a generalization are treated differently from persistent root classes.</B.BODY
><B.BODY>The class DBObject is part of the class library <CX5FX5FOBJECT.NAME>lw4omtne</CX5FX5FOBJECT.NAME
> (see <RBW-XREF REFID="18476" TYPE="XREF-TEXTCOPY">Class Library lw4omtne</RBW-XREF
>). It offers some general functions regarding database connection and transaction support for the runtime system. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Functions</L.LABEL
><B.BODY>Below, functions for database connection and transaction support are listed, together with some brief comments. The comments have leading dashes (&truehy;&truehy;):</B.BODY
><EWM.EXAMPLEW.MONO>&truehy;&truehy; Connect to the specified database, using the specified connection object.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>&truehy;&truehy; This function must be called before any database operation can be executed.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>&truehy;&truehy; When no connection object is specified, the implicit connection object is</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>&truehy;&truehy; used. Returns 0 on success, else &truehy;1.</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>SHARED FUNCTION <CX5FX5FFILE.NAME>commit</CX5FX5FFILE.NAME
>() RETURNING INTEGER</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>SHARED FUNCTION <CX5FX5FFILE.NAME>rollback</CX5FX5FFILE.NAME
>() RETURNING INTEGER</EWM.EXAMPLEW.MONO
><B.BODY>The class DBObject also serves as base class for every persistent root class. (A root class is a persistent class without a super class). It provides every persistent class with the following interface:</B.BODY
><EWM.EXAMPLEW.MONO>&truehy;&truehy; Get the case sensitive class name of the object.</EWM.EXAMPLEW.MONO
><B.BODY>The NewEra code generator generates a number of member functions for classes on the purpose of the runtime system. Some of these functions are generated for all classes and some exclusively for persistent root classes. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="17541"></RBW-ANCHOR
>Functions generated exclusively for persistent root classes </L.LABEL
><B.BODY>The following functions are generated for root classes only. You can call them directly.</B.BODY
>Functions generated for all persistent classes </L.LABEL
><B.BODY>The following functions for writing objects to and reading objects from the database are generated for all persistent classes. You can call these functions directly:</B.BODY
><B.BODY></B.BODY
><EWM.EXAMPLEW.MONO>&truehy;&truehy; Insert a new persistent object in the database. New in this context means</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>&truehy;&truehy; that the object does not yet exist in the database. This function is</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>&truehy;&truehy; typically used after a persistent object has been instantiated and its</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>&truehy;&truehy; attributes are set. After calling this function the data in the database</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>&truehy;&truehy; is up to date with the data in the object itself. Returns 0 on success,</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>PUBLIC FUNCTION <CX5FX5FFILE.NAME>updateInDB</CX5FX5FFILE.NAME
>() RETURNING INTEGER</EWM.EXAMPLEW.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Functions generated for instantiating a persistent class through the function findInDB</L.LABEL
><B.BODY>A number of generated functions are needed by the runtime system to instantiate a persistent class through the function <CX5FX5FOBJECT.NAME>findInDB</CX5FX5FOBJECT.NAME
> (see <RBW-XREF REFID="17541" TYPE="XREF-TEXTCOPY">Functions generated exclusively for persistent root classes</RBW-XREF
><B.BODY>An attribute does not result in a single private data member in the generated class. Instead, attribute values of a persistent object are stored in an ixRow object. The class ixRow is part of the NewEra Data Class Library (DCL).</B.BODY
><B.BODY>The data member in the generated class that refers to the object ixRow is called <className>Data:</B.BODY
><EM.EXAMPLE.MONO>...</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>INCLUDE SYSTEM "ixrow.4gh"</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> PUBLIC VARIABLE myClass<CX5FX5FFILE.NAME>Data</CX5FX5FFILE.NAME
> ixRow</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO></EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>END CLASS</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>This data member is instantiated at object construction time by copying an ixRow object named <persClass>RowSchema. This object is a SHARED data member in the generated class:</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO> LET myClassData = COPY myClassRowSchema</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>...</EM.EXAMPLE.MONO
><B.BODY>The object ixRow that is constructed already contains ixValue objects that will hold the actual attribute values. </B.BODY
><B.BODY>There is a one&truehy;to&truehy;one mapping between ixValue objects in the ixRow and the columns in the database table of the persistent class. Initially these ixValue objects are empty.</B.BODY
><B.BODY>For every object in the ixRow a corresponding constant named <className><columnName> will be generated in the header of the class. (The <className> prefix is required for making the constant unique.)</B.BODY
><B.BODY><type> must be a standard type. <ixtype> is the NewEra data class that can hold a value of type <type>. <ixtype> is a class that is derived from the NewEra class ixValue, e.g. ixString or ixInteger. For example:</B.BODY
><EWM.EXAMPLEW.MONO>CLASS myClass DERIVED FROM DBObject</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>...</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> FUNCTION getMyAtt1() RETURNING INTEGER</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> FUNCTION getMyAtt1Val() RETURNING ixInteger</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> FUNCTION getMyAtt2() RETURNING INTEGER</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> FUNCTION getMyAtt2Val() RETURNING ixInteger</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> FUNCTION setMyAtt2(newMyAtt2 INTEGER) RETURNING VOID</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO> FUNCTION setMyAtt2Val(newMyAtt2 ixInteger) RETURNING VOID</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>...</EWM.EXAMPLEW.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Key attributes</L.LABEL
><B.BODY>Key attributes are data attributes with a leading asterisk in the CD. Sub classes in a generalization are not allowed to have key attributes; they inherited the key attribute(s) from the super class. All other persistent classes must have at least one key attribute specified.</B.BODY
><B.BODY>During code generation, key attributes are added to the parameter list of the functions NEW<className>*. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>These functions are discussed in the section <RBW-XREF REFID="34523" TYPE="XREF-TEXTCOPY">Constructor</RBW-XREF
> and further.</B.BODY
><B.BODY>In the following example, there are no extra parameters (i.e. non&truehy;nullable attributes, mandatory associations, qualifiers) in the persistent class. As a result, key attributes are added to the parameter list in the function:</B.BODY
>The set functions that are generated for data attributes (see <RBW-XREF REFID="35019" TYPE="XREF-TEXTCOPY">Generated get and set functions</RBW-XREF
>) are not generated for key attributes.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Standard Types</L.LABEL
><B.BODY>In CDs, standard data types are used to define the data type of an attribute. These data types are mapped to target&truehy;dependent database types during persistent code generation. </B.BODY
><B.BODY>The standard data types can be found in the customization file:</B.BODY
>In persistent classes, you are not allowed to specify a class as the data type of an attribute.</W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Initial value</L.LABEL
><B.BODY>The initial value of an attribute is used to assign a value to the data member at the object construction time. The value is assigned in the body of the constructor.</B.BODY
> (=read) and <CX5FX5FPROCEDURE.NAME>set</CX5FX5FPROCEDURE.NAME
> (=write) member functions that are generated from the data attributes can be specified as <RBW-IDXTERM TERM1="public section" TERM2="accessibility"></RBW-IDXTERM
> result in the function having access control qualification PUBLIC, PROTECTED or PRIVATE. </B.BODY
><B.BODY><CX5FX5FFILE.NAME>None</CX5FX5FFILE.NAME
> indicates that the access function will not be generated.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="20897"></RBW-ANCHOR
>Nullable</L.LABEL
><B.BODY>Data attributes for which the property Nullable is set to <CX5FX5FOBJECT.NAME>no</CX5FX5FOBJECT.NAME
> are non&truehy;nullable attributes. During code generation, non&truehy;nullable attributes are added to the list of <CX5FX5FTERM><otherArguments></CX5FX5FTERM
><B.BODY>NewEra does not support function overloading. As a result, a class is allowed to have only one constructor. However, the constructor used by the runtime system (see <RBW-XREF REFID="17255" TYPE="XREF-TEXTCOPY">The Runtime System</RBW-XREF
> and further) only has the key attributes of the persistent class as parameters, whereas the constructor to be used by the user can have additional parameters dealing with:</B.BODY
><B.BODY>The generated NEW functions first instantiate the class by using the real constructor which is generated automatically by the NewEra code generator. Then, they initialize the instance by calling one of the following functions, which are also automatically generated:</B.BODY
><B.BODY>The consequence of the way the NewEra code generator handles the additional parameters, is that you are not allowed to specify an operation named <CX5FX5FOBJECT.NAME>$create</CX5FX5FOBJECT.NAME
> in the definition of a persistent class.</B.BODY
><B.BODY>The code generator issues an error message if it does encounter such an operation and it will stop generating code. </B.BODY
><B.BODY>Persistent classes in a generalization are treated similarly to non&truehy;persistent classes in a generalization. Persistent and non&truehy;persistent classes are instantiated differently, however. As a consequence, you cannot specify a persistent class as sub class of a non&truehy;persistent super class, or vice versa.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>For more information on non&truehy;persistent classes in a generalization, refer to: <RBW-XREF REFID="27879" TYPE="XREF-TEXTCOPY">Chapter 3, Mapping Modeling Data to NewEra Non&truehy;Persistent Code</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Differences with non&truehy;persistent code generation</L.LABEL
><B.BODY>A persistent root class must have key attributes. A persistent sub class is not allowed to have key attributes since it inherits the key attribute(s) from its super class.</B.BODY
>Differences with non&truehy;persistent code generation</L.LABEL
><B.BODY>For an association between two persistent classes in a CD member functions to manipulate the association are generated in one or both the classes. These functions have the same name as in the non&truehy;persistent code generation but the parameters and return type are slightly different. The return type is always INTEGER to indicate failure or success, except when a reference to one persistent object is returned.</B.BODY
><B.BODY>In non&truehy;persistent classes an association is maintained by setting an additional data member (i.e. an object reference or a set of object references) in one or both classes involved. </B.BODY
><B.BODY>In persistent classes an association is maintained by setting data in the database directly: the association is implemented via imported keys in database tables.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="41833"></RBW-ANCHOR
>Association properties</L.LABEL
><B.BODY>You can specify the same properties for associations between persistent classes as you can for associations between non&truehy;persistent classes.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>For more information on non&truehy;persistent association properties, refer to <RBW-XREF REFID="40839" TYPE="XREF-TEXTCOPY">Association Properties</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Association with <RBW-IDXTERM TERM1="link attribute" TERM2="in persistent (NewEra) code generation"></RBW-IDXTERM
>link objects</L.LABEL
><B.BODY>Associations between persistent classes that have a link attribute box or a linked class attached to them are generated similarly to associations between non&truehy;persistent classes.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>For more information on non&truehy;persistent associations with link objects, refer to <RBW-XREF REFID="17049" TYPE="XREF-TEXTCOPY">Association with Link Objects</RBW-XREF
><BI.BODY.INTRO>The following CD displays the relation between a Person and the Company he or she is working for. Both the classes Person and Company are persistent classes for which SQL and Persistent NewEra code is generated.</BI.BODY.INTRO
><B.BODY>In NewEra, the graphical user interface (GUI) of an application is represented in ASCII files with the extension wif. The NewEra Window Painter is normally used to create and manipulate these files interactively.</B.BODY
><B.BODY>ObjectTeam can be used to generate wif template files automatically. You can use these generated templates to further complete the graphical user interface of your application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section contains the following topics:</B.BODY
><B.BODY>You use the CD to model GUI classes. These classes are non&truehy;persistent classes in the OOPL model for which the property Referred Class is set. From these classes wif template files, in stead of source files (4gl) and header files (4gh), are generated by ObjectTeam.</B.BODY
><RBW-PARABODY>Enter the names of the data attributes for which you want a SuperField generated in the wif template file.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>These attributes must correspond to data attributes of the referred class. </LT.LIST.TEXT
><LT.LIST.TEXT>Make sure you include at least the key attributes and the non&truehy;nullable attributes of the referred class. The non&truehy;nullable attributes together with the key attribute(s) are required to instantiate a persistent class.</LT.LIST.TEXT
><LT.LIST.TEXT>Specify also the types of attributes in GUI classes. These are not used by the NewEra code generator, but are required for building up the OOPL model correctly.</LT.LIST.TEXT
><LT.LIST.TEXT>The active handler belonging to the button that is generated from a predefined operation is automatically generated during wif generation. The generated active handler of a user&truehy;defined button is empty.</LT.LIST.TEXT
><LT.LIST.TEXT>The following predefined operations are available:</LT.LIST.TEXT
><LT.LIST.TEXT>So if you specify, for example, an operation InsertRow(), a button InsertRow is generated in the wif template file, including the accompanying active handler code.</LT.LIST.TEXT
><B.BODY>If the class you refer to in your GUI class turns out to be a sub class in a generalization, the key attributes are handled differently by the WIF code generator. </B.BODY
><B.BODY>In a generalization, the sub class inherits key attributes from its super class. Therefore, these key attributes are generated into SuperFields in the wif template file. </B.BODY
><B.BODY>Make sure you also include non&truehy;nullable attributes of both the super class and the sub class in your GUI class, otherwise the WIF code generator will issue an error message.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What happens to the Properties in a <RBW-IDXTERM TERM1="GUI class" TERM2="properties"></RBW-IDXTERM
>GUI class</L.LABEL
><B.BODY>Except for the properties Referred Class and Persistent, the WIF code generator ignores all the properties you specify for a GUI class, or a data attribute or an operation in a GUI class. It takes however, the properties of the referred class into account.</B.BODY
><B.BODY>Do not set the property Persistent for a GUI class. If you still do so, the NewEra code generator considers the class as a persistent class and it will generate a 4gh and 4gl file in stead of a wif template file.</B.BODY
><B.BODY>If you forget to specify a value for the property Referred Class, the NewEra code generator considers the class as a normal class, for which it will generate a 4gh and 4gl file in stead of a wif template file. If the referred class turns out to be a non&truehy;persistent class, the code generator issues an error message.</B.BODY
><B.BODY>To model the graphical user interface for this application, you need to create GUI classes that refer to the persistent classes in this business model. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>GUI Model</L.LABEL
><B.BODY>The following CD contains examples of some GUI classes. The attributes of a GUI class refer to the attributes of the referred persistent class. Only the attributes that are included in the GUI class are generated for the window object. </B.BODY
><B.BODY>The operations in the GUI classes are generated into button objects.</B.BODY
><B.BODY>During code generation, the GUI classes are generated into wif template files. If you open such a file in the NewEra Window Painter (see <RBW-XREF REFID="35540" TYPE="XREF-TEXTCOPY">The NewEra Window Painter</RBW-XREF
>), it looks like one of the windows depicted below. This example shows the following generated wif template files: <CX5FX5FFILE.NAME>orders.wif</CX5FX5FFILE.NAME
>, <CX5FX5FFILE.NAME>lines.wif</CX5FX5FFILE.NAME
>, and <CX5FX5FFILE.NAME>mt_comp.wif</CX5FX5FFILE.NAME
><B.BODY>ObjectTeam can be used to generate wif template files automatically. This section discusses how to generate wif template files automatically in ObjectTeam and how to use the NewEra Window Painter in combination with ObjectTeam to further complete the graphical user interface of your application.</B.BODY
><B.BODY>It also lists the properties and event handlers that are generated for graphical objects in wif template files.</B.BODY
><RBW-PARABODY>a row of SuperTable Buttons</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>SuperField object</L.LABEL
><B.BODY>This object is an instance of the class ixSuperField or a class derived from this class. There is one SuperField object for every attribute that must be displayed in the Window, including inherited attributes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>SuperTable Button</L.LABEL
><B.BODY>This object is an instance of the class ixButton or a class derived from this class. There is one Button for every operation, e.g.: Query, and Retrieve.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</L.LABEL
><B.BODY>Every object in a wif template file has properties and event handlers assigned to it. Refer to <RBW-XREF REFID="23227" TYPE="XREF-TEXTCOPY">Properties of Generated WIF Objects</RBW-XREF
> and further for details on these properties. </B.BODY
><B.BODY>For more information on wif files and the wif language (wifl) in general refer to the INFORMIX&truehy;NewEra manual <CX5FX5FTITLE>Graphical and Connectivity Reference</CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In his section</L.LABEL
><B.BODY>This section contains the following section:</B.BODY
><B.BODY>The wif template files generated by ObjectTeam are just a staring point for developing the graphical user interface of your application. </B.BODY
><RBW-PARABODY>Save the file in the Window Painter.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The Window Painter does not only save the changes to the wif file, but it also generates a 4gl and a 4gh file from the wif file when you save it.</LR.LIST.RESULT
><LT.LIST.TEXT>These 4gl and 4gh files are used during the compilation and linking of the application, not the wif file. They are not visible in the ObjectTeam browser.</LT.LIST.TEXT
><B.BODY>For more information on the NewEra Window Painter refer to the INFORMIX&truehy;NewEra manual <CX5FX5FTITLE>Developing Graphical Applications</CX5FX5FTITLE
>Bear the following in mind if you have generated a wif template file for a GUI class before. When you remove an attribute or an operation from this GUI class in ObjectTeam, the corresponding SuperField or Button is not removed from the wif template file during regeneration. The code generator will, however, set the property <CX5FX5FOBJECT.NAME>SQLRole</CX5FX5FOBJECT.NAME
> of a removed SuperField to <CX5FX5FOBJECT.NAME>noRole</CX5FX5FOBJECT.NAME
>.</W.WARNING
><B.BODY>You have to remove the SuperField yourself using the NewEra Window Painter.</B.BODY
>Properties of Generated <RBW-IDXTERM TERM1="WIF object" TERM2="properties"></RBW-IDXTERM
>WIF Objects</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated properties</L.LABEL
><B.BODY>Each object in a wif template file has properties and event handlers assigned to it. Most generated properties get default values like they would have when drawn in the NewEra Window Painter.</B.BODY
><B.BODY>Some properties, however, get values that are determined by the data in the OOPL model. The tables on the following pages summarize these properties per object type.</B.BODY
><B.BODY>Properties with a trailing <CX5FX5FOBJECT.NAME>+</CX5FX5FOBJECT.NAME
> are set every time the object is (re)generated; properties without the <CX5FX5FOBJECT.NAME>+</CX5FX5FOBJECT.NAME
> are set only the first time the object is generated in the wif template file. </B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>total number (plus one) of attributes of the persistent class and its (recursive) superclasss that must be displayed. The extra attribute is the invisible field class_type </CELLBODY
><B.BODY>Each object in a wif template file has properties and event handlers assigned to it. The following table summarizes the event handlers that are generated for the various WIF objects:</B.BODY
><RBW-TEXTFLD TYPE="text">Code Generation Guide for NewEra</RBW-TEXTFLD
></RBW-SYSOBJ
></C.CHAPTER.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>One of the benefits of an object&truehy;oriented design methodology is its support for the reuse of software components. <CX5FX5FEMPHASIS>Reverse engineering</CX5FX5FEMPHASIS
> facilitates this by allowing you to use existing NewEra code in your project. This code may come from other projects or from third&truehy;parties, such as class library vendors or public domain software sites.</B.BODY
>Reverse engineering parses NewEra header files and builds CDs and CDMs that show the class hierarchy defined in the header files. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose </L.LABEL
><B.BODY>Use reverse engineering to capture and display the class hierarchy of a class library so that you can reuse the classes in the library. Reverse engineering</B.BODY
><RBW-PARABODY>Helps you to understand the structure and functionality of class libraries.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Not an import utility</SL.SUBLABEL
><B.BODY>Reverse engineering is not designed to capture all the information in a header file. Therefore, do not use reverse engineering to import classes in order to maintain them in ObjectTeam. If you generate header files from the CDs and CDMs created by reverse engineering, they will not match the header files you used to create those CDs and CDMs.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class hierarchy</L.LABEL
><BI.BODY.INTRO>A class hierarchy shows a base class and the subclasses derived from that base class. A class at or near the top of the hierarchy is more generalized. Classes at or near the bottom of the hierarchy are more specialized. The following illustration shows a class hierarchy for a graphical user interface subsystem.</BI.BODY.INTRO
>class library is a collection of classes intended for use in many different situations. Generally, classes near the top of a class hierarchy are better candidates for a class library because they are more likely to be reused. Classes lower in the hierarchy have more restricted use and might not be useful in a class library.</B.BODY
><B.BODY>In the previous illustration, myFrame is not useful in a class library because it is an instance. The other classes might appear in a class library.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><RBW-PARABODY>Nested type definitions are recognized, but processed as if they are not nested. This can result in duplicate definitions.</RBW-PARABODY
><RBW-PARABODY>References to nested type definitions are transformed into references to type definitions that are not nested. For example, <CX5FX5FINPUT>nested::type</CX5FX5FINPUT
><RBW-PARABODY>Definitions of templates are ignored; references to instances of the template are mapped to a reasonable name. For example, <CX5FX5FINPUT>List<Thing*></CX5FX5FINPUT
><RBW-PARABODY>It allows data types to be referenced before they are defined.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Preprocessing directives</SL.SUBLABEL
><B.BODY>The parser ignores all preprocessor symbols, such as #ifdef and #define. However, you can specify a preprocessor to be run before reverse engineering, as described in <RBW-XREF REFID="38598" TYPE="XREF-TEXTCOPY">Running Reverse Engineering</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Mapping the elements<RBW-IDXTERM TERM1="NewEra" TERM2="reverse engineering"></RBW-IDXTERM
><BI.BODY.INTRO>After mapping the NewEra constructs to ObjectTeam elements, reverse engineering creates draft CDs, as shown below, to hold the elements.</BI.BODY.INTRO
><RBW-PARABODY>If classes are too large, reverse engineering folds them, as shown in the following illustration. Alternatively, if you specify the Create Reference Diagrams option in the Reverse Engineer NewEra dialog box, reverse engineering creates a separate reference diagram for the class.</RBW-PARABODY
><LR.LIST.RESULT>As shown in the following illustration, the generated CDs display the class hierarchy defined in the selected files. The display includes attributes and operations; associations between classes are not reverse engineered.</LR.LIST.RESULT
><B.BODY>During reverse engineering, ObjectTeam prompts you to select the files that you want to reverse engineer. In most cases, you select NewEra header files. </B.BODY
><BI.BODY.INTRO>The following illustration shows the Windows dialog box and the UNIX dialog box. In Windows, use the File Name and File of Type fields to filter the list of files displayed. In UNIX, use the Filter field and Filter button.</BI.BODY.INTRO
><BI.BODY.INTRO>During reverse engineering, ObjectTeam displays the following dialog box prompting you to select the options that you want to use:</BI.BODY.INTRO
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Name of the diagram to be generated. Multiple header files can be generated to a single diagram.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>NewEra is case insensitive and ObjectTeam is case sensitive. Use this field to specify which case should be used in ObjectTeam.</CELLBODY
><RBW-PARABODY>FirstCase. For each identifier, use the case that is first encountered. (When reverse engineering multiple files, use this option with caution.)</RBW-PARABODY
><B.BODY>This file also contains minimum and maximum values for the standard types. </B.BODY
><B.BODY>Whenever you generate code or check a diagram’s contents, the data types used in the diagram are always checked against the data types in the standard types file. The standard types are then mapped to the appropriate language (i.e. NewEra) types.</B.BODY
><B.BODY>Here is a sample of the <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
> can be used to specify constraints on array size or format values of the standard types.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Checking types</L.LABEL
><B.BODY>Whenever you generate code or check a diagram’s contents, the data types used in the diagram are checked against the data types in the standard types file. This checking is always carried out, even when you don’t generate persistent code.</B.BODY
><B.BODY>During code generation, the standard types are mapped to:</B.BODY
><B.BODY>You can create a customization file <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
> if you want to extend or change the default <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
> file. You can do that by selecting File | New on the Browser level of your choice with the pseudo object <customization files> as current object. The name of the new customization file must be <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
>. After you have created the file, you can edit it and save it.</B.BODY
><B.BODY>The next time you generate code, your user&truehy;defined customization file is evaluated by the code generator. The nearest customization file overrules all other customization files that might be defined on higher levels. So if you have, for instance, a user&truehy;defined customization file <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
> defined on Configuration level, Project level and System level, the one on System level overrules all the other ones.</B.BODY
><B.BODY>NewEra types are data types that are supported by the Relational Database System (RDBMS) used. The standard types are mapped to NewEra types during persistent code generation.</B.BODY
><B.BODY>The mapping is taken care of by the configuration file:</B.BODY
><B.BODY>The first column in this file lists the standard types. These must be consistent with the types in the <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
> file. The second column lists the NewEra types the standard types must be mapped upon. In the column <CX5FX5FOBJECT.NAME>range</CX5FX5FOBJECT.NAME
> the type of brackets used in the target language is indicated.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customization file</L.LABEL
><B.BODY>You can create customization files for the files <CX5FX5FFILE.NAME>lang_types.lang_types</CX5FX5FFILE.NAME
>. The way to do that is analogous to creating a customization file for the <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
><B.BODY>The first column in this file lists the standard types. These must be consistent with the types in the <CX5FX5FFILE.NAME>stand_types.stand_types</CX5FX5FFILE.NAME
> file. The second column lists the SQL types the standard types must be mapped upon. In the column has <CX5FX5FINPUT>range</CX5FX5FINPUT
> the type of brackets used in the target language is indicated.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customization file</L.LABEL
><B.BODY>You can create customization files for the files <CX5FX5FFILE.NAME>db_types</CX5FX5FFILE.NAME
>. The way to do that is analogous to creating a customization file for the <CX5FX5FFILE.NAME>stand_types</CX5FX5FFILE.NAME
><B.BODY>The classes in the class library <CX5FX5FOBJECT.NAME>lw4omtne</CX5FX5FOBJECT.NAME
> are used to provide NewEra storage structures for classes participating in associations and qualified associations. These type of classes are more commonly referred to as container classes or collector classes, since they can contain many occurrences of any type of class. They also provide maintenance and search methods. </B.BODY
><B.BODY>The code generator maintains (qualified) associations specified in CDs by generating class member functions. See <RBW-XREF REFID="34119" TYPE="XREF-TEXTCOPY">Associations</RBW-XREF
> for the mapping of associations in diagrams and the implementation in (non&truehy;persistent) NewEra code.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Which classes does the class library include</L.LABEL
><B.BODY>The next table summarizes the classes available in lw4omtne and a short description. </B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY> The root class of every persistent class</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What are these classes based on</L.LABEL
><B.BODY>The current implementation of the set and dictionary classes are based on the NewEra class ixVector, which is part of the Data Class Library (DCL) that comes standard with the NewEra product. When these data structures are used heavily, they should be replaced with more efficient implementations to improve performance.</B.BODY
><B.BODY>The class DBObject is the root class of every persistent class for which code is generated. DBObject offers general functions for database interaction (connections, transactions), but also functionality that is needed by every persistent class. (See <RBW-XREF REFID="14975" TYPE="XREF-TEXTCOPY">The Class DBObject</RBW-XREF
> for more information.)</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>The file main.4gl</L.LABEL
><B.BODY>With the library comes a file called <CX5FX5FFILE.NAME>main.4gl</CX5FX5FFILE.NAME
> which contains an example of the <CX5FX5FOBJECT.NAME>MAIN</CX5FX5FOBJECT.NAME
> function every program needs. Note that this file must not be included in the library itself! </B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>directories that are searched for external sources; directories are separated by a semicolon; the external sources are set through the External Class Source property</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>generates the set initializer for the constructor (RefDict)</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY> orsdict::get_and_return <CX5FX5FTERM>sect name key return_type</CX5FX5FTERM
></CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>gets an element from the dictionary selected by <CX5FX5FTERM>key</CX5FX5FTERM
> and returns its value (ORSetDict)</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>orsdict::iter <CX5FX5FTERM>decl_sect impl_sect name type qual_type action</CX5FX5FTERM
></CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>generates an iterator of <CX5FX5FTERM>type</CX5FX5FTERM
> and <CX5FX5FTERM>name</CX5FX5FTERM
> in <CX5FX5FTERM>section</CX5FX5FTERM
>; <CX5FX5FTERM>action</CX5FX5FTERM
> contains the iterated code (ORSetDict)</CELLBODY
><RBW-PARABODY>Create a customization file <CX5FX5FFILE.NAME>objtype.objtype</CX5FX5FFILE.NAME
>.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>You do this by opening up the pseudo object <customization files> on an appropriate browser level, select File | New and select <CX5FX5FFILE.NAME>objtype.objtype</CX5FX5FFILE.NAME
><RBW-PARABODY>To change the extension for header files, for example, select the row containing the Repository Type <CX5FX5FOBJECT.NAME>External File Version</CX5FX5FOBJECT.NAME
> and the Browser Type <CX5FX5FOBJECT.NAME>4gh.</CX5FX5FOBJECT.NAME
><RBW-PARABODY>To make sure the new customization file is read by ObjectTeam, go to Corporate Level in the browser and go back to Implementation System level.</RBW-PARABODY
><RBW-PARABODY>The text editor that is now started up should show the file name with the new extension.</RBW-PARABODY
></LN.LIST.NUM
><B.BODY>Newly generated files will have the new extension in your user environment. However, the column Type in the information area of the browser on Implementation System level still reads 4gh.</B.BODY
>Delete files that were generated before you created the customization file. When you generate them again, they will have the new file extension.</T.TIP
><B.BODY>You can customize the generation of wif template files (see <RBW-XREF REFID="16738" TYPE="XREF-TEXTCOPY">Chapter 5, Modeling the User Interface</RBW-XREF
>) by changing the Tcl variables in the following Tcl file:</B.BODY
><RBW-PARABODY>Tcl variables that control the generation of geometric properties of graphical objects in the wif template file</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>Both types of variables are discussed in this section.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to create a customization file wif_const.tcl</L.LABEL
><B.BODY>If you want to make any changes to the Tcl variables mentioned here, you have to create a customization file <CX5FX5FFILE.NAME>wif_const.tcl</CX5FX5FFILE.NAME
>. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>Refer to <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for details on how to create customization files.</B.BODY
></LABEL
><SUBSECTION><SS.SUBSEC.HEAD>Customizing the Generation of Graphical Objects</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>The next pages summarize the Tcl variables that control the generation of the different graphical objects in a wif template file. These variables are set in the Tcl file <CX5FX5FFILE.NAME>wif_const.tcl</CX5FX5FFILE.NAME
>.</B.BODY
><B.BODY>The following graphical objects are covered:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>which ixWindow properties get calculated values (updated at each (re)generation; assigned with =)</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>which ixSuperTable properties get calculated values (updated at each (re)generation; assigned with =)</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>which ixSuperField properties get calculated values (updated at each (re)generation; assigned with =)</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>which ixButton properties get calculated values (updated at each (re)generation; assigned with =)</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>contains the bodies for the active event handlers indexed on the name of the ixButton</CELLBODY
>Which geometric properties are generated</L.LABEL
><B.BODY>The picture below shows the lay&truehy;out of the initially generated WIF&truehy;file. Generated values of geometric properties can be influenced by the global Tcl variables as indicated in the figure below:</B.BODY
><B.BODY>ObjectTeam offers the possibility to incorporate rules for referential integrity checking in the database. The default Referential Integrity rules are specified in the customization file:</B.BODY
><B.BODY>In the <CX5FX5FFILE.NAME>sqlrules.sqlrules</CX5FX5FFILE.NAME
> file, a rule is specified for every type of association, aggregation and generalization. The rules, specified in the last column of the file, refer to Tcl procedures. During persistent code generation, the Tcl procedure specified for the specific type of relation is called. The SQL code that is generated by this procedure is inserted in the SQL script <CX5FX5FFILE.NAME>create_procs</CX5FX5FFILE.NAME
>. </B.BODY
><B.BODY>See the <CX5FX5FTITLE>ObjectTeam Repository Interface Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for an overview of the mapping of the different types of relations to the SQL model.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What do the columns mean</L.LABEL
><B.BODY>In the SQL rules file, a rule is specified for every combination of:</B.BODY
><RBW-PARABODY><CX5FX5FTERM>Cascade<RBW-IDXTERM TERM1="cascade" TERM2="policy for referential integrity"></RBW-IDXTERM
></CX5FX5FTERM
>: referential integrity is maintained by propagating the database operation across the association. The most obvious use is for <CX5FX5FTERM>delete</CX5FX5FTERM
><RBW-PARABODY><CX5FX5FTERM>Nullify<RBW-IDXTERM TERM1="nullify" TERM2="policy for referential integrity"></RBW-IDXTERM
></CX5FX5FTERM
>: when an object is removed, the foreign key value is changed to NULL, indicating that no link exists. This policy cannot be selected for <CX5FX5FTERM>insert</CX5FX5FTERM
>: whether or not referential integrity is checked for this type of relation is determined by what is indicated at the top of the SQL rules file: <CX5FX5FTERM>on</CX5FX5FTERM
>: this rule is only valid for the database operations <CX5FX5FTERM>insert</CX5FX5FTERM
> and <CX5FX5FTERM>update</CX5FX5FTERM
> and for the policy <CX5FX5FTERM>Restrict</CX5FX5FTERM
>. The database operation is cancelled if a tuple exports or imports keys and the tuple to which it export keys or from which it imports keys doesn’t exist</RBW-PARABODY
>: this rule is only valid for the database operations <CX5FX5FTERM>insert</CX5FX5FTERM
> and <CX5FX5FTERM>update</CX5FX5FTERM
> and for the policy <CX5FX5FTERM>Cascade</CX5FX5FTERM
>. If a tuple is inserted in the detail table and the corresponding keys do not exist in the master table, they are inserted in the master table.</RBW-PARABODY
><B.BODY>If you want to change anything regarding Referential Integrity policies that must affect all relations of a particular type, you should create a customization file with the name <CX5FX5FFILE.NAME>sqlrules.sqlrules</CX5FX5FFILE.NAME
> on the browser level of your choice.</B.BODY
><B.BODY>Refer to <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for details on how to create customization files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing RI locally</L.LABEL
><B.BODY>The default policy for a particular type of relation is specified in the SQL rules file. For every type of relation a certain rule is defined. However, for individual associations, aggregations or generalizations, you can overrule the following settings from the sqlrules file:</B.BODY
><RBW-PARABODY>Whether or not referential integrity must be checked </RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>You can do that in the CD by editing the properties of the association, aggregation or generalization you want to overrule the default settings for:</B.BODY
><RBW-TEXTFLD TYPE="text">Code Generation Guide for NewEra</RBW-TEXTFLD
></RBW-SYSOBJ
></A.APPENDIX.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>NewEra code generation properties</L.LABEL
><B.BODY>The following table lists the properties that effect NewEra code generation. These are available in the CD in the Object Design phase.</B.BODY
> contains information specific to the PowerBuilder<CX5FX5FSUPERSCRIPT>® </CX5FX5FSUPERSCRIPT
>programming language. This includes information for setting up, configuring, and specifying code generation details in CDs that you will use to generate PowerBuilder code. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisites</L.LABEL
><B.BODY>This guide is intended for experienced users of ObjectTeam and the analysis and design method it supports. This guide gives you information on how to map ObjectTeam diagrams to PowerBuilder code; it does not teach you how to use PowerBuilder.</B.BODY
><B.BODY>To customize or extend the capabilities of the PowerBuilder code generator, you must have a thorough understanding of the ObjectTeam Shell, the Object&truehy;Oriented Programming Language (OOPL) model structure, and the Tool Command Language (Tcl) commands.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>PowerBuilder version</L.LABEL
><B.BODY>The PowerBuilder code generator is designed for use with PowerBuilder 5.0, Professional or Enterprise edition. To avoid potential problems, ensure that the following PowerBuilder files are in your path before using the PowerBuilder code generator:</B.BODY
> provides the menu items, the properties and the Tcl code required to use the PowerBuilder Code Generator. Therefore, before moving to the Object Design phase, make sure this module is active.</B.BODY
><B.BODY>You can check if a module is active on a particular Browser level by selecting Utilities | Show Active Modules on that level.</B.BODY
> for details on how to activate a module.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Object Design and Implementation</L.LABEL
><B.BODY>This chapter describes the tasks of the Object Design phase. <RBW-XREF REFID="40013" TYPE="XREF-TEXTCOPY">Chapter 2, Generating Code</RBW-XREF
>, describes the tasks of the Implementation phase. You work iteratively in these two phases to generate code and complete your application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose of object design</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="Object Design" TERM2="activities in this phase"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Object Design" TERM2="development phase in ObjectTeam project"></RBW-IDXTERM
>In ObjectTeam, the CDs (and the objects defined in the CDs) provide all the source data needed for code generation. The goal of object design is to add to the CDs all the data required for successful code generation. For example, you add properties (such as the Attribute Access property, which establishes read/write access to an attribute) and incorporate language&truehy;specific syntax (such as data type specifications for attributes and the arguments of operations).</B.BODY
><B.BODY>You might also add data to diagrams other than CDs. The code generator does not use oter diagrams, but they are useful for describing the behavior of classes, their attributes and operations.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="11800" TYPE="XREF-TEXTCOPY">Refining the Class Diagrams&rbwtab;1–3</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="11719" TYPE="XREF-TEXTCOPY">Hints and Tips for Effective Code Generation&rbwtab;1–6</RBW-XREF
>Introduction<RBW-IDXTERM TERM1="Class Association Diagram"></RBW-IDXTERM
></L.LABEL
><B.BODY>The CDs and the objects defined in the CDs provide all the source data needed for code generation. <RBW-IDXTERM TERM1="Class Association Model"></RBW-IDXTERM
>These diagrams distinguish the classes in a system and describe their identities and their features. In the Object Design phase, you must add to the CDs sufficient detail for successful code generation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using data from diagrams other than CDs</L.LABEL
><B.BODY>Diagrams other than the CDs are not used as input for code generation. However, they contain valuable information that can help you to complete and verify the CDs. The following table summarizes how you can use these other diagrams to help you find important objects that are not yet in the CDs.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>STD state names (enumerated list as an attribute value)</CELLBODY
><CELLBODY>STD condition on an event</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Upper&truehy; and lower&truehy;case characters</L.LABEL
><B.BODY>ObjectTeam is case&truehy;sensitive, but in many cases PowerBuilder allows only lower&truehy;case characters. To prevent potential problems, Cayenne strongly recommends that you use only lower&truehy;case characters to name items in systems that are used with the PowerBuilder code generator.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Classes</L.LABEL
><B.BODY>When you work on CDs, you focus on the implementation of classes. The CD must include all classes and the associations (and inheritance) between classes. In the Object Design phase, you may introduce new classes to ease implementation and improve performance.</B.BODY
><B.BODY>You must include all attributes and operations for each class. The attributes of a class map to the attributes of the class type. The operations of the class map to functions of the class type. In PowerBuilder, each ObjectTeam class must have a valid supertype. For more information, see <RBW-XREF REFID="15448" TYPE="XREF-TEXTCOPY">Mapping Classes</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>External classes</L.LABEL
><B.BODY>A class must have at least one attribute or one operation to generate code. Classes that have no attributes or operations are translated as external classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Associations</L.LABEL
><B.BODY>You must define the associations between all classes, including any constraints.</B.BODY
><B.BODY>Role names must also be defined. Every association needs at least one role name. Every mandatory association must have a role name. Without a role name, you cannot use the association.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role names in Analysis and System Design</SL.SUBLABEL
><B.BODY>In the Analysis and System Design phases, role names distinguish a class by showing the role the class is playing in a relationship with another class. Each role name defines the role of the class within the context of a single association. It also indicates the use and direction of the association toward the class that plays a role. For example, a manager can be both the boss of a coworker and an employee of a company.</B.BODY
>Role names in Object Design and Implementation</SL.SUBLABEL
><BI.BODY.INTRO>In the Object Design and Implementation phases, the use of role names is extended. The code generator creates access methods for an association if the class at the far end has a role name for the association. In the previous example, the code generated for Coworker includes access methods for Manager; the code generated for Manager does not include access methods for Coworker.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attributes</L.LABEL
><B.BODY>You must specify each attribute completely, including its data type. The way to specify a data type for an attribute is to include the type in the class symbol, for example:</B.BODY
><B.BODY>Data types of attributes and arguments can be standard ObjectTeam types, standard types for your target language, or class types and derived types. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Operations</L.LABEL
><BI.BODY.INTRO>You must specify each operation completely. This includes specifying such aspects as:</BI.BODY.INTRO
><RBW-PARABODY>Any parameters, as well as their data types</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Properties</L.LABEL
><BI.BODY.INTRO><RBW-IDXTERM TERM1="property" TERM2="using - to specify implementation details"></RBW-IDXTERM
>In the Object Design phase, a variety of properties allow you to specify many implementation details. <RBW-IDXTERM TERM1="property" TERM2="using - to specify implementation details"></RBW-IDXTERM
>These details are incorporated in the final code.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Checking</L.LABEL
><B.BODY>The last activity in object design is to use Check | Global Model to check the CDs. The CDs must be error&truehy;free before they can be used for code generation. See the <CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for more information about the Check utility.</B.BODY
>, and <RBW-XREF REFID="41939" TYPE="XREF-TEXTCOPY">Chapter 4, Modeling the Visual Interface</RBW-XREF
>, describe how the ObjectTeam model is translated into code. You can use this information to help you complete the CDs in the Object Design phase.</B.BODY
>Hints and Tips for Effective Code Generation</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Following are a few tips for effective code generation. It may be helpful to be aware of these items as you prepare for code generation, and then again as you generate and regenerate your source files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Understanding the translations</L.LABEL
><B.BODY>Before generating code, read through this guide. It contains detailed information about the data that you must include in your CDs for successful code generation. It also explains how the code generator translates the ObjectTeam model into source code files, what changes you can make to the source code files, and how to regenerate them without losing your changes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Naming conventions</L.LABEL
><B.BODY>Agree upon and follow a naming convention for projects, configurations, systems, classes, special characters, and so on. In addition, bear in mind that spaces between words (in class names, for instance) are deleted by ObjectTeam code generators.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing code generation</L.LABEL
><B.BODY>The code generators execute Tcl scripts that translate a model into source code. You can modify these scripts or create your own.. Always use caution when customizing or creating scripts; such scripts are not supported.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using multiple languages in a single application</L.LABEL
><B.BODY>Each ObjectTeam code generator is designed to generate code for one language. You can create an application that uses multiple languages by using different code generators to generate code for different systems; however, the generated code is not integrated across systems. </B.BODY
><B.BODY>The ObjectTeam code generators are not designed to provide language integration. To build an application that uses multiple languages, you must do the following: </B.BODY
>When you create a separate ObjectTeam system for each language&truehy;specific subsystem, be sure to define your classes in the appropriate system. When ObjectTeam generates code for the current system, it generates code for the classes that are defined in that system. It does not generate code for classes referenced, but not defined in, the current system; such classes are treated as external classes.</N.NOTE
>Typically, the ultimate goal of modeling an application is to produce code that implements the application. In ObjectTeam, you can generate a significant portion of the code automatically, then complete the code by adding the details that not specified in the model.</B.BODY
><RBW-PARABODY>Only the CDs (and the objects defined in the CDs) are used for code generation. Therefore, before code generation, it is critical that the CDs be fully defined, as described in <RBW-XREF REFID="13837" TYPE="XREF-TEXTCOPY">Chapter 1, Preparing Your ObjectTeam Model for Code Generation</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated files</L.LABEL
><B.BODY>The PowerBuilder source files generated by ObjectTeam are ASCII files that can be imported into a PowerBuilder (<CX5FX5FFILE.NAME>.pbl</CX5FX5FFILE.NAME
>) library.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Steps for generating code</L.LABEL
><B.BODY>The following table provides an overview of the code generation process. This chapter describes each step in greater detail.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Configure the PowerBuilder environment, copying required source files from the ObjectTeam installation directories to the appropriate user environment directories.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Import your systems into the Implementation phase. During this step, ObjectTeam runs the Tcl scripts that generate the PowerBuilder source files.</CELLBODY
> System level in the Implementation phase is fundamentally different than System level in other phases. The System files in the Implementation phase are source files, not diagram files.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>ObjectTeam generates a portion of your application, but not the entire application. To complete the generated source files, edit them in PowerBuilder, as described in the following table.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Steps for editing and regenerating code</L.LABEL
><B.BODY>The following table provides an overview of the process for editing and regenerating code. This chapter describes each step in greater detail.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>In PowerBuilder, create a PowerBuilder application. Add the library you just created to the library search path of the application. The generated PowerBuilder objects are now available in your PowerBuilder application.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>In PowerBuilder, complete the generated code. For example, ObjectTeam generates events for an object, but you must complete the event scripts in PowerBuilder.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>In ObjectTeam, modify the model and regenerate the PowerBuilder source files.</CELLBODY
><CELLBODY>The edits you made in PowerBuilder are not lost when you regenerate the source files (by reimporting systems into the Implementation phase). The code generator recognizes your changes and transfers them to the newly generated files.<RBWAUTO-0004><RBW-IDXTERM TERM1="code regeneration"></RBW-IDXTERM
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Import the generated source files into your PowerBuilder (<CX5FX5FFILE.NAME>.pbl</CX5FX5FFILE.NAME
>) library and return to step 3.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Importing and exporting source files</L.LABEL
><B.BODY>ObjectTeam supports incremental development. You can edit the ObjectTeam model or the generated PowerBuilder code. The PowerBuilder code generator preserves your changes as long as you remember the following:</B.BODY
><RBW-PARABODY>After editing the model in ObjectTeam, generate the PowerBuilder source file and import it into your PowerBuilder (<CX5FX5FFILE.NAME>.pbl</CX5FX5FFILE.NAME
>) library. Your changes are now available in PowerBuilder.</RBW-PARABODY
><RBW-PARABODY>After editing in PowerBuilder, export the code overwriting the originally generated source files. The PowerBuilder source file now contains your changes, which will be preserved when ObjectTeam regenerates the source file.</RBW-PARABODY
></LB.LIST.BULLET
><BI.BODY.INTRO>The following figure illustrates this process:</BI.BODY.INTRO
><B.BODY>It is critical to import generated source files into your PowerBuilder (<CX5FX5FFILE.NAME>.pbl</CX5FX5FFILE.NAME
>) library and to export edited files out of the PowerBuilder library. <RBW-XREF REFID="31389" TYPE="XREF-TEXTCOPY">Workflow Using the Keep Synchronized Property</RBW-XREF
> describes how you can automate the process by using the System&truehy;level property Keep Synchronized With PowerBuilder Libraries.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Illustration of code generation</L.LABEL
><BI.BODY.INTRO>The following illustration shows how ObjectTeam generates code, including the names of the Tcl scripts that it uses.</BI.BODY.INTRO
> activates, among other things, the Tcl script <CX5FX5FFILE.NAME><RBW-IDXTERM TERM1="gencpp.tcl"></RBW-IDXTERM
>pbimporter.tcl</CX5FX5FFILE.NAME
>, which contains Tcl procedures to retrieve information from internal models, format it and write it to PowerBuilder files. <CX5FX5FFILE.NAME>pbimporter.tcl</CX5FX5FFILE.NAME
> uses other Tcl scripts that use other Tcl scripts as well, and so on.</B.BODY
><B.BODY>The default <RBW-IDXTERM TERM1="Tcl" TERM2="script files used for code generation"></RBW-IDXTERM
>Tcl scripts used to generate PowerBuilder files can be found under the <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
><B.BODY>When you generate code, ObjectTeam converts the CDs and CDMs of the Object Design phase into an intermediate model: the OOPL model. The PowerBuilder code generator then generates the PowerBuilder source files based on the OOPL model.</B.BODY
> provides a detailed description of the classes in the OOPL model.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-IDXTERM TERM1="VisualWorks"></RBW-IDXTERM
>PowerBuilder files</L.LABEL
><B.BODY>You use ObjectTeam to model visual and nonvisual objects, as well as the associations among them. From the ObjectTeam model, you generate PowerBuilder source files that can be imported into a PowerBuilder (<CX5FX5FFILE.NAME>.pbl</CX5FX5FFILE.NAME
> and <RBW-XREF REFID="38296" TYPE="XREF-TEXTCOPY">Editing Generated Source Files</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>PowerBuilder</L.LABEL
><B.BODY>PowerBuilder is an application development environment. All PowerBuilder objects are stored in PowerBuilder (<CX5FX5FFILE.NAME>.pbl</CX5FX5FFILE.NAME
>) libraries. Every PowerBuilder application has a library search path that defines the set of PowerBuilder libraries that are used by the application. In PowerBuilder, you can edit any object defined in any library that is included in the library search path of the current application.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY>See the PowerBuilder documentation.</B.BODY
><B.BODY>In ObjectTeam, you configure your PowerBuilder environment in the Object Design phase <CX5FX5FEMPHASIS>and</CX5FX5FEMPHASIS
> the Implementation phase.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What happens in the Object Design phase</L.LABEL
><B.BODY>When you configure your PowerBuilder environment in the Object Design phase, ObjectTeam adds a new system to this phase of your project: the PBBuiltins system. This system contains the classes that represent the PowerBuilder object types, such as window, check box, custom visual object, and custom class object.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose</SL.SUBLABEL
><B.BODY>In ObjectTeam, you model a PowerBuilder application by creating an ObjectTeam class for each PowerBuilder object that you want to create. The supertype class of the ObjectTeam class indicates the type of PowerBuilder object that you want to create. In other words, when you model a PowerBuilder application, each ObjectTeam class that you create must be derived from one of the classes defined in the PBBuiltins system.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What happens in the Implementation phase</L.LABEL
><B.BODY>When you configure your PowerBuilder environment in the Implementation phase, ObjectTeam copies the following files to the <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
>\<CX5FX5FFILE.NAME>src</CX5FX5FFILE.NAME
> directory, where <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
> is the file path for your generated files. (For more information about the user environment, see the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
> PowerBuilder source files that define custom class objects used by the code that ObjectTeam generates for associations. For more information about how these classes are used, see <RBW-XREF REFID="14358" TYPE="XREF-TEXTCOPY">Mapping Associations</RBW-XREF
> in the library search path of any PowerBuilder application that uses PowerBuilder files generated by ObjectTeam. If the <CX5FX5FFILE.NAME>classlib.pbl</CX5FX5FFILE.NAME
> is not in the library search path, the generated code cannot access the classes that it requires.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to configure the environment in Object Design</L.LABEL
>For an overview of the classes defined in this system, open the system in ObjectTeam and examine the CD named SystemObjectsHierarchy. For more detailed information, use Utilities | Reports | On Classes to generate a report of the classes in the system.</T.TIP
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="36159"></RBW-ANCHOR
>How to configure the environment in Implementation</L.LABEL
>You can also configure the PowerBuilder environment from System level in the Implementation phase. However, to avoid potential errors, it is best to configure your environment from the Implementation Phase level before importing any systems.</N.NOTE
><B.BODY>When you generate source files, the code generator uses the CDs and CDMs that are in the Object Design phase to create PowerBuilder source files in the Implementation phase. At System level of the Implementation phase, you can then refine the source code and complete the application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Implementation Phase is different</L.LABEL
><B.BODY>The System level of the Implementation phase is fundamentally different from System level of any other phase. In the Implementation phase, the System files are PowerBuilder files. In other phases, the System files are ObjectTeam diagrams.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generate code on Phase or System level</L.LABEL
><B.BODY>You can generate code on the Implementation Phase level or on the System level of the Implementation phase.</B.BODY
><RBW-PARABODY>On the <CX5FX5FBULLET.EMPHASIS>Implementation Phase level</CX5FX5FBULLET.EMPHASIS
>, you can generate code for one or more systems. This creates a matching system in the Implementation Phase that contains the generated source files. To regenerate code for an existing system, use System level.</RBW-PARABODY
><RBW-PARABODY>On the <CX5FX5FBULLET.EMPHASIS>System level of the Implementation phase</CX5FX5FBULLET.EMPHASIS
>, you can (re)generate code for the entire system, or regenerate selected source files.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>Typically, you use Implementation Phase level to generate code for a system initially and System level to regenerate code subsequently.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to generate code on Implementation Phase level</L.LABEL
> to generate code for one or more systems in the Object Design phase. You can select only systems that do not yet exist in the Implementation phase.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>ObjectTeam opens a Monitor window for displaying log messages, then generates the source files.</LR.LIST.RESULT
> to (re)generate code for all classes that are defined in this system.</RBW-PARABODY
></LB2.LIST.BULLET.2
><LR.LIST.RESULT>ObjectTeam opens a Monitor window for displaying log messages, then generates the source files. The following illustration shows the Monitor window after generating code for a system.</LR.LIST.RESULT
><B.BODY>The PowerBuilder files are stored in the repository as external files. They are also written to the <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
> directory, where <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
> is the file path for your generated files. For more information on the user environment, see the <CX5FX5FTITLE>ObjectTeam Project Management Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>. </B.BODY
><B.BODY>The following illustration shows how the source files appear in the Browser.</B.BODY
><RBW-IDXTERM TERM1="Update User Environment (Utilities menu)"></RBW-IDXTERM
>Update user environment</SL.SUBLABEL
><B.BODY>Utilities | Update User Environment updates your user environment based on the repository. This can be particularly useful if you are working on two machines, and the user environment of each is set to a local drive. When you move between machines, you can use Utilities | Update User Environment to update the local drive of the current machine.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated files</L.LABEL
><B.BODY>The PowerBuilder code generator generates the following files:<RBW-IDXTERM TERM1="C++ header file" TERM2="generating"></RBW-IDXTERM
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>One for each ObjectTeam class that represents a PowerBuilder user object (custom visual object, standard visual object, custom class object, or standard class object).</CELLBODY
>ObjectTeam does not generate a PowerBuilder source file for every ObjectTeam class. Only for those classes that represent appropriate PowerBuilder objects and only if the Global Property of class is set to Yes. See <RBW-XREF REFID="15448" TYPE="XREF-TEXTCOPY">Mapping Classes</RBW-XREF
> for more information.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>When code is not generated</L.LABEL
><B.BODY>The PowerBuilder code generator generates code for all classes defined in the current system. It does not generate code in the following situations:</B.BODY
><RBW-PARABODY>If a CD in the current system contains a class that is defined in another system, the code generator does not generate code for that class.</RBW-PARABODY
><B.BODY>The generated PowerBuilder files are ASCII text files that can be imported into a PowerBuilder (<CX5FX5FFILE.NAME>.pbl</CX5FX5FFILE.NAME
>) library. This section describes how to edit the generated files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisite</L.LABEL
><B.BODY>At System level in the Implementation phase, the Browser displays a PowerBuilder menu that provides access to PowerBuilder features, such creating a PowerBuilder (<CX5FX5FFILE.NAME>.pbl</CX5FX5FFILE.NAME
>) library. To use the items in the PowerBuilder menu, the following PowerBuilder files must be in your path:</B.BODY
> provides command line access to the items in the PowerBuilder menu. For a description of <CX5FX5FFILE.NAME>genpbl</CX5FX5FFILE.NAME
> and the other ObjectTeam executables, see the <CX5FX5FTITLE>ObjectTeam System Administrator’s Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Edit generated files in PowerBuilder</L.LABEL
><B.BODY>The recommended method for editing the generated source files is to import them into a PowerBuilder (<CX5FX5FBULLET.EMPHASIS>.pbl</CX5FX5FBULLET.EMPHASIS
>) library, edit the library in PowerBuilder, and then export the modified information from the library back to the generated source files. <RBW-XREF REFID="36293" TYPE="XREF-TEXTCOPY">Workflow for Editing Files</RBW-XREF
> describes this process.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Text editor</SL.SUBLABEL
><B.BODY>You can also edit the generated source files using your default text editor; however, the PowerBuilder documentation discourages this way of editing PowerBuilder information. To edit a generated file using your default text editor, double&truehy;click on the file that you want to edit.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Keep Synchronized... property</L.LABEL
><B.BODY>The System&truehy;level property, Keep Synchronized With PowerBuilder Libraries, helps to automate the process of moving the generated PowerBuilder source files in and out of the PowerBuilder (<CX5FX5FBULLET.EMPHASIS>.pbl</CX5FX5FBULLET.EMPHASIS
>) libraries, as described in <RBW-XREF REFID="31389" TYPE="XREF-TEXTCOPY">Workflow Using the Keep Synchronized Property</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing generated files</L.LABEL
><BI.BODY.INTRO>The generated PowerBuilder files serve as framework files. They contain the code that reflects your model, but not all of the code necessary for the application. Comments indicate where you should add code to complete the application:</BI.BODY.INTRO
>A function or event is generated for each operation defined in an ObjectTeam class; however, you must add the code that implements the function or event. The script of the generated function or event contains one of the following comments. Add statements below the comment; optionally, delete the comment.</RBW-PARABODY
></LB.LIST.BULLET
><EM.EXAMPLE.MONO>// <RBWAUTO-0030>Implement this function</RBWAUTO-0030
>!</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>// <RBWAUTO-0030>Implement this event</RBWAUTO-0030
><RBW-PARABODY>A generated constructor or destructor event contains the following comments; it might also contain generated statements. Add statements between the comments.</RBW-PARABODY
></LB.LIST.BULLET
><EM.EXAMPLE.MONO>// Start user section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>// End user section</EM.EXAMPLE.MONO
><RBW-PARABODY>Other generated functions, such as the accessor methods for associations, also contain generated code. They do <CX5FX5FEMPHASIS>not</CX5FX5FEMPHASIS
> contain comments indicating where you should add code; therefore, you should <CX5FX5FEMPHASIS>not</CX5FX5FEMPHASIS
> add code to these functions. If you add code, it is not preserved when you regenerate the source files.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes are preserved</L.LABEL
><B.BODY>Changes you make to generated PowerBuilder files are preserved when you regenerate the files, provided that you adhere to the following guidelines:</B.BODY
><RBW-PARABODY>If you add variables (instance variables, shared variables, or new variables in a structure), functions, events, structures, or window controls to a generated object, use round&truehy;trip engineering to add the appropriate attributes, operations, or classes to the ObjectTeam model <CX5FX5FEMPHASIS>before</CX5FX5FEMPHASIS
><B.BODY>This section describes the workflow for generating PowerBuilder source files, editing the generated files, and then regenerating the source files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>PowerBuilder libraries</L.LABEL
><B.BODY>You can create PowerBuilder libraries in ObjectTeam or PowerBuilder. However, the items in the PowerBuilder menu only work with the PowerBuilder libraries created by ObjectTeam; therefore, the workflow described here uses ObjectTeam to create the PowerBuilder libraries that hold the generated source files.</B.BODY
><RBW-PARABODY>Generate the source files by importing systems or files into Implementation Phase level, as described in <RBW-XREF REFID="23311" TYPE="XREF-TEXTCOPY">Generating PowerBuilder Source Files</RBW-XREF
><LR2.LIST.RESULT.2>ObjectTeam opens a Monitoring window to display messages, creates a PowerBuilder library (<CX5FX5FVARIABLE>system&truehy;name</CX5FX5FVARIABLE
>.<CX5FX5FFILE.NAME>pbl</CX5FX5FFILE.NAME
>), and updates the Information area to display the name of the library.</LR2.LIST.RESULT.2
><RBW-PARABODY>Select PowerBuilder | Import Entries Into Library | All.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam opens a Monitoring window to display messages and imports the generated files into the PowerBuilder (<CX5FX5FFILE.NAME>.pbl</CX5FX5FFILE.NAME
><RBW-PARABODY>Exit from all PowerBuilder painters to ensure that you have saved all changes.</RBW-PARABODY
></LN2.LIST.NUM.2
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Library search paths</L.LABEL
><B.BODY>In ObjectTeam, when you import source files into a PowerBuilder library, ObjectTeam constructs and uses a temporary library path. The temporary library path lists all PowerBuilder libraries in the current Implementation phase. This ensures that the <CX5FX5FFILE.NAME>classlib.pbl</CX5FX5FFILE.NAME
> library is also included in the temporary library path. (<CX5FX5FFILE.NAME>classlib.pbl</CX5FX5FFILE.NAME
> is the PowerBuilder library created for you when you configure the PowerBuilder environment in the Implementation phase, as described in <RBW-XREF REFID="40480" TYPE="XREF-TEXTCOPY">Configuring Your PowerBuilder Environment</RBW-XREF
>.)</B.BODY
><B.BODY>In PowerBuilder, when you add a PowerBuilder library to your application, if that library references other libraries, you must ensure that you also add the referenced libraries to the library path of the application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to regenerate the edited source files</L.LABEL
><RBW-PARABODY>If, in PowerBuilder, you added variables (instance variables, shared variables, or new variables in a structure), functions, events, structures, or window controls to a generated object, use round&truehy;trip engineering to add the appropriate attributes, operations, or classes to the ObjectTeam model. See <RBW-XREF REFID="22218" TYPE="XREF-TEXTCOPY">Round&truehy;Trip Engineering</RBW-XREF
><RBW-PARABODY>Regenerate the source files, as described in the previous procedure (<RBW-XREF REFID="30704" TYPE="XREF-TEXTCOPY">How to generate and edit source files</RBW-XREF
>).</RBW-PARABODY
></LN.LIST.NUM
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Workflow</L.LABEL
><BI.BODY.INTRO>The following figure shows the workflow graphically:</BI.BODY.INTRO
>Workflow Using the Keep Synchronized Property</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Keep Synchronized property</L.LABEL
><B.BODY>When you select the System&truehy;level property Keep Synchronized With PowerBuilder Libraries, ObjectTeam automatically moves the generated files into and out of the PowerBuilder library for you:</B.BODY
><RBW-PARABODY>When you generate source files by importing systems or files into Implementation Phase level, the PowerBuilder code generator generates the source files <CX5FX5FEMPHASIS>and</CX5FX5FEMPHASIS
> imports them into the PowerBuilder library.</RBW-PARABODY
><RBW-PARABODY>If you are generating the source files for the first time and have not yet created a PowerBuilder library does not yet exist, the code generator automatically creates the PowerBuilder library.</RBW-PARABODY
><RBW-PARABODY>If you are regenerating the files, the code generator automatically exports the generated (edited) source files from the PowerBuilder library before regenerating the source files.</RBW-PARABODY
><RBW-PARABODY>When you use round&truehy;trip engineering, the code generator automatically exports the generated (edited) source files from the PowerBuilder library before running round&truehy;trip engineering.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to use the Keep Synchronized property</L.LABEL
><RBW-PARABODY>Generate the source files by importing systems or files into Implementation Phase level, as described in <RBW-XREF REFID="23311" TYPE="XREF-TEXTCOPY">Generating PowerBuilder Source Files</RBW-XREF
>.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam opens a Monitoring window to display messages, creates a PowerBuilder library (<CX5FX5FVARIABLE>system&truehy;name</CX5FX5FVARIABLE
>.<CX5FX5FFILE.NAME>pbl</CX5FX5FFILE.NAME
>), imports the generated files into the PowerBuilder (<CX5FX5FFILE.NAME>.pbl</CX5FX5FFILE.NAME
>) library, and updates the Information area.</LR.LIST.RESULT
><RBW-PARABODY>If, in PowerBuilder, you added variables (instance variables, shared variables, or new variables in a structure), functions, events, structures, or window controls to a generated object, use round&truehy;trip engineering to add the appropriate attributes, operations, or classes to the ObjectTeam model. See <RBW-XREF REFID="22218" TYPE="XREF-TEXTCOPY">Round&truehy;Trip Engineering</RBW-XREF
> for more information.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam exports the modified objects out of the PowerBuilder (<CX5FX5FFILE.NAME>.pbl</CX5FX5FFILE.NAME
>) library, updating the generated files, before running running&truehy;trip engineering.</LR.LIST.RESULT
><RBW-PARABODY>Regenerate the source files by importing systems or files into Implementation Phase level, as described in <RBW-XREF REFID="23311" TYPE="XREF-TEXTCOPY">Generating PowerBuilder Source Files</RBW-XREF
>.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam exports the modified objects out of the PowerBuilder (<CX5FX5FFILE.NAME>.pbl</CX5FX5FFILE.NAME
>) library, updating the generated files, before regenerating the source files.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Workflow</L.LABEL
><B.BODY>The following figure shows the workflow graphically. The operations shown in the shaded area are performed automatically when the Keep Synchronized With PowerBuilder Libraries property is selected.</B.BODY
>Regenerating Code<RBW-IDXTERM TERM1="code regeneration" TERM2="edited C++ source file"></RBW-IDXTERM
></S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Design changes and code changes</L.LABEL
><B.BODY>ObjectTeam supports incremental development. You can generate code from your models, edit that code, and regenerate the code without losing your changes. You can work with models during design and with code during implementation, shifting your focus between the two as necessary.</B.BODY
><B.BODY>It is, however, important that you make changes where appropriate.</B.BODY
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Change the code</CX5FX5FBULLET.EMPHASIS
> when you are adding code that is not generated by ObjectTeam (for example, adding method bodies), or when you are making local changes to the code (for example, adding a missing variable or function to a class).</RBW-PARABODY
>If you add variables, functions, events, structures, or controls to the code, you must add the appropriate attributes, operations, or classes to ObjectTeam before regenerating the source files. See <RBW-XREF REFID="38296" TYPE="XREF-TEXTCOPY">Editing Generated Source Files</RBW-XREF
><RBW-PARABODY><CX5FX5FBULLET.EMPHASIS>Change the model</CX5FX5FBULLET.EMPHASIS
> when you are changing the structure of the model (for example, if you are changing the class hierarchy or class associations), or when you are making global changes to the code (for example, if you are changing the name of a class, attribute, or operation).</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing generated files</L.LABEL
><B.BODY>The generated PowerBuilder files are framework files that you need to complete. Comments in the file indicate where you should add code.</B.BODY
><B.BODY>Always edit the generated files in accordance with the guidelines described in <RBW-XREF REFID="38296" TYPE="XREF-TEXTCOPY">Editing Generated Source Files</RBW-XREF
>. This ensures that your changes are preserved when you regenerate the PowerBuilder files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Editing the ObjectTeam model</L.LABEL
><B.BODY>The ObjectTeam model is always used as the source for generating the PowerBuilder files. If you change the model, you generally want to regenerate the PowerBuilder files.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Old files</SL.SUBLABEL
><B.BODY>Changes to the ObjectTeam model can cause a previously generated PowerBuilder file to change. In this case, the code generator saves the originally generated file. This saved copy of the generated file is marked as an <CX5FX5FEMPHASIS>old file</CX5FX5FEMPHASIS
> and appears highlighted in the Information area of the Browser.</B.BODY
><B.BODY>You can compare the old and new copies of a generated file and copy sections of the old file to the new file as necessary. However, you must always delete all old files before regenerating the PowerBuilder files.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Preserving files</SL.SUBLABEL
><B.BODY>If you want to save both the old files and the new files, you can copy the old files to another directory before deleting them from the Browser. Alternatively, before changing the ObjectTeam model, you can freeze both the model and the generated PowerBuilder files; this ensures that you have a stable version of the model and generated files to return to should your changes to the model not give the desired results.</B.BODY
>Using PowerBuilder With ObjectTeam</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This section contains hints and tips for using PowerBuilder and ObjectTeam to build applications.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>PowerBuilder libraries</L.LABEL
><B.BODY>The following guidelines for creating and maintaining PowerBuilder libraries that contain objects generated by ObjectTeam are strongly recommended:</B.BODY
><RBW-PARABODY>Import into the library only PowerBuilder source files originally generated by ObjectTeam. This ensures that all objects in the library are in the Cayenne repository.</RBW-PARABODY
><RBW-PARABODY>An ObjectTeam system can contain at most one PowerBuilder library. Import into a PowerBuilder library only the source files that are contained in the same system. This ensures that the source files are correctly regenerated.</RBW-PARABODY
><RBW-PARABODY>When you add these libraries to the library search path of a PowerBuilder application, point directly to the library created by ObjectTeam. This ensures that you are using the library that is in the Cayenne repository.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>PowerBuilder applications</L.LABEL
><B.BODY>When you create an application in PowerBuilder, you can have PowerBuilder build an application template. Typically, you do <CX5FX5FEMPHASIS>not</CX5FX5FEMPHASIS
> want to build the application template if you plan to use ObjectTeam.</B.BODY
><B.BODY>If you choose to build a template application, PowerBuilder adds a number of objects to the default library of the application. Because these objects are originally created in PowerBuilder, you cannot use ObjectTeam to edit or maintain them.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Reusing objects</L.LABEL
><B.BODY>If you have objects defined in existing PowerBuilder (<CX5FX5FFILE.NAME>.pbl</CX5FX5FFILE.NAME
>) libraries, you can reuse those objects by referencing them as external classes in ObjectTeam. See <RBW-XREF REFID="37141" TYPE="XREF-TEXTCOPY">Using External Objects</RBW-XREF
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Variable and access functions</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Upper&truehy; and lower&truehy;case characters</L.LABEL
><B.BODY>ObjectTeam is case&truehy;sensitive, but in many cases PowerBuilder allows only lower&truehy;case characters. To prevent potential problems, Cayenne strongly recommends that you use only lower&truehy;case characters when naming items in ObjectTeam systems used with the PowerBuilder code generator.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisites</L.LABEL
><B.BODY>This chapter assumes that you are familiar with generating and editing PowerBuilder source files, as described in Chapter 2, Generating Code.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Examples</L.LABEL
><B.BODY>When you are using the PowerBuilder code generator, every ObjectTeam class must have a valid supertype class. For simplicity, the examples in this chapter do not show the supertype class. Unless otherwise indicated, you can assume that the supertype class is nonvisualobject, which generates a custom class object.</B.BODY
><B.BODY>An ObjectTeam class maps to a PowerBuilder object.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Supertype class indicates object type</L.LABEL
><B.BODY>The supertype of an ObjectTeam class indicates the type of PowerBuilder object that you want to generate. If an ObjectTeam class does not have a valid supertype class, ObjectTeam generates a custom class user object.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>PBBuiltins</SL.SUBLABEL
><B.BODY>Each type of PowerBuilder object that ObjectTeam can generate is represented as a class in the PBBuiltins system; these classes are the valid supertype classes. ObjectTeam creates the PBBuiltins system when you configure the Object Design environment, as described in <RBW-XREF REFID="40480" TYPE="XREF-TEXTCOPY">Configuring Your PowerBuilder Environment</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Global and local objects</L.LABEL
><B.BODY>The Global Type property of the ObjectTeam class determines whether the generated PowerBuilder object is global or local.</B.BODY
>ObjectTeam generates PowerBuilder source files only for global objects. Typically, local objects are contained in a global object and, therefore, defined in the source file of that global object.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Constructors and destructors</L.LABEL
><B.BODY>PowerBuilder supports constructor and destructor events for many types of objects. ObjectTeam generates these events in the following situations:</B.BODY
><RBW-PARABODY>You define an operation named constructor or destructor and, in the operation properties, select the Event check box to indicate that the operation should be generated as an event. See <RBW-XREF REFID="14596" TYPE="XREF-TEXTCOPY">Mapping Operations</RBW-XREF
><RBW-PARABODY>You define an association. In this case, ObjectTeam generates a constructor event to support creation and maintenance of the association. See <RBW-XREF REFID="14358" TYPE="XREF-TEXTCOPY">Mapping Associations</RBW-XREF
>Many ObjectTeam code generators generate constructors based on the existence of a $create operation. The PowerBuilder code generator does no special processing for a $create operation.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class properties</L.LABEL
><B.BODY>You use ObjectTeam’s class properties to provide input to the code generator. <RBW-XREF REFID="39809" TYPE="XREF-TEXTCOPY">Editing Class Properties</RBW-XREF
> describes how to edit class properties, and the effect of each property.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section contains the following topics:</B.BODY
><B.BODY>Every ObjectTeam class must have a valid supertype class. The code generator uses the supertype class to determine what type of PowerBuilder object to generate.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>To model a PowerBuilder window, for example, you create an ObjectTeam class whose supertype is window. (The window class is defined in the PBBuiltins system.)</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Default supertype class</L.LABEL
><B.BODY>If an ObjectTeam class does not have a supertype class, the PowerBuilder code generator displays a warning message and uses nonvisualobject as the supertype class. This indicates that the desired PowerBuilder object type is custom class user object.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Supertype classes for PowerBuilder types</L.LABEL
><B.BODY>The following table lists the PowerBuilder object types generated by ObjectTeam and their matching supertype classes from the PBBuiltins system:</B.BODY
><B.BODY>A structure groups variables; therefore, an ObjectTeam class that represents a structure should contain only attributes. The PowerBuilder code generator ignores any operations that are specified for such a class.</B.BODY
><B.BODY>A structure can be either a global or local object. As described in <RBW-XREF REFID="13782" TYPE="XREF-TEXTCOPY">Specifying Global Type</RBW-XREF
>, the Global Type property of the ObjectTeam class that represents the structure determines whether the structure is generated as a global or local object.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Standard class user objects</L.LABEL
><B.BODY>A standard class user object inherits its definition from a built&truehy;in, nonvisual PowerBuilder object, such as a connection or datastore. The attributes and operations that you specify for an ObjectTeam class that represents a standard class user object enhance the behavior of the built&truehy;in PowerBuilder object.</B.BODY
><B.BODY>A standard class user object should be a global object; therefore, the Global Type property of an ObjectTeam class that represents a standard class user object should be set to Yes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Custom class user object</L.LABEL
><B.BODY>A custom class user object is an object of your own design that encapsulates the attributes (variables) and operations (functions) that you specify.</B.BODY
><B.BODY>A custom class user object should be a global object; therefore, the Global Type property of an ObjectTeam class that represents a custom class user object should be set to Yes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Visual objects</L.LABEL
><B.BODY>Chapter 4, Modeling the Visual Interface, provides more information about modeling windows, menus, standard visual user objects, and custom visual user objects.</B.BODY
> objects are contained in global objects. A local object is defined in a global object and can only be accessed within the context of that object.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Global Type property</L.LABEL
><B.BODY>The Global Type property of an ObjectTeam class determines whether the generated PowerBuilder object is global or local:</B.BODY
> indicates that the object is local.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</SL.SUBLABEL
><B.BODY><RBW-XREF REFID="39809" TYPE="XREF-TEXTCOPY">Editing Class Properties</RBW-XREF
> describes how to set class properties.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Source files generated for global objects only</L.LABEL
><B.BODY>The PowerBuilder code generator generates a PowerBuilder source file for each ObjectTeam class that represents a global PowerBuilder object.</B.BODY
><B.BODY>The PowerBuilder code generator does not generate source files for local objects. Typically, a local object is contained in a global object and is defined in the source file generated for the global object.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Global objects must be defined items</L.LABEL
><B.BODY>Before generating code, check that all classes that represent global objects are defined items. If a class is not a defined item, it is an external class; ObjectTeam does not generate code for external classes.</B.BODY
><RBW-PARABODY>If the Define Item button is available, the class is not a defined item. Select the Define Item button to define the item.</RBW-PARABODY
><RBW-PARABODY>Use the Global Type field to indicate whether the object is global or local, as described in <RBW-XREF REFID="13782" TYPE="XREF-TEXTCOPY">Specifying Global Type</RBW-XREF
><RBW-PARABODY>Use the Autoinstantiate field to indicate that the generated object is autoinstantiated (that is, a variable whose data type is the same as this class is automatically assigned an instance of the class when the variable comes in scope).</RBW-PARABODY
><RBW-PARABODY>Use the Window Type field to specify the type of the generated window: Child, Main (default), MDI, MDIHelp, Popup, or Response.</RBW-PARABODY
>If the Global Type property of an ObjectTeam class is set to No, the code generator ignores the data attributes of the class. See <RBW-XREF REFID="39809" TYPE="XREF-TEXTCOPY">Editing Class Properties</RBW-XREF
> for more information.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attribute syntax</L.LABEL
><B.BODY>In ObjectTeam, you use the following syntax to specify attributes for a class:</B.BODY
><E.EXAMPLE>[ * | $ | / ] name : type [ = initial&truehy;value ]</E.EXAMPLE
><RBW-PARABODY>$ indicates a class attribute, which is generated as a shared variable.<RBW-IDXTERM TERM1="attribute" TERM2="class attribute"></RBW-IDXTERM
><RBW-PARABODY>/ indicates a derived attribute. PowerBuilder does not support derived attributes; therefore, this indicator is ignored by the code generator.<RBW-IDXTERM TERM1="derived attribute"></RBW-IDXTERM
> is either a standard type or the name of another class, as described in <RBW-XREF REFID="19428" TYPE="XREF-TEXTCOPY">Specifying Attribute Data Types</RBW-XREF
>, if specified, is the initial value assigned to the generated variable. The code generator does not validate the data type of the specified value. <RBW-IDXTERM TERM1="attribute" TERM2="default value"></RBW-IDXTERM
><RBW-IDXTERM TERM1="default value, for attribute"></RBW-IDXTERM
><RBW-IDXTERM TERM1="initial value, for attribute"></RBW-IDXTERM
></RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attribute maps to variable</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="variable, in Visual Basic"></RBW-IDXTERM
>By default, an attribute maps to an instance variable, as shown in the following example:</B.BODY
><B.BODY>You use attribute properties to provide input to the code generator. <RBW-XREF REFID="17827" TYPE="XREF-TEXTCOPY">Editing Attribute Properties</RBW-XREF
> describes how to edit attribute properties, and the effect of each property.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section contains the following topics:</B.BODY
><B.BODY>The standard data types are defined by the <CX5FX5FFILE.NAME><RBW-IDXTERM TERM1="stand_types customization file"></RBW-IDXTERM
>stand_types</CX5FX5FFILE.NAME
> customization file. These are the data types that are valid in the Object Design phase.</B.BODY
><B.BODY>The translation between standard data types and PowerBuilder data types is defined by the <CX5FX5FFILE.NAME><RBW-IDXTERM TERM1="lang_types customization file"></RBW-IDXTERM
>lang_types</CX5FX5FFILE.NAME
> customization file. These are the translations used by the PowerBuilder code generator.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing the standard data types</L.LABEL
><B.BODY>You can add additional data types to the list of standard types by editing the <CX5FX5FFILE.NAME>stand_types</CX5FX5FFILE.NAME
> customization file. If you add additional standard types, you must also provide translations for those data types by editing the <CX5FX5FFILE.NAME>lang_types</CX5FX5FFILE.NAME
> customization file.</B.BODY
><B.BODY>By default, the <CX5FX5FFILE.NAME>stand_types</CX5FX5FFILE.NAME
> and <CX5FX5FFILE.NAME>lang_types</CX5FX5FFILE.NAME
> customization files are defined on Corporate level in the <CX5FX5FFILE.NAME>\etc\l_pb</CX5FX5FFILE.NAME
> external directory. You can edit the customization files at Corporate level, or create and edit them at a lower level, such as Project level. (The customization files at the lower level override the customization files at the higher level.)</B.BODY
><B.BODY>In the Object Design phase, you use attribute properties to specify attribute access and to indicate whether the attribute is a constant.</B.BODY
><RBW-PARABODY>Use the Constant Attribute field to generate a constant rather than a variable, as described in <RBW-XREF REFID="17590" TYPE="XREF-TEXTCOPY">Specifying Constants</RBW-XREF
><RBW-PARABODY>Use the Attribute Access field to specify the read/write access for the attribute, as described in <RBW-XREF REFID="34899" TYPE="XREF-TEXTCOPY">Specifying Attribute Access</RBW-XREF
><RBW-PARABODY>Use the Text tab to enter comment text. The text does not appear in the generated code.<RBW-IDXTERM TERM1="comment" TERM2="for attribute"></RBW-IDXTERM
><B.BODY>Select the Attribute Constant check box on the Misc tab of the Edit Properties dialog box to generate a constant rather than a variable.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Initial value required</L.LABEL
><B.BODY>ObjectTeam uses the attribute’s initial value as the value of the constant. If you select the Attribute Constant checkbox for an attribute, you must also specify an initial value for the attribute.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>In the following example, the Attribute Constant property is selected for the displayfont attribute; it is not selected for the name attribute.</B.BODY
>The values you specify in the Attribute Access group box on the Misc tab of the Edit Properties dialog box determine which access keywords are included in the declaration of the generated variable or constant. In PowerBuilder, these access keywords control access to the variable or constant.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Examples</L.LABEL
><B.BODY>The following examples show how the Attribute Access fields (Read&truehy;Write) affect code generation for the name attribute.</B.BODY
> By default, an operation maps to a function. If the operation has a return type, the function has a return value; otherwise, it does not.</RBW-PARABODY
> If the Event property of an operation is selected, as described in <RBW-XREF REFID="19182" TYPE="XREF-TEXTCOPY">Editing Operation Properties</RBW-XREF
>Functions are only generated if the Global Type property of the class is set to Yes. See <RBW-XREF REFID="39809" TYPE="XREF-TEXTCOPY">Editing Class Properties</RBW-XREF
> for more information about the Global Type property.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Operation syntax</L.LABEL
><B.BODY>In ObjectTeam, you use the following syntax to specify operations for a class:</B.BODY
><RBW-PARABODY>$ indicates a class operation. PowerBuilder does not support shared operations; therefore, this indicator is ignored by the code generator.<RBW-IDXTERM TERM1="class" TERM2="procedure"></RBW-IDXTERM
> of a parameter is either a standard type or a class modeled in the CD. Specifying the data type of a parameter is similar to specifying the data type of an attribute (see <RBW-XREF REFID="19428" TYPE="XREF-TEXTCOPY">Specifying Attribute Data Types</RBW-XREF
> is either a standard type or a class modeled in the CD. Specifying the return type for a function is similar to specifying the data type of an attribute (see <RBW-XREF REFID="19428" TYPE="XREF-TEXTCOPY">Specifying Attribute Data Types</RBW-XREF
><RBW-PARABODY>{abstract} indicates an abstract operation. PowerBuilder does not support abstract operations; therefore, this indicator is ignored by the code generator.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="18902"></RBW-ANCHOR
>Example</L.LABEL
><B.BODY>The following code excerpt shows the default translation of two operations on the customer class:</B.BODY
><EM.EXAMPLE.MONO>// Implement this function !!</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>end subroutine</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Properties</L.LABEL
><B.BODY>You use properties on operations and their parameters to provide input to the code generator. The following sections describe how to edit these properties, and the effect of each property.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Association accessor functions</L.LABEL
><B.BODY>The PowerBuilder code generator also generates association accessor functions, as described in <RBW-XREF REFID="27062" TYPE="XREF-TEXTCOPY">Mapping Simple Associations</RBW-XREF
>. (You do not specify these functions as operations on the ObjectTeam class.)</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section contains the following topics:</B.BODY
><B.BODY>In the Object Design phase, you define operation properties to specify operation access and whether the operation should be generated as an event.</B.BODY
><RBW-PARABODY>Use the Method Access field to specify the read/write access for the method, as described in <RBW-XREF REFID="29675" TYPE="XREF-TEXTCOPY">Specifying Method Access</RBW-XREF
><RBW-PARABODY>Use the Text tab to enter comment text. This text does not appear in generated code.<RBW-IDXTERM TERM1="comment" TERM2="for operation"></RBW-IDXTERM
><B.BODY>In the example at the beginning of this section (see <RBW-XREF REFID="18902" TYPE="XREF-TEXTCOPY">Example</RBW-XREF
>), the Method Access property for both operations is set to public (the default). In the following example, the Method Access property for the checkCredit operation is set to protected and the Method Access property for the print operation is set to private.</B.BODY
>The values you specify in the Method Access field on the Misc tab of the Edit Properties dialog box determine wether the generated function is one of the following:</B.BODY
><B.BODY>You can display the access level of methods in your diagram by checking Options | Show Visibility in the Class Diagram Editor. Method names will then be displayed with the following leading characters indicating the method’s access level:</B.BODY
><B.BODY>These special characters can also be used to <CX5FX5FEMPHASIS>set</CX5FX5FEMPHASIS
> the access level of methods. Typing a minus sign (&truehy;) before a method name will set the access level of the method to Private, for example. </B.BODY
>The special characters only work if the menu entry Options | Show Visibility in the Class Diagram Editor has been checked. Otherwise, the special characters will just be regarded as part of the method name.</W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Examples</L.LABEL
><B.BODY>The following examples show how the Method Access field affect code generation for the print method.</B.BODY
><RBW-PARABODY>Use the Pass By field to specify how the parameter should be passed to the function: by value (default), by reference, or as a readonly parameter.</RBW-PARABODY
><BI.BODY.INTRO>The following examples show how the Pass By field affects code generation of the print subroutine and its copies parameter.</BI.BODY.INTRO
>Both ObjectTeam and PowerBuilder provide full support for single inheritance. PowerBuilder does not support mulitple inheritance; therefore, the PowerBuilder code generator displays an error if an ObjectTeam class has more than one supertype class.</B.BODY
>In ObjectTeam, you can specify either disjoint or overlapping inheritance. The PowerBuilder code generator generates the code for disjoint inheritance, regardless of which symbol you use.</B.BODY
><B.BODY>An ObjectTeam association maps to a PowerBuilder variable and a set of accessor functions that maintain the variable.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Restrictions</L.LABEL
><B.BODY>If the Global Type property of an ObjectTeam class is set to No, the code generator ignores the associations of the class. See <RBW-XREF REFID="39809" TYPE="XREF-TEXTCOPY">Editing Class Properties</RBW-XREF
> for more information about the Global Type property.</B.BODY
><B.BODY>The constructor event of the generated PowerBuilder object is used to initialize the association variable. To allow associations for windows, the code generator creates a constructor event for the window and uses the window’s open event to trigger the window’s constructor event.</B.BODY
><B.BODY>N&truehy;ary associations are ignored by the PowerBuilder code generator. Code is generated for the classes involved, but no code is generated for the n&truehy;ary association.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Optionality</L.LABEL
><B.BODY>If a class has a mandatory association, the constructor for the class <CX5FX5FEMPHASIS>should</CX5FX5FEMPHASIS
> ensure that it is related to an instance of the associated class. PowerBuilder’s constructors do not support parameters; therefore, in the current release of the PowerBuilder generator, the generated class constructor does <CX5FX5FEMPHASIS>not</CX5FX5FEMPHASIS
>The PowerBuilder code generator translates aggregations like associations, unless the aggregrations are being used to model object containment. See Chapter 4, Modeling the Visual Interface, for more information about using aggregations to model container objects.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Ordered associations</L.LABEL
><B.BODY>The {ordered} indicator on an association is ignored by the PowerBuilder code generator. In lists of associations generated by the PowerBuilder code generator, new elements are always added to the front of the list.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section contains the following topics:</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="20798" TYPE="XREF-TEXTCOPY">Mapping Link Attributes and Classes as Associations&rbwtab;3–39</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="16465" TYPE="XREF-TEXTCOPY">Specifying Access Methods for Associations&rbwtab;3–43</RBW-XREF
><B.BODY>This section describes how the PowerBuilder code generator implements the following simple associations between the customer class and the book class.</B.BODY
>The direction of an association is defined by the role names on the association. A role name at the far end of the association indicates an association from the class at the near end to the class at the far end.</B.BODY
><B.BODY>If an association has a role name at only one end, it is a <CX5FX5FEMPHASIS>unidirectional</CX5FX5FEMPHASIS
> association (implemented in one direction). If an association has role names at both ends, it is a <CX5FX5FEMPHASIS>bidirectional</CX5FX5FEMPHASIS
> association (implemented in both directions).</B.BODY
>The PowerBuilder code generator implements a unidirectional association by adding an <CX5FX5FEMPHASIS>association attribute</CX5FX5FEMPHASIS
> and a set of <CX5FX5FEMPHASIS>association accessor methods</CX5FX5FEMPHASIS
> to the code generated for the class at the near end of the association. This allows the class at the near of the association (customer) to access the class at the far end (book); the class at the far end of the association cannot access the class at the near end.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Mapping a bidirectional association</L.LABEL
><B.BODY>The PowerBuilder code generator implements a bidirectional association by adding an <CX5FX5FEMPHASIS>association attribute</CX5FX5FEMPHASIS
> and a set of <CX5FX5FEMPHASIS>association accessor methods</CX5FX5FEMPHASIS
> to the code generated for both classes. This allows each class to access the other. To ensure integrity of a bidirectional association, the update method for a bidirectional association always maintains the association in both directions.</B.BODY
>The ObjectTeam documentation and generated PowerBuilder code use the term <CX5FX5FTERM>association attributes</CX5FX5FTERM
> to refer to data attributes generated to support ObjectTeam associations (as opposed to data attributes generated from ObjectTeam attributes). In PowerBuilder, an association attribute is simply another data attribute.</B.BODY
> use the association attributes to implement and maintain the associations between the classes. By default, the code generator creates public methods that read and update the association (association attributes). However, you can use the Association Access property of the association to change this default behavior, as described in <RBW-XREF REFID="16465" TYPE="XREF-TEXTCOPY">Specifying Access Methods for Associations</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example of a unidirectional association</L.LABEL
><B.BODY>Following is an excerpt from the code generated for the customer class in the unidirectional association. Because this is a unidirectional association, the book class does not contain any code related to the association.</B.BODY
><RBW-PARABODY>The association attribute, customer.possession, defines the association between the customer and the book. The constructor initializes the association attribute.</RBW-PARABODY
><EM.EXAMPLE.MONO>// Start user code section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>// End user code section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>end event</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example of a bidirectional association</L.LABEL
><B.BODY>Following is an excerpt from the code generated for the customer class in the bidirectional association. Because this is a bidirectional association, the book class would contain similar code.</B.BODY
><B.BODY>Notice that the remove, set and get functions maintain the association in both directions:</B.BODY
><RBW-PARABODY>As in the previous example, the functions update the association attribute customer.possession to reflect the association between the customer and the book.</RBW-PARABODY
> shows the code generated for associations with a multiplicity of one. This section shows the code generated for associations with a multiplicity of many.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisite</L.LABEL
><B.BODY>This section assumes that you are familiar with the information in the previous section, <RBW-XREF REFID="27062" TYPE="XREF-TEXTCOPY">Mapping Simple Associations</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Multiplicity of many</L.LABEL
><B.BODY>In the following example, each customer can have zero or more books:</B.BODY
><B.BODY>For an association with multiplicity of many, the type of the association attribute is classset. The classset class, which is supplied with the PowerBuilder code generator, includes special methods for handling sets of associations. The association accessor methods use these special methods to get, add, and remove associations.</B.BODY
>ObjectTeam copies the classset class to your user environment when you configure your Implementation environment, as described in <RBW-XREF REFID="40480" TYPE="XREF-TEXTCOPY">Configuring Your PowerBuilder Environment</RBW-XREF
>.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated code</L.LABEL
><B.BODY>Following is an excerpt from the code generated for the customer class shown above. Notice that</B.BODY
><RBW-PARABODY>The add function adds an association to the set of associations. (The add function is similar to the set function that is generated for an association with multiplicity of one.)</RBW-PARABODY
><BI.BODY.INTRO>In the following example, each customer can have at most 10 books. The PowerBuilder code generator ignores the numeric specifier. The code generated for this association is the same as that shown above.</BI.BODY.INTRO
><B.BODY>You can, of course, effect the code generated for any of these association by editing the association properties, as described in <RBW-XREF REFID="16465" TYPE="XREF-TEXTCOPY">Specifying Access Methods for Associations</RBW-XREF
>The mapping of a qualified association, is similar to that of an association with multiplicity of many. For a qualified association, however, the qualifier (bookid, in the following example) is used to identify each association in the set of associations.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisite</L.LABEL
><B.BODY>This section assumes that you are familiar with the information in the previous section, <RBW-XREF REFID="27062" TYPE="XREF-TEXTCOPY">Mapping Simple Associations</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Qualified association</L.LABEL
><B.BODY>This section describes how the PowerBuilder code generator implements the following associations between the customer class and the book class. </B.BODY
><B.BODY>For a qualified association, the type of the association attribute is classdict. The classdict class, which is supplied with the PowerBuilder code generator, includes special methods for handling qualifiers. The association accessor methods use these special methods to access the qualifier.</B.BODY
>ObjectTeam copies the classdict class to your user environment when you configure your Implementation environment, as described in <RBW-XREF REFID="40480" TYPE="XREF-TEXTCOPY">Configuring Your PowerBuilder Environment</RBW-XREF
>.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><BI.BODY.INTRO>Following are excerpts from the code generated for the customer and book classes shown above. Notice that</BI.BODY.INTRO
><RBW-PARABODY>The association customer.possession is managed using an association attribute with type classdict class, and the bookid index.</RBW-PARABODY
><EWM.EXAMPLEW.MONO>// Start user code section</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>// End user code section</EWM.EXAMPLEW.MONO
><EWM.EXAMPLEW.MONO>end event</EWM.EXAMPLEW.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Association properties</L.LABEL
><B.BODY>You can effect the code generated for any association by editing the association properties, as described in <RBW-XREF REFID="16465" TYPE="XREF-TEXTCOPY">Specifying Access Methods for Associations</RBW-XREF
>Mapping Link Attributes and Classes as Associations</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisite</L.LABEL
><B.BODY>This section assumes that you are familiar with the mapping of various types of associations, as described in the previous sections.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="35128"></RBW-ANCHOR
>Attributes and classes on associations</L.LABEL
><B.BODY>ObjectTeam allows you to specify information about an association by linking attributes, or a class, to the association. The following diagram shows a link attribute symbol; a class symbol could be used in the same location.</B.BODY
><B.BODY>An association that includes a link attribute or a class is transformed before code generation. The link attribute or class becomes a separate class, with appropriate associations to the original classes. The generated code is then based on the transformed association.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The code generated for the CD shown above is actually based on the following CD:</B.BODY
>If an attribute is linked to the association, the new class is assigned the name of the association. Therefore, an association that has a link attribute must have an association name.</B.BODY
>The class created for the link attribute does not have a supertype class. As for any class that does not have a supertype class, the code generator uses nonvisualobject as the supertype class, which creates a custom class user object.</N.NOTE
><RBW-IDXTERM TERM1="mapping" TERM2="class, as association"></RBW-IDXTERM
>If a class is linked to the association, that class is used as the third class. Therefore, an association that is described by a class does not need an association name.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role names are required</L.LABEL
><B.BODY>As with all associations, role names are required. If a role name is omitted, the association attributes and methods that would map to that role name are not generated.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><BI.BODY.INTRO>Following is the code generated for the link attribute shown above (<RBW-XREF REFID="35128" TYPE="XREF-TEXTCOPY">Attributes and classes on associations</RBW-XREF
>). The code reflects the transformed CD (<RBW-XREF REFID="30454" TYPE="XREF-TEXTCOPY">Association mapped as two associations</RBW-XREF
>Only the get functions are generated for associations that include link attributes or classes. The remove and add functions are not generated.</N.NOTE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Generated code for the purchase class</SL.SUBLABEL
><B.BODY></B.BODY
><EM.EXAMPLE.MONO>// Association attributes</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>// Start user code section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>// End user code section</EM.EXAMPLE.MONO
><EM.EXAMPLE.MONO>end event</EM.EXAMPLE.MONO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Association properties</L.LABEL
><B.BODY>You can effect the code generated for any association by editing the association properties, as described in <RBW-XREF REFID="16465" TYPE="XREF-TEXTCOPY">Specifying Access Methods for Associations</RBW-XREF
>Specifying Access Methods for Associations</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>The values you specify in the Association Access group box on the Edit Properties dialog box for an association determines what association accessor methods are generated for the association.</B.BODY
>The association accessor methods for bidirectional associations are always public. Therefore, for bidirectional associations, the Association Access group box on the Edit Properties dialog box is ignored.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Read&truehy;write access</L.LABEL
><B.BODY>The Association Access group box contains a Read field and a Write field. For each field, you can specify one of the following values:</B.BODY
><RBW-IDXTERM TERM1="access property" TERM2="for association attribute"></RBW-IDXTERM
>Use the Association Access field to specify which association methods are generated for the association attribute. See the examples below.</RBW-PARABODY
> shows an example of a unidirectional association and the code generated for the association. If you modify the Association Access field for the possession role, specifying the Read field as Protected and the Write field as Private, the following code would be generated:</B.BODY
><RBW-TEXTFLD TYPE="text">Code Generation Guide for PowerBuilder</RBW-TEXTFLD
></RBW-SYSOBJ
></C.CHAPTER.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This chapter describes how to model the visual interface of an application. This includes modeling windows, menus, visual custom user objects, and visual standard objects.</B.BODY
><RBW-PARABODY>Nonvisual objects: custom class objects, class standard objects, and structures.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Upper&truehy; and lower&truehy;case characters</L.LABEL
><B.BODY>ObjectTeam is case&truehy;sensitive, but in many cases PowerBuilder allows only lower&truehy;case characters. To prevent potential problems, Cayenne strongly recommends that you use only lower&truehy;case characters when naming items in ObjectTeam systems used with the PowerBuilder code generator.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisites</L.LABEL
><B.BODY>This chapter assumes that you are familiar with the following:</B.BODY
><RBW-PARABODY>Valid supertype classes and the Global Type class property, as described in <RBW-XREF REFID="15448" TYPE="XREF-TEXTCOPY">Mapping Classes on page 3–3</RBW-XREF
><RBW-PARABODY>Generating and editing PowerBuilder source files, as described in <RBW-XREF REFID="40013" TYPE="XREF-TEXTCOPY">Chapter 2, Generating Code</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Examples</L.LABEL
><B.BODY>For simplicity, in the examples in this chapter, classes do not have attributes, operations, or associations (except those that are used to model the user interface). </B.BODY
><B.BODY>Global classes can have attributes, operations, and/or associations. If included, these features are mapped to PowerBuilder variables and functions, as described in <RBW-XREF REFID="16205" TYPE="XREF-TEXTCOPY">Chapter 3, Modeling Nonvisual Elements</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="40978" TYPE="XREF-TEXTCOPY">Modeling Standard Visual User Objects&rbwtab;4–15</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="16125" TYPE="XREF-TEXTCOPY">Modeling Custom Visual User Objects&rbwtab;4–18</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="28166" TYPE="XREF-TEXTCOPY">Modeling Data Windows&rbwtab;4–21</RBW-XREF
>The folded classes in the CD (picture, window, singlelineedit, commandbutton, and statictext) are defined in the PBBuiltins system. The unfolded classes represent the window elements that you are modeling. </B.BODY
><B.BODY>As described in <RBW-XREF REFID="15448" TYPE="XREF-TEXTCOPY">Mapping Classes on page 3–3</RBW-XREF
>, each ObjectTeam class must have a valid supertype class. The supertype class indicates the type of PowerBuilder object that you want to generate.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Aggregations</L.LABEL
><B.BODY>In PowerBuilder, certain objects can contain other objects. For example, the w_welcome window contains a picture, 3 static text fields, 2 singleline edit fields, and 2 command buttons. </B.BODY
><B.BODY>The w_welcome window is an <CX5FX5FEMPHASIS>aggregation</CX5FX5FEMPHASIS
> of these controls; therefore, in the CD, aggregations are used to show containment. The role name of the aggregation becomes the name of the control in PowerBuilder.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Steps for modeling the window</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="window" TERM2="representing in ObjectTeam"></RBW-IDXTERM
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Create the w_welcome class to represent the window. Also, add the window class and make w_welcome a subclass of window.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Add attributes and operations to the w_welcome class. For simplicity, in this example, only the wf_connect operation is added.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Create the p_sports class to represent the picture control. Also, add the picture class and make p_sports a subclass of picture.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Create the sle_userid and sle_password classes to represent the single line edit controls. Add the singlelineedit class and make sle_userid and sle_password subclasses of singlelineedit.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Create the cb_ok and cb_cancel classes to represent the command button controls. Add the commandbutton class and make cb_ok and cb_cancel subclasses of commandbutton.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Create the st_welcome, st_userid, and st_password classes to represent the static text controls. Add the statictext class and make st_welcome, st_userid, and st_password subclasses of statictext.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The w_welcome window contains all eight controls. It is an <CX5FX5FTERM>aggregation</CX5FX5FTERM
> of these controls. Create the eight relationships that define the aggregation. Each relationship must have a role name. </CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Add a clicked event to the cb_ok class and cb_cancel class. </CELLBODY
><CELLBODY>To do so: add a clicked() operation; select Item | Edit Properties; select the clicked operation; and select the Event check box on the Misc tab of the Edit Properties dialog.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The w_welcome window is a global object. The controls on the w_welcome window are local objects.</CELLBODY
><CELLBODY>The Global Type property of an ObjectTeam class indicates whether the generated PowerBuilder object is global (default) or local. For each of the 8 control classes, change the value of the Global Type property from Yes to No.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The w_welcome window is a Response window. Set the Window Type property of the w_welcome class to Response.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>For each class that is not defined in the system, select Item | Edit properties. If the Define item button is available, select it to define the class item. See <RBW-XREF REFID="39577" TYPE="XREF-TEXTCOPY">All classes must be defined items</RBW-XREF
> for more information.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="39577"></RBW-ANCHOR
>All classes must be defined items</L.LABEL
><B.BODY>ObjectTeam generates code for class items. It does not generate code for graphical elements that do not have associated class items.</B.BODY
><B.BODY>When you create a class, ObjectTeam creates a graphical element. When you perform one of the following actions, ObjectTeam creates a class item:</B.BODY
><BI.BODY.INTRO>In ObjectTeam, you model the content of the window, not its layout. Therefore, the generated PowerBuilder file defines the window and its controls, but it does not define the properties of the window or its controls. <RBW-IDXTERM TERM1="form" TERM2="layout information"></RBW-IDXTERM
>When you open the generated window in PowerBuilder, it appears as shown below (the controls are stacked in the upper left corner):</BI.BODY.INTRO
><RBW-PARABODY>Adjust the size of the window.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>When you are done, the window looks like the one shown at the beginning of this section (see <RBW-XREF REFID="11320" TYPE="XREF-TEXTCOPY">page 4–3</RBW-XREF
>When you export the window from the PowerBuilder (<CX5FX5FFILE.NAME>.pbl</CX5FX5FFILE.NAME
>) library, the exported source file reflects the changes that you made in PowerBuilder. ObjectTeam preserves the changes when you regenerate the file. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What you can change in PowerBuilder</L.LABEL
><BI.BODY.INTRO><RBW-XREF REFID="38296" TYPE="XREF-TEXTCOPY">Editing Generated Source Files on page 2–13</RBW-XREF
> provides guidelines for editing generated PowerBuilder files. When editing visual objects in PowerBuilder, adhere to those general guidelines <CX5FX5FEMPHASIS>and</CX5FX5FEMPHASIS
> to the following guidelines for visual objects:</BI.BODY.INTRO
><RBW-PARABODY>You can add code to a generated event. The body of each generated event contains the following comment. Add your code below the comment.</RBW-PARABODY
></LB.LIST.BULLET
><EM.EXAMPLE.MONO>// <RBWAUTO-0030>Implement this event</RBWAUTO-0030
><RBW-PARABODY>You can add new control events; however, you must then add those events to the appropriate control class in ObjectTeam <CX5FX5FEMPHASIS>before</CX5FX5FEMPHASIS
> regenerating the PowerBuilder files. Round&truehy;trip engineering can do this for you, as described in <RBW-XREF REFID="22218" TYPE="XREF-TEXTCOPY">Round&truehy;Trip Engineering on page 5–11</RBW-XREF
><RBW-PARABODY>You can add controls to a window; however, you must then define the same controls in ObjectTeam by adding the appropriate classes to the ObjectTeam model <CX5FX5FEMPHASIS>before</CX5FX5FEMPHASIS
> regenerating the PowerBuilder files. Round&truehy;trip engineering can do this for you, as described in <RBW-XREF REFID="22218" TYPE="XREF-TEXTCOPY">Round&truehy;Trip Engineering on page 5–11</RBW-XREF
><RBW-PARABODY>Model the window only</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Model the window and controls</L.LABEL
><B.BODY>As described in the previous sections, you can use ObjectTeam to model windows and controls, then use PowerBuilder to complete the generated window. The benefit of this approach is that, while modeling the application, you remain focused on the functions of the application rather than becoming distracted by the details of the GUI.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Model the window only</L.LABEL
><B.BODY>Alternatively, you can use the following approach:</B.BODY
>To model menus in ObjectTeam, create a class for each menu item. The supertype class of a menu item is the menu class, which is defined in the PBBuiltins system.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Menus can contain other objects</L.LABEL
><B.BODY>In PowerBuilder, a menu is a container object. A menu object can contain menus and menu cascades. A menu cascade can contain menus.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Sample menu</L.LABEL
><B.BODY>Following is a menu similar to one used in the PowerBuilder tutorial:</B.BODY
><B.BODY>All classes are subtypes of the menu class; for simplicity, the subtype&truehy;supertype relationships are not shown.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Global Type property</SL.SUBLABEL
><B.BODY>In PowerBuilder, a menu must be a global object; therefore, the Global Type property of the m_frame class must be set to Yes. Typically, the menu items are local objects; therefore, the Global Type property is set to No for all other classes in the CD.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Aggregations</SL.SUBLABEL
><B.BODY>The aggregations define the menu structure: </B.BODY
>The role names become the PowerBuilder control names.</N.NOTE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Operations</SL.SUBLABEL
><B.BODY>Each menu item has a clicked event. Therefore, each class that represents a menu item, has a clicked() operation with the Event property of the operation selected.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Completing the menu</L.LABEL
><BI.BODY.INTRO>The generated PowerBuilder file contains the menu declarations, but no menu properties. The name of each menu item defaults to its control name. In PowerBuilder, open and edit the menu as follows:</BI.BODY.INTRO
><RBW-PARABODY>For each menu item, add the script for the clicked() event.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Toolbars</L.LABEL
><B.BODY>You do not model toolbars in ObjectTeam. To place a menu item in a toolbar, specify the appropriate menu properties in PowerBuilder. Only MDI applications can have toolbars.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Menu cascades</L.LABEL
><B.BODY>A menu cascade in PowerBuilder is a toolbar icon that has a drop&truehy;down list of other toolbar icons. Only MDI applications can have menu cascades.</B.BODY
><RBW-PARABODY>Change the supertype of the parent menu item from menu to menucascade. (For example, change the supertype of m_open from menu to menucascade.)</RBW-PARABODY
><RBW-PARABODY>In PowerBuilder, make sure that the child menu items have toolbar icons.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>When you run the MDI application, the toolbar contains a menu cascade that contains the icons for the child menu items.</LR.LIST.RESULT
><B.BODY>To model a PowerBuilder window in ObjectTeam, create a class that represents the window and make it a subclass of the window class, which is defined in the PBBuiltins system.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Windows can contain other objects</L.LABEL
><B.BODY>In PowerBuilder, a window is a container object. It can contain menus, structures, standard visual user objects, and custom visual user objects.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class properties</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Global Type</SL.SUBLABEL
><B.BODY>ObjectTeam does not generate code for the window unless it is a global object; therefore, set the Global Type property of the class that represents the window to Yes.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Window Type</SL.SUBLABEL
><B.BODY>The Window Type property of the class that represents the window determines the type of window that is generated: Child, Main (default), MDI, MDIHelp, Popup, or Response.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Aggregations</L.LABEL
><B.BODY>A window can contain other objects. As described in <RBW-XREF REFID="11320" TYPE="XREF-TEXTCOPY">Basic Modeling Technique</RBW-XREF
>, you use aggregations to indicate which objects are contained in a window.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Sample window</L.LABEL
><B.BODY>Following is the main window of the MDI application built in the PowerBuilder tutorial:</B.BODY
><B.BODY>The w_frame window is a global PowerBuilder window of type MDI Frame With Microhelp. Therefore, in the w_frame class, the Global Type property is set to Yes and the Window Type property is set to MDIHelp. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Completing the window</L.LABEL
><B.BODY>To complete the window in PowerBuilder, specify the title of the window by editing the window’s properties.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Inheritance</L.LABEL
><B.BODY>PowerBuilder and ObjectTeam both support inheritance of windows. For an example of how to model inheritance of windows, see <RBW-XREF REFID="28166" TYPE="XREF-TEXTCOPY">Modeling Data Windows</RBW-XREF
>Modeling Standard Visual User Objects</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Standard visual user objects</L.LABEL
><B.BODY>A standard visual user object is a global object that is predefined in PowerBuilder. In ObjectTeam, each stardard visual user object is represented as a class in the PBBuiltins system.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Events on standard visual user objects</L.LABEL
><B.BODY>Each standard visual user object contains a set of predefined events.</B.BODY
><RBW-PARABODY>If you want to redefine a predefined event or add new events, you create a new object based on the standard visual user object.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Modeling standard visual user object</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="standard visual user object"></RBW-IDXTERM
><RBW-IDXTERM TERM1="modeling" TERM2="standard visual user object"></RBW-IDXTERM
>To model a standard visual user object, add the appropriate PBBuiltins class to your CD and use an aggregation to indicate that the window contains the standard visual user object.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Modeling new object based on standard visual user object</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="standard visual user object"></RBW-IDXTERM
><RBW-IDXTERM TERM1="modeling" TERM2="standard visual user object"></RBW-IDXTERM
>To model a new object based on a standard visual user object, create a class that represents the user object and make it a subclass of the appropriate PBBuiltins class. Use an aggregation to indicate that the window contains the new object.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</L.LABEL
><B.BODY>The following CD models a window with three controls: a picture control and two command buttons. For the picture control, the predefined events are sufficient so you can use the standard visual user object picture. For the command buttons, the clicked event must be redefined so you must create new objects: cb_ok and cb_cancel.</B.BODY
><B.BODY>Typically, if you define a new object based on a standard visual user object, the new object is used only within a single window. In this case, the window is a global object and the new object is a local object; therefore, in the class that represents the new object, you generally set the Global Type property to No. In the previous CD, for example, the Global Type property is set to No for both the cb_ok and cb_cancel classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>PBBuiltins classes</L.LABEL
><B.BODY>Following are the valid supertype classes for standard visual user objects:</B.BODY
><B.BODY>The datawindow class represents a data window <CX5FX5FEMPHASIS>control</CX5FX5FEMPHASIS
>. ObjectTeam does not generate data window <CX5FX5FEMPHASIS>objects</CX5FX5FEMPHASIS
>. Use PowerBuilder to create the data window object and to associate the data window object with the generated data window control. See <RBW-XREF REFID="28166" TYPE="XREF-TEXTCOPY">Modeling Data Windows</RBW-XREF
>Modeling Custom Visual User Objects</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introductions</L.LABEL
><B.BODY>Custom visual user objects allow you to group visual user objects. By placing a custom visual user object in a window, you place the entire group of visual user objects in the window.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Userobject class</L.LABEL
><B.BODY>To model a custom visual user object in ObjectTeam, create a class that represents the user object and make it a subclass of the userobject class, which is defined in the PBBuiltins system.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Userobjects can contain other objects</L.LABEL
><B.BODY>In PowerBuilder, a custom visual user object is a container object. It can contain structures, standard visual user objects, and other custom visual user objects.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Class properties</L.LABEL
><B.BODY>A custom visual user object is generally a global object, which allows it to be used on more than one window. Therefore, for a class that represents a custom visual user object, you generally set the Global Type property to Yes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Aggregations</L.LABEL
><B.BODY>A custom visual user object, like a window, can contain other objects. As described in <RBW-XREF REFID="11320" TYPE="XREF-TEXTCOPY">Basic Modeling Technique</RBW-XREF
>, you use aggregations to indicate containment.</B.BODY
> shows the w_welcome window that is built in the PowerBuilder tutorial. The user name and password fields that appear in that window might be useful in a number of different windows.</B.BODY
><B.BODY>The following CDs show how you might model those fields as a custom visual user object and how you would then include that custom visual user object on the w_welcome window.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Sample CD: define the userobject</L.LABEL
><BI.BODY.INTRO>The following CD models a custom visual user object that contains the user name and password fields:</BI.BODY.INTRO
><B.BODY>In PowerBuilder, a control cannot have the same name as a global object. In the CD shown above, for example, if you used a role name of u_loginfields instead of u_login, the PowerBuilder code generator would display the following error:</B.BODY
><EWM.EXAMPLEW.MONO>Name of aggregation “u_loginfields” from class “w_welcome” to class “u_loginfields” results in invalid type name in global class “w_welcome”.</EWM.EXAMPLEW.MONO
><B.BODY>This section uses an example from the PowerBuilder tutorial to show the use of inheritance, data windows, and external objects.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Sample window</L.LABEL
><B.BODY>In the PowerBuilder tutorial, you create two windows, w_customers and w_products, that provide access to the Customer and Product tables in the Powersoft Demo Database. Following is the w_customers window; the w_products window is similar.</B.BODY
> The w_customers and w_products windows are both based on the ancestor window, w_master_detail. The ancestor window defines the data window controls, dw_master and dw_details, that appear in the descendant windows.</RBW-PARABODY
> The data window controls, dw_master and dw_detail, are both based on the data window control u_dwstandard. You do not create u_dwstandard; it is an external object defined in the PowerBuilder library <CX5FX5FFILE.NAME>pbtutor.pbl</CX5FX5FFILE.NAME
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this section</L.LABEL
><B.BODY>This section contains the following topics:</B.BODY
><B.BODY>The w_customers and w_products windows are both based on the w_master_details window. All three windows are global objects; therefore, the Global Type property is set to Yes for all three classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Events</L.LABEL
><B.BODY>The operations specified in the w_master_details class are events; therefore, the Event property is specified for each operation. The events are generated in the source file for the w_master_detail window; they are then available to the descendant windows.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Menu</L.LABEL
><B.BODY>The menu is a global object; therefore, its Global Type property is set to Yes. It is associated with the w_master_detail window, so it is also available to the descendant windows.</B.BODY
>This example assumes that the m_fileopen class is further defined by another CD in the current system. See <RBW-XREF REFID="20826" TYPE="XREF-TEXTCOPY">Modeling Menus</RBW-XREF
> for more information about menus.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Data window controls</L.LABEL
><B.BODY>The data window controls, dw_master and dw_detail, are both local objects; therefore, their Global Type properties are set to No. They are defined in the source file generated for the w_master_detail window; therefore, they also appear in the descendant windows.</B.BODY
><B.BODY>The dw_master and dw_detail data window controls are both based on the u_dwstandard data window control, which is defined in another PowerBuilder library (another ObjectTeam system). See <RBW-XREF REFID="37141" TYPE="XREF-TEXTCOPY">Using External Objects</RBW-XREF
> for more information.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Data window objects</L.LABEL
><B.BODY>In PowerBuilder, a data window <CX5FX5FEMPHASIS>control</CX5FX5FEMPHASIS
> contains a data window <CX5FX5FEMPHASIS>object</CX5FX5FEMPHASIS
>. ObjectTeam does not generate data window <CX5FX5FEMPHASIS>objects</CX5FX5FEMPHASIS
>, therefore, they are not included in the CD.</B.BODY
><B.BODY>After generating the PowerBuilder source files, in PowerBuilder, you create the data window <CX5FX5FEMPHASIS>objects</CX5FX5FEMPHASIS
> and add them to generated data window <CX5FX5FEMPHASIS>controls</CX5FX5FEMPHASIS
>. See <RBW-XREF REFID="19080" TYPE="XREF-TEXTCOPY">Completing the Generated Windows</RBW-XREF
>The term external objects used in this section does not refer to PowerBuilder’s external visual user objects. ObjectTeam does not generate external visual user objects.</N.NOTE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>External objects in PowerBuilder</L.LABEL
><B.BODY>A PowerBuilder library defines a set of objects. An object defined in one PowerBuilder library can reference the objects defined in another PowerBuilder library. </B.BODY
><B.BODY>For example, the dw_master and dw_detail data window controls are defined in the current PowerBuilder library, but they are based on the u_dwstandard data window control defined in the <CX5FX5FFILE.NAME>pbtutor.pbl</CX5FX5FFILE.NAME
> PowerBuilder library.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>External classes in ObjectTeam</L.LABEL
><B.BODY>In ObjectTeam, each system defines a PowerBuilder library. A class defined in the current system represents an object that is defined in the PowerBuilder library. An external class — one that appears in the current system, but is defined another system — represents an object that is defined in another PowerBuilder library.</B.BODY
><B.BODY>For example, the dw_master and dw_detail classes shown in the CD at the beginning of this section (<RBW-XREF REFID="28166" TYPE="XREF-TEXTCOPY">Modeling Data Windows</RBW-XREF
>) are defined in the current system. The u_dwstandard class is defined in another system.</B.BODY
><B.BODY>ObjectTeam does not generate code for external classes. However, the code it generates for the classes defined in the current system can reference external classes. To generate the appropriate references to the external classes, ObjectTeam must know the supertype of the external class; that is, it must know the type of the referenced object.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>External classes must be defined</L.LABEL
><B.BODY>Every external class used in a system, must be defined in another system that is in the same phase as the current system. For PowerBuilder code generation, the only information required for the external class is its supertype. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>The following CD defines the external class u_dwstandard.</B.BODY
><B.BODY>When you import a source file into a PowerBuilder library, PowerBuilder must be able to resolve all references to external objects. The library search path defines the list of libraries that PowerBuilder uses to resolve external objects.</B.BODY
><RBW-PARABODY>In ObjectTeam, the code generator defines the library search path as the list of all PowerBuilder libraries in all subdirectories of the current <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to add libraries to ObjectTeam search path</L.LABEL
><B.BODY>When you create a PowerBuilder library in ObjectTeam, the <CX5FX5FVARIABLE>system</CX5FX5FVARIABLE
>.<CX5FX5FFILE.NAME>pbl</CX5FX5FFILE.NAME
> library appears in the <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
>\<CX5FX5FVARIABLE>system</CX5FX5FVARIABLE
> directory. When you configure the PowerBuilder environment in the Implementation phase, the <CX5FX5FFILE.NAME>classlib.pbl</CX5FX5FFILE.NAME
> library appears in the <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
>\<CX5FX5FFILE.NAME>src</CX5FX5FFILE.NAME
> directory. </B.BODY
><B.BODY>If you want to include additional PowerBuilder libraries in the library search path used by the code generator, copy the PowerBuilder libraries into the <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
>\<CX5FX5FFILE.NAME>src</CX5FX5FFILE.NAME
> directory. For example, to add <CX5FX5FFILE.NAME>pbtutor.pbl</CX5FX5FFILE.NAME
> to the library search path, copy <CX5FX5FFILE.NAME>pbtutor.pbl</CX5FX5FFILE.NAME
> to the <CX5FX5FVARIABLE>user_environment</CX5FX5FVARIABLE
> objects defined in an existing PowerBuilder library makes them available as classes in ObjectTeam. ObjectTeam projects can use the classes to reference the existing objects. In this way, reverse engineering supports reuse of software components.</B.BODY
>Classes created by reverse engineering should not be edited or regenerated from within ObjectTeam. They should only be used as external classes.</N.NOTE
> updates the ObjectTeam model based on the changes you have made to the generated PowerBuilder source files. Use round&truehy;trip engineering to update the ObjectTeam model <CX5FX5FEMPHASIS>before</CX5FX5FEMPHASIS
> you regenerate the source files. If you add variables, functions, controls, or structures to the generated source file, but do not add them to the ObjectTeam model, they are lost when you regenerate the source files.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Explanation</SL.SUBLABEL
><B.BODY>The code generator generates code based on the ObjectTeam model. When you regenerate the source file, only the attributes, operations, and controls defined in the model appear in the generated source file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
>Reverse engineering parses files exported from PowerBuilder (<CX5FX5FFILE.NAME>.pbl</CX5FX5FFILE.NAME
>) libraries and builds CDs and CDMs that model the objects defined in those files. It can be particularly useful if you want to reference existing PowerBuilder objects from within an ObjectTeam project.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose </L.LABEL
><B.BODY>Use reverse engineering to capture and display the objects defined in your PowerBuilder (<CX5FX5FFILE.NAME>.pbl</CX5FX5FFILE.NAME
>) libraries. This serves two primary purposes:</B.BODY
><RBW-PARABODY>Helps you to understand the structure and functionality of the PowerBuilder objects.</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Not an import utility</SL.SUBLABEL
><B.BODY>Reverse engineering is not designed to capture all the information in a PowerBuilder export file. Therefore, do not use reverse engineering to import objects in order to edit and regenerate them from ObjectTeam. If you generate PowerBuilder files from the CDs and CDMs created by reverse engineering, the generated files are <CX5FX5FEMPHASIS>not</CX5FX5FEMPHASIS
> the same as the original files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="19526"></RBW-ANCHOR
>What happens during reverse engineering</L.LABEL
><B.BODY>Reverse engineering uses the following steps to translate PowerBuilder files into CDs and CDMs:</B.BODY
><RBW-PARABODY>Parses the following types of PowerBuilder files, which are exported from PowerBuilder libraries: <CX5FX5FFILE.NAME>.srw</CX5FX5FFILE.NAME
><B.BODY>After parsing the PowerBuilder file, reverse engineering maps the PowerBuilder constructs to ObjectTeam elements, as shown in the following table:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Class with Global Type and Window Type properties set. Class hierarchies and aggregations show the relationships among classes.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Class attribute (name is prefixed with $), data type, and default value (if any). Attribute Access property is set.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Attribute and data type. The Constant attribute property is set and default value of the attribute is set to the value of the constant. Attribute Access property is set.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Operation and parameters. Method Access operation property and Pass By parameter property are set. </CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Operation and parameters. The Event operation property and Pass By parameter property are set.</CELLBODY
> file in the powerbuilder module defines the reverse engineering rules used to detect associations and attribute accessors. You can modify reverse engineering by editing this customization file, as described in the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><BI.BODY.INTRO>After mapping the PowerBuilder constructs to ObjectTeam elements, reverse engineering creates the CDs and CDMs that define the ObjectTeam elements. It creates the following CDs:</BI.BODY.INTRO
>In PowerBuilder, each object type is a class. Therefore, reverse engineering creates a CD for each type of object that shows all objects of that type.</N2.NOTE.2
><RBW-PARABODY>One or more CDs to show the associations among the classes</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Naming conventions for CDs</SL.SUBLABEL
><B.BODY>Each CD is named for the primary class in the CD; for example, Class1. The word Tree is appended to the name of each CD that defines part of the class hierarchy; for example, TestClass1Tree.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How many diagrams are created</L.LABEL
><B.BODY>The number and complexity of the CDs created by reverse engineering depend largely on the following:</B.BODY
><RBW-PARABODY>The files that you select for reverse engineering, particularly the number and complexity of classes defined in the files.</RBW-PARABODY
><RBW-PARABODY>The reverse engineering options that you select, particularly whether you choose to reverse engineer associations.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="22283"></RBW-ANCHOR
>Options for reverse engineering</L.LABEL
><BI.BODY.INTRO>During reverse engineering, ObjectTeam displays the following dialog box prompting you to select the options that you want to use:</BI.BODY.INTRO
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>If selected, reverse engineering creates a separate reference CD for each class that exceeds the maximum size. The class is folded in all diagrams other than the reference diagram.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Max Class Width & Height</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a class. When a class exceeds this size, it is folded.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Max Tree Width & Height</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a class tree. When a class hierarchy exceeds this size, it is split.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Specifies the maximum size of a diagram. When a diagram exceeds this size, it is split.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>If selected, reverse engineering examines the attributes and accessor methods defined on each class to determine the associations among classes. It then creates CDs that show those associations.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>PowerBuilder almost always uses lowercase and ObjectTeam is case sensitive. Use this field to specify which case should be used in ObjectTeam.</CELLBODY
><RBW-PARABODY>FirstCase. For each identifier, use the case that is first encountered. (When reverse engineering multiple files, use this option with caution.)</RBW-PARABODY
><RBW-PARABODY>LowerCase. Always use lowercase characters.</RBW-PARABODY
></CELLBULLET
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>GUI aggregations</SL.SUBLABEL
><B.BODY>Reverse engineering always creates CDs that show the aggregations that define the GUI, even if you have not selected the Reverse Engineer Associations option. How it creates these CDs depends on which Placement Algorithm option you selected in the Reverse Engineer dialog box.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>CDs that show the class hierarchy</L.LABEL
><BI.BODY.INTRO>Following are the guidelines used to draw the CDs that show the class hierarchy:</BI.BODY.INTRO
><RBW-PARABODY>Reverse engineering creates a CD for each top&truehy;level parent class. The CD contains the parent class and all subclasses.</RBW-PARABODY
><RBW-PARABODY>If a class has multiple parent classes, reverse engineering creates a CD for each parent. The CD for the first parent class contains the parent class, the child class, and all subclasses of the child class. The CD for each of the other parent classes contains only the parent class and the child class; in these diagrams, the child class is folded.</RBW-PARABODY
><B.BODY>If you select the Reverse Engineer Associations option in the Reverse Engineer dialog box, reverse engineering creates CDs that show the associations. How it creates these CDs depends on which Placement Algorithm option you selected in the Reverse Engineer dialog box. Both algorithms are described below.</B.BODY
><B.BODY>If you do not select the Reverse Engineer Associations option, reverse engineering shows associations only as attributes and accessor methods in the appropriate classes.</B.BODY
>Bidirectional associations are reverse engineered as two unidirectional associations.</N.NOTE
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>GUI aggregations</SL.SUBLABEL
><B.BODY>Reverse engineering always creates CDs that show the aggregations that define the GUI, even if you have not selected the Reverse Engineer Associations option. How it creates these CDs depends on which Placement Algorithm option you selected in the Reverse Engineer dialog box.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Simple algorithm</L.LABEL
><B.BODY>If you select Simple in the Placement Algorithm field of the Reverse Engineer dialog box, reverse engineering draws the CDs as follows:</B.BODY
><RBW-PARABODY>Divides all classes into groups of <CX5FX5FEMPHASIS>n</CX5FX5FEMPHASIS
>, where <CX5FX5FEMPHASIS>n</CX5FX5FEMPHASIS
> is the number specified by the Number of Classes per CD field of the Reverse Engineer dialog box. The algorithm attempts to group associated classes.</RBW-PARABODY
><RBW-PARABODY>For each group of classes, creates a CD and adds the classes (unfolded) to the CD. To position the classes, reverse engineering uses a uniform grid whose squares are the size of the largest class in the group and its longest association.</RBW-PARABODY
><RBW-PARABODY>For each class in each CD, draws all associations from the class to all associated classes. If an associated class is not in the CD, reverse engineering adds it (folded) to the CD.</RBW-PARABODY
></LN.LIST.NUM
><BI.BODY.INTRO>The following illustration shows a CD created by the grid algorithm. (The classes in the illustration have been rearranged slightly to fit more easily on the page.)</BI.BODY.INTRO
>Reverse engineering creates CDs and CDMs based on the files that you select. Therefore, you generally want to reverse engineer all related files at the same time.</T2.TIP.2
><RBW-PARABODY>Select the files that you want to reverse engineer, then select Open.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>A second Reverse Engineer PowerBuilder dialog box appears (see <RBW-XREF REFID="22283" TYPE="XREF-TEXTCOPY">Options for reverse engineering</RBW-XREF
>), prompting you to select the options that you want to use. </LR.LIST.RESULT
><B.BODY>Round&truehy;trip engineering updates the ObjectTeam model based on the changes you have made to the generated PowerBuilder source files. Use round&truehy;trip engineering to update the ObjectTeam model <CX5FX5FEMPHASIS>before</CX5FX5FEMPHASIS
> you regenerate the source files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose</L.LABEL
><B.BODY>The code generator generates code based on the ObjectTeam model. If you do not update the ObjectTeam model before regenerating the source files, the new source files do not include your changes. </B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Example</SL.SUBLABEL
><B.BODY>You generate PowerBuilder files. You then edit the generated source file, adding a new function. If you do not update the ObjectTeam model, the model does not contain the operation that corresponds to the function. When you regenerate the source file, the code generator assumes that you <CX5FX5FEMPHASIS>deleted</CX5FX5FEMPHASIS
> the operation from ObjectTeam and, therefore, does not include the <CX5FX5FEMPHASIS>obsolete</CX5FX5FEMPHASIS
> function in the newly generated source file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes captured by round&truehy;trip engineering</L.LABEL
><B.BODY>If you have made the following types of changes to the generated PowerBuilder source, round&truehy;trip engineering updates the ObjectTeam model based on those changes:</B.BODY
><RBW-PARABODY>Added structures to an object, such as a window or custom class object</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes not captured by round&truehy;trip engineering</L.LABEL
><B.BODY>Round&truehy;trip engineering ignores the following types of changes that you might have made to the generated source files. If you have made these types of changes, you must update the ObjectTeam model manually:</B.BODY
><RBW-PARABODY>Deleted structures from an object</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Round&truehy;trip engineering and events</L.LABEL
><B.BODY>Adding events in Powerbuilder is not discouraged, since the code attached to an event may get lost during a roundtrip action in ObjectTeam. </B.BODY
><B.BODY>The preferred way to add events is to add them in ObjectTeam, and regenerate the code. Next, you can attach code to the event in Powerbuilder, without running the risk of losing code during a roundtrip action.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>What happens during round&truehy;trip engineering</L.LABEL
><B.BODY>The following table shows the steps that occur during round&truehy;trip engineering:</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>You select the generated (edited) source files that you are interested in and start round&truehy;trip engineering.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>ObjectTeam parses the selected files and compares the information in the files with the information in the ObjectTeam model.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>For each difference it finds, ObjectTeam proposes an action and prompts you for confirmation. For example:</CELLBODY
><CELLBODY><CX5FX5FINPUT>In class “Account”: delete attribute “Address”?</CX5FX5FINPUT
>Parsing the Generated (Edited) Source Files</SS.SUBSEC.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>This section describes which changes to the generated source files are captured by round&truehy;trip engineering. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes to attributes</L.LABEL
><B.BODY>You can add, delete, and modify shared or instance variables. In PowerBuilder, when you edit the variables in a generated file, you see the following comments:</B.BODY
><RBW-PARABODY>// User defined attributes</RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>Round&truehy;trip engineering updates the ObjectTeam model based on the variable declarations that appear under this comment. Typically, these are the variable declarations that you edit.</LT.LIST.TEXT
><RBW-PARABODY>// Non modeled user defined attributes</RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>Round&truehy;trip engineering ignores variable declarations that appear under this comment. However, the code generator preserves these variables when you regenerate the source files. These are variables, such as SQL cursors, that you want to use in PowerBuilder, but do not want to model in ObjectTeam.</LT.LIST.TEXT
><RBW-PARABODY>// Association attributes</RBW-PARABODY
></LB.LIST.BULLET
><LT.LIST.TEXT>This comment appears only for instance variables. It lists the variables that ObjectTeam uses to implement associations. Round&truehy;trip engineering ignores these variable declarations and the code generator generates them based on the associations defined in the ObjectTeam model. Therefore, changes that you make to these variable declarations are not preserved.</LT.LIST.TEXT
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attribute Access property</SL.SUBLABEL
><B.BODY>The Attribute Access property of an attribute is based on the access keyword in the attribute declaration. If you do not specify an access keyword, the Read and Write fields of the Attribute Access property are set to Public.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="34671"></RBW-ANCHOR
>Changes to functions </L.LABEL
><BI.BODY.INTRO>You can add and delete functions. </BI.BODY.INTRO
><B.BODY>You can modify function declarations by adding, removing, or reordering parameters, changing default values, changing the return type, or changing the access method (public, protected, private). </B.BODY
><B.BODY>You can change the code in the body of any function. Such changes are ignored by round&truehy;trip engineering, but are preserved by the code generator when you regenerate the source files.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Overloaded functions</SL.SUBLABEL
><B.BODY>If you have multiple functions with the same name, do not delete one and change the declaration of another at the same time. Delete one, run round&truehy;trip engineering, change the declaration of the other, and run round&truehy;trip engineering. This approach prevents potential errors in round&truehy;trip engineering.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes to events</L.LABEL
><B.BODY>You can modify event declarations by adding, removing, or reordering parameters, changing default values, or changing the return type.</B.BODY
><B.BODY>You can change the code in the body of any event. Such changes are ignored by round&truehy;trip engineering, but are preserved by the code generator when you regenerate the source files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes to controls and structures</L.LABEL
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes to controls</SL.SUBLABEL
><B.BODY>You can add controls to a generated window. However, <CX5FX5FEMPHASIS>if you delete a control, you must edit the ObjectTeam</CX5FX5FEMPHASIS
><CX5FX5FEMPHASIS> model manually</CX5FX5FEMPHASIS
>. In ObjectTeam, controls are modeled as classes and round&truehy;trip engineering does not delete classes from the ObjectTeam model.</B.BODY
><B.BODY>If you add controls to a generated window, round&truehy;trip engineering updates the ObjectTeam model. Round&truehy;trip engineering does not modify existing CDs. It creates the following CDs to hold the classes that represent the new controls:</B.BODY
><RBW-PARABODY>A CD for each modified window; these CDs show the associations between the new controls and their windows</RBW-PARABODY
></LB.LIST.BULLET
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Changes to structures</SL.SUBLABEL
><B.BODY>You can add structures to a generated window or class. Adding a structure to a window or class is similar to adding a control to a window.</B.BODY
> in the <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
>/etc directory controls what actions round&truehy;trip engineering proposes, as well as the default answers it supplies. To examine or modify the current behavior of round&truehy;trip engineering, examine or modify the customization file.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>How to run round&truehy;trip engineering</L.LABEL
><RBW-PARABODY>Optionally, enter a prefix to be used in naming any CDs created by round&truehy;trip engineering, then select OK. If you do not enter a prefix, round&truehy;trip engineering uses the prefix <CX5FX5FINPUT>NewRT</CX5FX5FINPUT
>.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>ObjectTeam opens the Roundtrip Selected Files dialog box, compares the classes in the PowerBuilder files to the classes in the Object Design phase, and then begins proposing actions and prompting you for confirmation.</LR.LIST.RESULT
><RBW-TEXTFLD TYPE="text">Code Generation Guide for PowerBuilder</RBW-TEXTFLD
></RBW-SYSOBJ
></C.CHAPTER.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Expert users can extend the PowerBuilder code generator by modifying the Tcl scripts that are supplied in the <CX5FX5FVARIABLE>M4_home</CX5FX5FVARIABLE
>\<CX5FX5FFILE.NAME>tcl</CX5FX5FFILE.NAME
>\<CX5FX5FFILE.NAME>l_pb</CX5FX5FFILE.NAME
> directory. </B.BODY
><B.BODY>Editing these Tcl scripts, or writing new ones that add functionality to the code generator, requires a thorough knowledge of the OOPL model structure, Tcl commands, and the ObjectTeam Shell.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Modifying Tcl procedures</L.LABEL
><B.BODY>You can adapt existing methods of Object Tcl classes that are used in the code generation by redefining them in a user&truehy;defined Tcl file.</B.BODY
>Cayenne Software cannot support any provided Tcl scripts that you modify. Therefore, the scripts and their structures are not documented. If you choose to modify any Tcl scripts or procedures, you must have a thorough knowledge of the script’s structures to avoid introducing errors. </W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="22291" TYPE="XREF-TEXTCOPY">How Tcl is Used in the Code Generation&rbwtab;6–18</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="15580" TYPE="XREF-TEXTCOPY">Customizing Tcl Scripts Used for Code Generation&rbwtab;6–21</RBW-XREF
><B.BODY>This chapter provides information on the use of Tcl (Tool command language) in ObjectTeam. It does not provide an introduction to Tcl itself. If you want to become familiar with Tcl, try the following introductory book:</B.BODY
><LT.LIST.TEXT>John K. Ousterhout, <CX5FX5FTITLE>Tcl and the Tk Toolkit</CX5FX5FTITLE
><B.BODY>Tcl (Tool command language) is an interpretive command language that resembles C. By default all arguments are passed as strings. These strings are C&truehy;compatible. Tcl consists of:</B.BODY
><B.BODY>The Tcl core is a simple language that can be completely programmed. It provides a collection of commonly used features such as these:</B.BODY
><BI.BODY.INTRO>When the ObjectTeam shell executes a Tcl script file, it translates information from the repository, internal models, and <RBW-IDXTERM TERM1="code generation model" TERM2="and Tcl"></RBW-IDXTERM
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Refer to general Tcl documentation for details.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Calls to Tcl </CELLBODY
><CELLBODY>procedures</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>These procedures are stored in Tcl files. They become available when the file in which the procedure is defined is sourced.</CELLBODY
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><CELLBODY>Calls to methods of classes</CELLBODY
><CELLBODY>in the <RBWAUTO-0024>ObjectTeam</RBWAUTO-0024
><RBWAUTO-0024></RBWAUTO-0024
> </CELLBODY
><CELLBODY>models</CELLBODY
></ENTRY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>The classes of the ObjectTeam models (including the OOPL model and SQL model) are documented in <CX5FX5FTITLE>ObjectTeam Repository Interface Guide</CX5FX5FTITLE
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Besides methods of classes belonging to the <RBWAUTO-0024>ObjectTeam</RBWAUTO-0024
><RBWAUTO-0024></RBWAUTO-0024
> models, methods belonging to other built&truehy;in classes can also be called. Refer to the <CX5FX5FTITLE>ObjectTeam Repository Interface Guide</CX5FX5FTITLE
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>These commands are built&truehy;in to otsh and otk. You can use these commands, but you cannot edit or view them like Tcl procedures. Refer to the <CX5FX5FTITLE>ObjectTeam Repository Interface Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for details. </CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="35220"></RBW-ANCHOR
>Which Tcl files are used?</L.LABEL
><B.BODY>Tcl procedures used for code generation are stored in Object Tcl script files. During code generation, these scripts are interpreted and executed by the ObjectTeam shell (otsh). When you use Utilities | Import From Previous Phase in the Browser at the system level of the Implementation phase, otsh interprets the Object Tcl code in the Tcl file tcl\l_pb\pbimporter.tcl. In the implementation of these methods, Tcl methods from other classes are called.</B.BODY
><B.BODY>Most of the Tcl script files that the code generator uses are located under the <CX5FX5FTERM>M4_home</CX5FX5FTERM
> directory in tcl\l_pb\*.tcl. The Tcl script files fstorage.tcl and caynutil.tcl in the tcl directory contain utility procedures that are also used.</B.BODY
>Customizing Tcl Scripts Used for <RBW-IDXTERM TERM1="code generation" TERM2="adapting"></RBW-IDXTERM
>Code Generation</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>User&truehy;defined Tcl files</L.LABEL
><B.BODY>Because of the open character of Tcl, you can redefine the existing Object Tcl methods of the Tcl scripts, if you want to adapt the code generation to your needs and circumstances. You can include your own properties, control flow keywords, and section keywords in the code generation this way. You can even build your own code generator by creating your own Tcl scripts. </B.BODY
>Note that existing Object Tcl classes cannot be redefined. However, you can add new, user&truehy;defined Object Tcl classes.</W.WARNING
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-ANCHOR ID="37212"></RBW-ANCHOR
>Where to store user&truehy;defined Tcl procedures</L.LABEL
><B.BODY>The Tcl script files used for the default code generation are stored in the file system. They can be found in the following directory:</B.BODY
><B.BODY>If you want to adapt the default code generation, you can edit the Tcl files in this directory, but it is better to modify copies of the original files. There are several ways available to make otsh use user&truehy;defined files. These ways are briefly discussed in this section. </B.BODY
><B.BODY>You can overrule existing Tcl files or you can extend them by creating new Tcl files with new user&truehy;defined Tcl procedures and methods, or redefinitions of existing methods. The ways to do that are also covered in this section.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Storing Tcl files in the same System as where the code is generated</L.LABEL
><B.BODY>One of the available file types on the system level of the Implementation phase is Tcl. You can create new files of this type and redefine methods of existing Object Tcl classes in such a file. During code generation, otsh sources all files of the type Tcl in the current system, regardless of their names.</B.BODY
><RBW-PARABODY>Select Tcl as the file type, specify a name for the Tcl file (without the extension .tcl), and click OK.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>You can enter the name of an existing Tcl file used for code generation or any other name. If you enter an existing name, the original Tcl file is replaced by this new file during code generation.</LT.LIST.TEXT
><RBW-PARABODY>Edit and save the new Tcl file.</RBW-PARABODY
></LN.LIST.NUM
><LR.LIST.RESULT>The next time you generate code (by using Utilities | Import From Previous Phase) the new Tcl file is sourced by otsh.</LR.LIST.RESULT
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Storing Tcl files in a system Tcl</L.LABEL
><B.BODY>If you do not want to store user&truehy;defined Tcl files in the same system in which your code is generated, you can create a system called Tcl and store your user&truehy;defined Tcl files in there. Any Tcl file that is defined in such a system is sourced during code generation. You can use this mechanism for user&truehy;defined Tcl files or for user&truehy;defined Tcl files that are meant to replace existing ones.</B.BODY
><RBW-PARABODY>Select Tcl as the file type, specify a name for the Tcl file (without the extension <CX5FX5FFILE.NAME>.tcl</CX5FX5FFILE.NAME
>), and click OK.</RBW-PARABODY
></LN.LIST.NUM
><LT.LIST.TEXT>You can enter the name of an existing Tcl file used for code generation or any other name. If you enter an existing name, the original Tcl file is replaced by this new file during code generation.</LT.LIST.TEXT
><B.BODY>If you want to test a customized Tcl file before you add it to a system in ObjectTeam, you can create the Tcl file in your file system and feed it to otsh outside the ObjectTeam environment. </B.BODY
><B.BODY>See the <CX5FX5FTITLE>ObjectTeam Customization Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for details on how to start otsh from the command line.</B.BODY
><B.BODY>When the Tcl file has reached its final state, you can decide to add it to a system in ObjectTeam, as described above. </B.BODY
><RBW-TEXTFLD TYPE="text">Code Generation Guide for PowerBuilder</RBW-TEXTFLD
></RBW-SYSOBJ
></A.APPENDIX.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>PowerBuilder code generation properties</L.LABEL
><B.BODY>The following table lists the properties that effect PowerBuilder code generation. These are available in the CD in the Object Design phase.</B.BODY
> contains information specific to the Smalltalk programming language. This includes information for setting up, configuring, and specifying code generation details in CDs that you will use to generate Smalltalk code. Refer to the <CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for general information about the code generation process.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Prerequisites</L.LABEL
><B.BODY>This guide is intended for experienced users of ObjectTeam and the analysis and design method it supports. This guide gives you information on how to map ObjectTeam diagrams to Smalltalk code; it does not teach you how to use Smalltalk.</B.BODY
><B.BODY>To customize or extend the capabilities of the Smalltalk code generator, you must have a thorough understanding of the ObjectTeam Shell, the Object&truehy;Oriented Programming Language (OOPL) model structure, and the Tool Command Language (Tcl) commands.</B.BODY
> provides the menu items, the properties and the Tcl code required to use the Smalltalk Code Generator. Therefore, before moving to the Object Design phase, make sure this module is active.</B.BODY
><B.BODY>You can check if a module is active on a particular Browser level by selecting Utilities | Show Active Modules on that level.</B.BODY
> for details on how to activate a module.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Object Design and Implementation</L.LABEL
><B.BODY>This chapter describes the tasks of the Object Design phase. <RBW-XREF REFID="28728" TYPE="XREF-TEXTCOPY">Chapter 2, Generating Code</RBW-XREF
>, describes the tasks of the Implementation phase. You work iteratively in these two phases to generate code and complete your application.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Purpose of object design</L.LABEL
><B.BODY><RBW-IDXTERM TERM1="Object Design" TERM2="activities in this phase"></RBW-IDXTERM
><RBW-IDXTERM TERM1="Object Design" TERM2="development phase in ObjectTeam project"></RBW-IDXTERM
>In ObjectTeam, the CDs (and the objects defined in the CDs) provide all the source data needed for code generation. The goal of object design is to add to the CDs all the data required for successful code generation. For example, you add properties (such as the Attribute Access property, which establishes read/write access to an attribute) and incorporate language&truehy;specific syntax (such as data type specifications for attributes and the arguments of operations).</B.BODY
><B.BODY>You might also add data to diagrams other than CDs. The code generator does not use oter diagrams, but they are useful for describing the behavior of classes, their attributes and operations.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>In this chapter</L.LABEL
><B.BODY>This chapter contains the following sections:</B.BODY
><TBODY><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="13501" TYPE="XREF-TEXTCOPY">Refining the Class Diagrams&rbwtab;1–3</RBW-XREF
></SB.SECTION.BLOCK.TABLE
></ENTRY
></RBW-ROW
><RBW-ROW><ENTRY COLNAME="1" VALIGN="TOP" MOREROWS="0"><SB.SECTION.BLOCK.TABLE><RBW-XREF REFID="35686" TYPE="XREF-TEXTCOPY">Hints and Tips for Effective Code Generation&rbwtab;1–6</RBW-XREF
>Introduction<RBW-IDXTERM TERM1="Class Association Diagram"></RBW-IDXTERM
></L.LABEL
><B.BODY>The CDs and the objects defined in the CDs provide all the source data needed for code generation. <RBW-IDXTERM TERM1="Class Association Model"></RBW-IDXTERM
>These diagrams distinguish the classes in a system and describe their identities and their features. In the Object Design phase, you must add to the CDs sufficient detail for successful code generation.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using data from diagrams other than CDs</L.LABEL
><B.BODY>Diagrams other than the CDs are not used as input for code generation. However, they contain valuable information that can help you to complete and verify the CDs. The following table summarizes how you can use these other diagrams to help you find important objects that are not yet in the CDs.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>STD state names (enumerated list as an attribute value)</CELLBODY
><CELLBODY>STD condition on an event</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Classes</L.LABEL
><B.BODY>When you work on CDs, you focus on the implementation of classes. The CD must include all classes and the associations (and inheritance) between classes. In the Object Design phase, you may introduce new classes to ease implementation and improve performance.</B.BODY
><B.BODY>You must include all attributes and operations for each class. The attributes of a class map to the attributes of the class type. The operations of the class map to functions and procedures of the class type. </B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>External classes</L.LABEL
><B.BODY>A class must have at least one attribute or one operation to generate code. Classes that have no attributes or operations are translated as external classes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Associations</L.LABEL
><B.BODY>You must define the associations between all classes, including any constraints.</B.BODY
><B.BODY>Role names must also be defined. Every association needs at least one role name. Every mandatory association must have a role name. Without a role name, you cannot use the association.</B.BODY
><SL.SUBLABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Role names in Analysis and System Design</SL.SUBLABEL
><B.BODY>In the Analysis and System Design phases, role names distinguish a class by showing the role the class is playing in a relationship with another class. Each role name defines the role of the class within the context of a single association. It also indicates the use and direction of the association toward the class that plays a role. For example, a manager can be both the boss of a coworker and an employee of a company.</B.BODY
>Role names in Object Design and Implementation</SL.SUBLABEL
><BI.BODY.INTRO>In the Object Design and Implementation phases, the use of role names is extended. The code generator creates access methods for an association if the class at the far end has a role name for the association. In the previous example, the code generated for Coworker includes access methods for Manager; the code generated for Manager does not include access methods for Coworker.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Attributes</L.LABEL
><B.BODY>You must specify each attribute completely, including its data type. (See <RBW-XREF REFID="11934" TYPE="XREF-TEXTCOPY">Data Attributes</RBW-XREF
> for attribute syntax.)The way to specify a data type for an attribute is to include the type in the class symbol, for example:</B.BODY
><B.BODY>Data types of attributes and arguments can be standard ObjectTeam types, standard types for your target language, or class types and derived types. Types are abstracted from the data types recognized by the OOPL environment. The code generator translates the standard types to the target types. </B.BODY
><B.BODY>Take care when customizing the files that define standard types. Any additions you make must conform to the target language or the generated code may not be usable. For details on customizing the standard types, see <RBW-XREF REFID="24015" TYPE="XREF-TEXTCOPY">Customizing Data Types</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Operations</L.LABEL
><BI.BODY.INTRO>You must specify each operation completely. This includes specifying such aspects as:</BI.BODY.INTRO
><RBW-PARABODY>Any parameters, as well as their data types</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Properties</L.LABEL
><BI.BODY.INTRO><RBW-IDXTERM TERM1="property" TERM2="using - to specify implementation details"></RBW-IDXTERM
>In the Object Design phase, a variety of properties allow you to specify many implementation details. <RBW-IDXTERM TERM1="property" TERM2="using - to specify implementation details"></RBW-IDXTERM
>These details are incorporated in the final code.</BI.BODY.INTRO
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Checking</L.LABEL
><B.BODY>The last activity in object design is to use Check | Global Model to check the CDs. The CDs must be error&truehy;free before they can be used for code generation. See the <CX5FX5FTITLE>ObjectTeam Modeling Guide</CX5FX5FTITLE
><CX5FX5FTITLE></CX5FX5FTITLE
> for more information about the Check utility.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>For more information</L.LABEL
><B.BODY><RBW-XREF REFID="17827" TYPE="XREF-TEXTCOPY">Chapter 3, Mapping Modeling Data to Smalltalk</RBW-XREF
>, describes how the ObjectTeam model is translated into code. You can use this information to help you complete the CDs in the Object Design phase.</B.BODY
>Hints and Tips for Effective Code Generation</S.SECTION.HEAD
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Introduction</L.LABEL
><B.BODY>Following are a few tips for effective code generation. It may be helpful to be aware of these items as you prepare for code generation, and then again as you generate and regenerate your source files.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Understanding the translations</L.LABEL
><B.BODY>Before generating code, read through this guide. It contains detailed information about the data that you must include in your CDs for successful code generation. It also explains how the code generator translates the ObjectTeam model into source code files, what changes you can make to the source code files, and how to regenerate them without losing your changes.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Naming conventions</L.LABEL
><B.BODY>Agree upon and follow a naming convention for projects, configurations, systems, classes, special characters, and so on. In addition, bear in mind that spaces between words (in class names, for instance) are deleted by ObjectTeam code generators.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Customizing code generation</L.LABEL
><B.BODY>The code generators execute Tcl scripts that translate a model into source code. You can modify these scripts or create your own.. Always use caution when customizing or creating scripts; such scripts are not supported.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Using multiple languages in a single application</L.LABEL
><B.BODY>Each ObjectTeam code generator is designed to generate code for one language. You can create an application that uses multiple languages by using different code generators to generate code for different systems; however, the generated code is not integrated across systems. </B.BODY
><B.BODY>The ObjectTeam code generators are not designed to provide language integration. To build an application that uses multiple languages, you must do the following: </B.BODY
>When you create a separate ObjectTeam system for each language&truehy;specific subsystem, be sure to define your classes in the appropriate system. When ObjectTeam generates code for the current system, it generates code for the classes that are defined in that system. It does not generate code for classes referenced, but not defined in, the current system; such classes are treated as external classes.</N.NOTE
>Typically, the ultimate goal of modeling an application is to produce code that implements the application. In ObjectTeam, you can generate a significant portion of the code automatically, then complete the code by adding the details that not specified in the model.</B.BODY
><RBW-PARABODY>Only the CDs (and the objects defined in the CDs) are used for code generation. Therefore, before code generation, it is critical that the CDs be fully defined, as described in <RBW-XREF REFID="37544" TYPE="XREF-TEXTCOPY">Chapter 1, Preparing Your ObjectTeam Model for Code Generation</RBW-XREF
>.</RBW-PARABODY
></LB.LIST.BULLET
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Steps in code generation</L.LABEL
><B.BODY>The following table provides an overview of the code generation process. This chapter describes each step in greater detail.</B.BODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Generate Smalltalk files. During this step, ObjectTeam creates Smalltalk files at System level in the Implementation phase.s</CELLBODY
> System level in the Implementation phase is fundamentally different than System level in other phases. The System files in the Implementation phase are source files, not diagram files.</CELLBODY
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>Edit the source files in either ObjectTeam or VisualWorks. ObjectTeam generates a large portion of your application code, but not all of it. In this stage, you finish writing the application code.</CELLBODY
><CELLBODY>Changes you make to the source files are not lost. When you regenerate the source files, the code generator recognizes your changes and transfers them to the newly generated files.<RBWAUTO-0004><RBW-IDXTERM TERM1="code regeneration"></RBW-IDXTERM
><ENTRY COLNAME="2" VALIGN="TOP" MOREROWS="0"><CELLBODY>If you have not done so already, import the classes into the VisualWorks environment and test the application. If necessary: correct the source files, the model, or both; regenerate the Smalltalk files; and return to step 4.</CELLBODY
></ENTRY
></RBW-ROW
></TBODY
></TGROUP
></RBW-TABLE
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
>Illustration of code generation</L.LABEL
><BI.BODY.INTRO>The following illustration shows how ObjectTeam generates code, including the names of the Tcl scripts that it uses. The CDs and CDMs shown at the top are in the Object Design phase.</BI.BODY.INTRO
><B.BODY>The scripts written for code generation retrieve information from the code generation models, format this information and write the results to source code files. Code generation models are built from the CDs in the Object Design phase.</B.BODY
><RBW-PARABODY>Changes that you make to the generated files are preserved when you regenerate the files.</RBW-PARABODY
></LB.LIST.BULLET
><B.BODY>For more information, see <RBW-XREF REFID="12958" TYPE="XREF-TEXTCOPY">Regenerating Code</RBW-XREF
>.</B.BODY
></LABEL
><LABEL><L.LABEL><RBW-AUTOGEN></RBW-AUTOGEN
><RBW-IDXTERM TERM1="class library" TERM2="including in code generation"></RBW-IDXTERM
>Class library integration</L.LABEL
><B.BODY>You can include external class libraries in your design. Such an external class library is automatically included during the code generation. In addition, ObjectTeam helps you to understand and reuse existing class libraries through reverse engineering.</B.BODY
><B.BODY>For more information, see <RBW-XREF REFID="32714" TYPE="XREF-TEXTCOPY">Chapter 4, Reverse Engineering</RBW-XREF