BridgePoint - Tool Guide

BridgePoint® - Tool Guide

Release 3.3 to 4.0

BridgePoint® Customer Support

http://www.projtech.com/support/bpcsa.html

User ID Password

Tel: 800-482-3853 or 520-544-0808email: [email protected]

Tool Guide

ii

Use, examination, reproduction, copying, transfer, and/or disclosure of“BridgePoint® - Tool Guide”

to others is prohibited except by express agreement withProject Technology, Inc.

Copyright 1992-1999Project Technology, Inc. and its licensors.

7400 N. Oracle Road, Suite 365 Tucson, AZ 85704-6342 USAAll rights reserved.

The Database Management portion of this product is based on:ObjectStore®

Copyright Object Design, Inc. 1988-1998All rights reserved. Patent Pending.

The License Management portion of this product is based on:Elan License Manager

Copyright Rainbow Technologies, Inc. 1998All rights reserved.

All other products or services mentioned in this document are identified by the trademarks, service marks, or product names as designated by the companies who market those products.

RESTRICTED RIGHTS LEGENDUse, duplication, or disclosure by the Government is subject to restrictions as set forth in

subparagraphs (c)(1)(ii) of theRights in Technical Data and Computer Software

clause at 252.227-7013 (48 CFR, Ch.2).Contractors/manufacturers are

Project Technology, Inc., 7400 N. Oracle Rd., Ste. 365, Tucson, AZ 85704-6342 USAObject Design, Inc., 25 Burlington Mall Road, Burlington, MA 01803 USA

Rainbow Technologies, Inc. USA

Version 4.0-1.3

Documentation Roadmap

he p is s n ethod

step.

ues. t”,

tion

The BridgePoint products are documented in three manuals. An overview of the three manuals is presented below.

BridgePoint - OOAThis manual focuses on the OOA process and divides the process into two tasks and six steps. The first task, “Partition Problem”, is addressed in two steps. Tsecond task, “Object Oriented Analysis”, is addressed in four steps. Each steseparated into three sections: Process, Method and Automation. The Processection addresses analyst responsibility for the step, length of time involved iusing the step, effects of the step, and quality issues in using the step. The Msection addresses the underlying method issues for the step. The Automationsection describes how the BridgePoint tool set is used to automate the OOA

BridgePoint - AutomationThis manual focuses on file generation through Design by Translation techniqIt is divided into two tasks and four steps. The first task, “Architecture Blueprinaddresses the method only. The second task, “Software Architecture Implementation”, addresses both method and automation. Design by Translatechniques utilize the BridgePoint Generator tools.

iv Documentation Roadmap

BridgePoint - Tool GuideThis manual is BridgePoint tool specific. Included in the topics addressed are: Tool Fundamentals, User Specific Properties, General Model Editing, Printing, Version Management, License Management, Importing and Exporting Data, and BridgePoint Installation.

Table of Contents

Documentation Roadmap iii

CHAPTER 1:Introduction 1 1.1 Tool Architecture 1

1.2 Installation 2

1.3 Databases 2

CHAPTER 2:Fundamentals 3 2.1 Window Overview 3

2.2 Invoking BridgePoint Model Builder 4

2.3 BridgePoint Model Builder Index Window 5

2.4 File Operations 6

vi Table of Contents

2.5 OOA Database Operations 7

2.5.1 Open Domain OOA 7

2.5.2 Database/Domain Creation 7

2.5.3 Print Setup 9

2.5.4 About 10

2.6 Preferences 10

2.6.1 User Preferences 11

2.6.2 Project Preferences 17

2.7 Model Selection 19

2.8 Versioning 20

2.9 Model Editing 20

2.9.1 Glyphs 21

2.9.2 Model Editing Windows 21

2.10 Data Editor Constraints 26

2.11 Data Editor Acceleration Keys 27

2.12 Description Editor 28

2.12.1 Description Editor Menus 28

2.12.2 Description Editor Acceleration Keys 28

CHAPTER 3:Model Editing 293.1 Screen Size 29

3.2 Snap Grid 30

3.2.1 Turn Snap Grid Lines On/Off Automatically 30

3.2.2 Adjust Snap Grid 31

3.3 Zoom 31

3.4 Drawing Procedures 31

3.4.1 Drawing Shapes 32

3.4.2 Drawing Connectors 32

Table of Contents vii

3.5 Selecting 33

3.5.1 Selecting Multiple Elements 34

3.6 Moving 34

3.6.1 Moving Selected Elements 34

3.6.2 Moving Unselected Elements 35

3.7 Cutting Graphical Elements 35

3.8 Resizing Shapes 36

3.9 Resizing Connectors 36

3.9.1 Adding Points 37

3.9.2 Deleting Points 37

3.10 Working With Text 38

CHAPTER 4:Printing 41 4.1 Printing from the Index Window 41

4.2 Printing from the Model Editors 42

4.3 Printing with the Project Notebook 42

CHAPTER 5:Version Management 43 5.1 Typical Use Scenario 44

5.2 Version Management Concepts 48

5.2.1 Configurations and Configuration Versions 48

5.2.2 Domain Configurations 50

5.2.3 OOA & OOA Versions 53

5.2.4 OOA of ’Version Management’ 54

5.3 Domain Repository 63

5.3.1 Domain Repository Visibility from Model Builder63

5.3.2 Domain Repository Content 64

viii Table of Contents

5.3.3 Default Domain Repository 65

5.3.4 Custom Domain Repository 67

5.4 OOA Databases (x.ooa) 68

5.4.1 OOA Database Access 68

5.4.2 OOA Database Operations 69

5.4.3 Configuration Version Operations 71

5.4.4 OOA Version Operations 77

CHAPTER 6:License Management 816.1 Available Commands 81

6.2 Resource File 83

CHAPTER 7:Exchanging Data 85 7.1 CDIF Import 85

7.1.1 CDIF Import of Entity Relationship Diagrams 86

7.1.2 CDIF Import of State Transition Diagram 88

7.2 SQL Export and Import of BridgePoint OOA of OOA 88

7.2.1 Exporting a Backup File 89

7.2.2 Exporting an SQL File 90

7.2.3 Importing a Backup File 90

7.2.4 Importing an SQL File 91

7.3 Importing old BridgePoint .ooa files 92

APPENDIX A:Solaris 2.x Platform Guide 93A.1 Installation Requirements for Solaris 2 94

A.1.1 Pre-Installation 95

A.2 First Time Installation Procedure for Solaris 2 95

Table of Contents ix

A.2.1 Loading BridgePoint Files 96

A.2.2 Performing Installation Step On the Server 97

A.2.3 Performing Installation Step On Each Client 100

A.2.4 Providing Access To The User Community 101

A.2.5 Modifications To The Server Boot Sequence 102

A.3 Upgrade Installation 103

A.3.1 Preparation for Upgrade Process 103

A.3.2 Upgrade Process 103

A.3.3 Providing Access To The User Community 104

A.3.4 Modifications To The Server Boot Sequence 105

APPENDIX B: HPUX Platform Guide 107B.1 Installation Requirements for HP 108

B.1.1 Pre-Installation 109

B.2 Installation Procedure for HP 111

B.2.1 Loading BridgePoint Files 111

B.2.2 Performing Installation Step On the Server 112

B.2.3 Performing Installation Step On Each Client 115

B.2.4 Providing Access To The User Community 116

B.2.5 Modifications To The Server Boot Sequence 117

B.3 Upgrade Installation 118

B.3.1 Preparation for Upgrade Process 118

B.3.2 Upgrade Process 118

B.3.3 Providing Access To The User Community 119

B.3.4 Modifications To The Server Boot Sequence 120

APPENDIX C:Customizing the Domain Repository 121C.1 Domain Repository Files 122

x Table of Contents

C.2 Domain Repository Commands 122

CHAPTER 1:

Introduction

t’s

1.1 Tool ArchitectureBridgePoint makes use of client/server capabilities through three specific client/server relationships:

• BridgePoint License Server - There is only one instance of the BridgePoint License manager for an installation, regardless of how many clients or platforms are at the installation.

• BridgePoint Database Server - The BridgePoint Model Builder (.ooa), BridgePoint Model Verifier (.sim), and BridgePoint Generator (.gen) databases must physically reside on a BridgePoint Database Server. All OOA work products for a specific problem domain are stored in the Domain OOA database (.ooa), which exists as a UNIX file. All verification data is stored in a SIM (.sim) database. There may be many BridgePoint Database Servers at an installation.

• BridgePoint File Server - Each hardware platform requires a separate software load. Each client workstation must have the $PATH set to the network location containing the BridgePoint executables for the clienplatform.

2 Introduction

ase

1.2 Installation

The typical installation for a product evaluation consists of all three servers as the same workstation in a platform homogeneous network. More complex users may have multiple platforms and, potentially, multiple BridgePoint Database Servers.

1.3 Databases

The OOA of a particular domain is a tangible, exchangeable entity that can be used by more than one project. Each OOA database will contain all of the artifacts for one—and only one—domain.

Each SIM database holds the information for only one simulation. SIM databfiles are not intended for simultaneous use by multiple users.

CHAPTER 2:

Fundamentals

2.1 Window OverviewBridgePoint Model Builder contains several types of windows (see Table 2.1).

TABLE 2.1 BridgePoint Model Builder Windows

Window Type: Window Multiplicity: Accessible From:

Index 1 Invocation

Preferences 1 Index

Model

Model 1 per Model Instance Index

Model Navigation

Data Editor 1 (Data Editor Type based on Selected Item in Model)

Model

4 Fundamentals

2.2 Invoking BridgePoint Model BuilderSeveral steps must be taken before invoking BridgePoint Model Builder for the first time.

To invoke BridgePoint Model Builder:

1. Determine whether or not the Model Builder process is in your path:$ type pt_builder

If pt_builder appears, skip to step 4. If not, continue:

2. Add to your path the directory: INSTALL_DIR/BridgePoint/bin

Note: Obtain the name and path of your installation directory, referred to asINSTALL_DIR, from your system administrator.

3. Verify path was updated correctly: $ type pt_builder

Note: If pt_builder appears, then continue to next step. If not, see your systemadministrator.

4. Run BridgePoint Model Builder from a shell capable of displaying X applications: $ pt_builder

Steps 1-3 are required the first time the tool is invoked or after the installation of a new release. To invoke the tool anytime thereafter, use step 4.

Description 1 per Description Instance Model

Data Editor

Print Setup 1 per Model Instance Index

Model

Notebook Print 1 Index

TABLE 2.1 BridgePoint Model Builder Windows

Window Type: Window Multiplicity: Accessible From:

5

Each user invoking Model Builder should use his or her own distinct login/userid for simultaneous access. Database corruption may result if the same login/userid is used by multiple users simultaneously.

Command Line OptionsBridgePoint products are based on a GUI supported by Galaxy (a general purpose GUI manager). Galaxy allows the user to pick between OpenLook, Motif, or Windows presentations. Default presentation depends on machine hardware. To override these defaults and allow the user to run Model Builder with a desired look and feel, invoke the BridgePoint product with the appropriate -laf parameter. The possibilities are:

• pt_builder -laf openlook3d

• pt_builder -laf motif

• pt_builder -laf windows3d

2.3 BridgePoint Model Builder Index WindowThe Index Window (see Figure 2.1) is the system view of BridgePoint Model Builder and is the window you see when the tool is invoked. From this window you can directly:

• Create and Open Domain OOA Databases

• Control User & Project Preferences

• Control Versioning

• Access Model Editing Windows

• Print Models and Notebook

• Control Importing and Exporting of OOA Data

• Audit OOA Data

6 Fundamentals

Figure 2.1 Index Window

2.4 File OperationsThe pulldown File menu creates new or loads existing Domain OOA database files, or changes the print setup. Note that all database names must end in .ooa.

7

y

are

e

ation.

2.5 OOA Database OperationsThe following operations are available in Model Builder to allow the analyst to manipulate the OOA Databases:

• Open x.ooa

• Create x.ooa from Existing Domain Repository

• Create x.ooa & Domain Repository for New Domain

2.5.1 Open Domain OOAIt is only necessary to open a database after it has been created for a new domain or an existing domain. Only a user’s personal database, not those created bothers, should be opened.

To open a Domain OOA Database:

1. From the Index Window, MENU-Click on the File button.

2. SELECT-Click on Open x.ooa.

3. Navigate the File Chooser until the desired directory is reached.

4. Type in the database name at the caret and SELECT-Click on OK, or Double-Click on the database name.

Note: If a database's file permissions are read-only, all Version controlshidden once the domain is loaded. See the Version Management,Chapter 5 for details regarding read-only permissions.

2.5.2 Database/Domain CreationInitially, only one user needs to create a given domain. Once it is created, th(Existing Domain) users will have to create individual OOA databases (sometimes called “personal” databases) using the initial domain as a found

2.5.2.1 Creating a Database from an Existing Domain

8 Fundamentals

xt in id

ing

all

xt id

Once the new domain has been created, other users can create individual databases using the existing domain as a foundation.

To create a Database from an Existing Domain:

1. From the index window, MENU-Click on the file button.

2. SELECT-Click on Create x.ooa from Existing Domain Repository. A file chooser will appear.

3. Navigate the file chooser until the desired directory is reached.

4. Enter the domain name followed by the user’s login id (Actually, any testring can be entered, but it is highly recommended that the users logbe used).

For example, the initial domain was created as car.ooa. Another user(called usr2) will need to create his or her own domain using the ExistDomain button (i.e., car__usr2.ooa).

For a typical users scenario, please refer to Chapter 5.

5. SELECT-Click on OK.

2.5.2.2 Creating Database for New DomainBefore beginning any work, a new domain must be created. This is done byforming a common domain repository (the initial database) that is shared byusing that domain.

To create a database for a New Domain:

1. From the index window, MENU-Click on the file button.

2. SELECT-Click on Create x.ooa from New Domain Repository. A file chooser will appear.

3. Navigate the file chooser until the desired directory is reached.

4. Enter the domain name followed by the user’s login id (Actually, any testring can be entered, but it is highly recommended that the user loginbe used). The file name must take the form: <Domain_Name>.ooa.

9

This database should not contain the double underscores.


When this operation is complete, a new OOA Database and Domain Repository will exist.

2.5.3 Print SetupThis property is used to define the commands needed to print OOA Models and Descriptions from BridgePoint Model Builder.

Note: Model Builder prints to a temporary file in the /tmp directory; the${USER_FILE} environment variable is set to this temporary file name.ALWAYS use ${USER_FILE} as the file name in your default printcommands.

Default Model Print Command - On this text line, type in the command for printing on your system with ${USER_FILE} as the temporary file name.

Default Text Print Command - On this text line, type in the desired commands for text formatting and printing on your system with ${USER_FILE} as the temporary file name.

Orientation - This selects Portrait or Landscape orientation for model output. All text output will be in Portrait orientation.

Paper - This sets width and height of paper. It is used to scale the model output. Setting the orientation will default the paper size to 8.5 inches by 11 inches with the correct orientation.

Options... Print to - This allows the output to be sent to a file instead of a printer. If the file option is used, the Default Model Print Command and Default Text Print Command are ignored, and the output is copied into the specified file. Remember to press the OK button on the Print Options page for the File choice to become effective.

Options... Poster Form - This specifies that the model output will be enlarged and divided into the specified number of rows and columns.

10 Fundamentals

2.5.4 AboutThe About button brings up a dialog box that displays Platform and version numbers of the client BridgePoint Model Builder product, as well as, support and product information telephone numbers.

2.6 PreferencesThis feature is accessible from the Index window, and from every modeling window. Use it to control the following:

• User Preferences

– Auto Numbering

– Audits

– Backups

– Canvas Color

– Font

– Project Properties File

– Shape Color

– Miscellaneous

• Project Preferences

– Description Templates

– Description Formats

– SQL Formats

Model Builder creates a file in your $home directory to store user preferences. Project preferences are stored in a file that you specify.

11

2.6.1 User PreferencesUser preferences allow customization of your personal Model Builder session environment. Changes made to these settings remain intact across invocations until modified.

To Set User Preferences:

1. MENU-Click on the Preferences pull-down menu.

2. SELECT-Click on User.

3. MENU-Click on the Category menu button.

4. SELECT-Click on the desired category.

Note: User preference changes must be applied before they become active.

2.6.1.1 Auto NumberingAuto numbering can be set for objects, relationships, states, or events (each can be set independently). The default is ON for all items. Auto numbering automatically assigns unique numbers to the number field of the entity chosen for editing; the number assigned is one greater than the previous number for that entity. If auto-numbering is not used, numbers can be assigned to any item by using its respective data editor.

When auto numbering is turned off for any item, the number associated with a newly-drawn object or relationship will be the value that you specified as the Auto Numbering Start Value for that subsystem in the Domain Decomposition window. The number associated with a newly-drawn state or event will always be zero (0). If auto numbering is not used, the number can be set manually by using the appropriate editor.

To Set Auto Numbering:

1. Access User Preferences as described in Section 2.6.1. Choose Auto Numbering.

2. SELECT-Click on any or all of the items.


12 Fundamentals

2.6.1.2 AuditsThis user property allows the user to engage or disengage specific audit checks. The audit is run on demand from Index window glyphs or from the Model Window. Typically, a specific audit is disengaged if the project does not supply a certain description. For example: if you do not want to supply a relationship description, you will disengage the Relationship Description audit to avoid unnecessary audit output.

2.6.1.3 BackupsThis property is used to control ascii backups of user databases. The use of this feature is recommended to insure recovery in the case of database corruption or .ooa files that are accidentally removed.

Model Builder will make backups automatically upon a check-in operation from either the domain/subsystem level, or the state model/action level. Backups can also be done on demand from the Index Window. This window allows the user to specify where backup files are kept and to control the number of backups that are kept per database. All backups are suffixed with a .bak. The naming convention is as follows: domain_name1.bak is always the most current. If the user has specified the number of backups to be three (3) and a backup operation is performed, then domain_name2.bak moves to domain_name3.bak, domain_name1.bak moves to domain_name2.bak, domain_name1.bak is populated with the selected data and what was in domain_name3.bak is lost. To retrieve backup data, the Import - Backup option should be used.

Backups on Check-in - This tells Model Builder if you want a backup file created automatically every time a check-in operation is performed.

Number of Backups - This specifies the historical depth on a per database basis.

Backup Directory - This identifies the location where backup files will be created.

Note: Importing backup files can take several minutes for large databases.

2.6.1.4 Canvas Color

13

r e

d

d be you n

d ed at

The Canvas Color user property is used by the user to define a custom foreground and background color scheme for each model type. The defined colors are used for the models themselves, button colors on the Index page, and for the buttons on the Navigate menu found on each model window. This allows users to quickly identify or navigate to specific model types on the display based on color.

To Set a Canvas Color:

1. Press the button for the desired model and background/foreground. Note that Assigner State Models (ASM) and Instance State Models (ISM) are treated separately.

2. Press the “Edit Colors...” button to bring up the Color Chooser dialog.

3. You can choose a color based on either name or by selecting the colofrom a color wheel. The “Views” menu will let you toggle between thestwo choosing methods. The default is to select the color from a color wheel.

4. If you are choosing a color based on name, double click on the desirename and hit the “Apply” button on the Color Chooser dialog.

5. If you are choosing a color by selecting from a color wheel, the “ColorMethods” menu can be used to change between HLS, RGB, CMY, anGray methods. For RGB and CMY methods, the “Options” menu can used to alternate between color planes. Regardless of color method, can modify color by either clicking directly on the color wheel/square othe right or by adjusting the sliders at the bottom. The lower half of therectangle on left is the current color and the upper half is the selectedcolor.

6. Repeat steps 1-5 for all the models to be changed.

7. Back on the User Preferences Canvas Color dialog, press “Apply” to commit all the changes persistently. At this point, all affected model windows and the index window will be updated with the new colors.

2.6.1.5 FontThis property enables the user to select the font used in the presentation anprinting of all models in the OOA. When utilizing this property, a file chooserappears that lists all available fonts on your system. The font may be chang

14 Fundamentals

any time during your OOA sessions. Session font changes will result in a global change to the font in all of your models.

Note: Often in the presentation and printing of OOA models, certain elementsare bold or italic for clarification. In order for the text to be plain font (nobold or italics), select the Normal Font Only option.

Note: Font sizes are automatically selected for correct sizing within graphicalelements. User cannot redefine.

To Choose a Default Font:

1. Access User Specific Properties as described in Section 2-4. Choose Font.

2. In the file chooser, scroll to the desired font and SELECT-Click on the font name.

3. If you do not want text to appear bold or italic, SELECT-Click on the Normal Font Only.


2.6.1.6 Project Properties FileThis property is used to identify the file in the description format strings and to save template filenames.

Note: If the properties being utilized are global to a project (i.e., everyoneinvolved in the project will use the same description format strings,template filenames, and SQL formats), obtain the file name from theindividual who entered the information, and enter it in this property.These property specifications are then automatically entered into theappropriate property areas.

15

r e

d

d be you n

To Enter a Project Properties File:

1. Access User Preferences as described in Section 2.6.1. Choose Project Properties File.

2. Select-Click on Select Project File.

3. Navigate until the correct file is located.

4. Type in the filename at the caret and Click on OK, or Double-Click on the filename.

Alternatively:

1. Type in the full path and new filename at the caret in the Save-As pop-up window.

2. Click on OK.

2.6.1.7 Shape ColorThe Shape Color user property is used by the user to define a custom background color for each model shapes, such as Object and Subsystem. This allows users to quickly identify or navigate to specific model types on the display based on color.

To Set a Shape Color:

1. Press the button for the desired shape and background/foreground. Press the “Edit Colors...” button to bring up the Color Chooser dialog.

2. You can choose a color based on either name or by selecting the colofrom a color wheel. The “Views” menu will let you toogle between thestwo choosing methods. The default is to select the color from a color wheel.

3. If you are choosing a color based on name, double click on the desirename and hit the “Apply” button on the Color Chooser dialog.

4. If you are choosing a color by selecting from a color wheel, the “ColorMethods” menu can be used to change between HLS, RGB, CMY, anGray methods. For RGB and CMY methods, the “Options” menu can used to alternate between color planes. Regardless of color method, can modify color by either clicking directly on the color wheel/square othe right or by adjusting the sliders at the bottom. The lower half of the

16 Fundamentals

on

areser

ee

e can

rectangle on left is the current color and the upper half is the selected color.

5. Repeat steps 1-5 for all the shapes to be changed.

6. Back on the User Preferences Canvas Color dialog, press “Apply” to commit all the changes persistently. At this point, all affected shapes active model windows will be updated with the new colors.

Note: Assigner State Model (ASM) and Instance State Model (ISM) colors determined by background selections from the Canvas Color UProperty. See section 2.6.1.4 for additional instructions.

2.6.1.8 MiscellaneousThis property allows system warnings to be disabled. Currently there are thrwarnings:

• Unapplied Edits Warning

• Parse Actions on Import

• Init Parse on Apply to ON

• Default STT entry

Unapplied Edits. If you are entering new attributes into an object and you dismiss the object data editor window before applying changes, normally you are warned and given the opportunity to apply the new attributes before closing the window. If you disable the Unapplied Edits warning, the object data editor window closes without applying the new attributes. By disabling a warning, a user may inadvertently lose unapplied edits.

Parse Actions on Import provides for parsing actions when an import is performed. For example, it may be useful to have this ON when importing data that is mostly complete and accurate. If imported data is known to be incomplete, then it may not be useful to set parse actions on import.

Init Parse on Apply to ON - If selected, initializes parse on apply to ON for a given action when the corresponding state is created.

Default STT entry - This indicates whether a cell of the state transition table defaults to event ignored or can’t happen. Note that one and only one of thesbe selected.

17

To Set System Warnings:

1. Access User Preferences as described in Section 2.6.1.Choose Warnings.

2. If you wish to disable warnings, SELECT-Click on the appropriate system warning. If the button is not highlighted, it has been disabled.

Note that each system warning must be selected independently and applied.

2.6.2 Project PreferencesProject specific preferences enable all individuals working on an OOA project to share common characteristics in order to ensure consistency throughout the project. This facilitates consistency in the appearance of model descriptions and SQL exports among multiple individuals in an OOA project.

Note: All the format strings and template filenames can be entered as discussedin the previous section, User Preferences. When you apply thisinformation by saving to the Project Properties File, everyone involvedin the project can use the strings and filenames you defined by enteringyour filename in their Project Properties File area. Conversely, you canenter the name of a file that has been created by another individual intothis area, and the strings they previously defined will appear in yourTemplate Filenames, Description Format and SQL Format properties.

Changes made to these settings remain intact until the next time they are modified.

2.6.2.1 Description Templates

It is common practice for various descriptions to have a pre-determined format and style that everyone on the project must follow. For example, suppose we wanted all object description to have the following template format.

Object Description:

Object Role:

18 Fundamentals

A description template provides for a template to be automatically generated when the item is created.

To Define Template Descriptions and Files:

1. Outside the tool, create and edit a file to contain your template for the desired description.

2. In the Index window, Select-Click the Preferences pull-down window. Choose Project Preferences and then choose Description Templates.

3. For each item needing a description template, type the full path and name of the file you created in step 1.

4. Upon SELECT-Clicking the Apply button, all items that you create from this point forward will have the text from Step 1 in the description window. All existing descriptions will be unchanged.

5. Repeat steps 1 - 4 for each template description you wish to use.

2.6.2.2 Description FormatsThis property allows specific text formatting strings (256 character limit) to be included in model descriptions that can be printed from the notebook window (which is accessible from the index window). Note that the notebook option aids in importing formats from other desktop publishers.

Report Include File- On this text line, type in the path and name of a previously defined file that contains formatting commands, such as .macro definitions. When Model Builder reports are printed, this file is read in and placed at the beginning of the print file.

Beginning Report String- On these text lines, type in formatting strings to be included at the Beginning and/or End of each report. If more formatting strings or commands are required than are permitted here, use the Report Include File discussed above.

Before Format Strings/After Format Strings- On these text lines, type in specific formatting strings for the desired level(s), that is, Report, Section, Description Number, Description Titles, Description Header, and Body.

19

The strings default to ASCII formatting commands, and can be overwritten for other text processing packages. When these strings are changed and applied, they are saved in the Project Preferences file.

Format Management - This allows the user to add new format strings or to cut existing format strings. It also provides the load options used to apply the format type (i.e., troff, ASCII, etc.).

Format Type - Any formats that are Added from the steps listed above will show up in the Format Type area when MENU-Clicking the menu button. SELECT-Click on the desired Format Type and the strings previously entered will appear.

After selecting the format type, you must MENU-Click on Format Management and SELECT-Click Load to load the format type.

Load on Init - After selecting a Format Type, SELECT-Click on the Load on Init check box to load this Format Type each time BridgePoint Model Builder is initiated. If you do not SELECT-Click on the Load on Init check box, the Format type may differ each time you enter Model Builder.

2.6.2.3 SQL FormatsThis property exists to help support translation. If OOA data is imported into a relational database for source code generation or document generation, be aware that different relational databases accept different SQL syntax. Database specific syntax elements are entered in this property window to assist a user in exporting data to SQL and seamlessly importing the output into a relational database of choice.

’CREATE TABLE’ Format - On this text line, type in the desired format of the CREATE TABLE statement. The defined substitution variables on the text line must be used.

’CREATE TABLE’ Field - On these text lines, enter the typing syntax needed to support the relational database of choice.

2.7 Model SelectionThe Index Window contains four scrolling lists where items are selected from your working OOA.

20 Fundamentals

When a Domain OOA database file is created or loaded, the name appears in the Loaded Database scrolling list.

More than one database can be loaded at any given time. However, once a database is loaded, it remains loaded for the duration of your Model Builder session, and you cannot unload it without exiting and re-invoking Model Builder.

The remaining three scrolling lists appear to the left of the horizontal row of modeling glyphs to which they pertain. For example, the Subsystem list appears to the left of the four subsystem-oriented modeling glyphs.

Using the Model Editing Glyphs:

1. SELECT-Click on the desired subsystem in the Subsystem list.

2. Menu-Click on the OIM glyph and select SHOW to bring up the OIM window.

Alternatively:

Double-Click on the desired subsystem.

The State Based Models and Action Based Models scrolling lists work exactly as the Subsystem example described above.

Note: In order to edit the models described in the above steps, you must Check-Out the model first. This is explained briefly in the next section.If it is not checked-out, then it is still accessible, but in read-only mode.

2.8 VersioningPlease refer to Chapter 5 for a detailed explanation of how BridgePoint Model Builder utilizes Version Management.

In short, Model Builder facilitates two levels of versioning - the Domain/ Subsystem level and the State Model/Action level. In order to edit any of the models at these levels, the desired version must be checked-out.

2.9 Model EditingThe Index Window provides access to the Model Editing Windows.

21

2.9.1 GlyphsEach Window is accessed through a glyph, which represents the specific OOA function of the Window.

Before accessing a glyph, an item in the corresponding list to the left must be selected. To access a model editing window, simply MENU-Click on the desired glyph.

Note: When modeling an OOA, most of the work takes place in the four glyphswhich form a diagonal from top-left to bottom-right. When you MENU-Click on one of these glyphs (SPM, OIM, or SM), the followingmenu appears: (When you click on the Action glyph, only the Showoption appears.)

Show - This invokes the model editing window.

Print - This permits Default or Custom printing of the model, without invoking the editing window.

Notebook - This invokes the Project Notebook (see next section).

Import/Export - These are methods of exchanging data both inside and outside of BridgePoint Model Builder. Note that Import only exists when the model is checked-out.

Audit - This verifies model completion and name uniqueness.

Note: Chapter 4 provides detailed instructions for using the BridgePoint ModelBuilder printing facilities. Chapter 7 contains details on Import/Export.

2.9.2 Model Editing WindowsAll of BridgePoint Model Builder’s model editing windows are similar in look and feel, with the exception of the Action and State Transition Table windows. The Object Information Model window illustrated in Figure 2.2 demonstrates the common features of the editing windows.

22 Fundamentals

Figure 2.2 Object Information Model Editing Window

23

2.9.2.1 Drawing ToolsThe SPM, OIM, OCM, OAM, and SM editing windows provide a series of glyphs (i.e., drawing tools) which are accessible when the latest version of a model is checked-out. When in read-only mode, they are inactive.

Individual chapters in this manual are devoted to each model editing window. These chapters describe the appropriate tools and provide instructions on creating objects, states, relationships, transitions, and other elements. Chapter 3 describes drawing and editing techniques which are common to all model editing windows.

2.9.2.2 Control ButtonsEach model editing window contains a series of control pull-down menus beginning at the top left-hand corner of the window. Each button controls a specific function, as described below.

2.9.2.3 File ButtonThis button provides the following options:

• Refresh - Redraws screen (canvas)

• Import - Imports diagrams and/or data

• Audit - Scans OOA for redundant IDs

• Print Setup - Specifies printer options

• Close Editor - Closes window in which you are working

Please refer to Chapter 7, Exchanging Data, for details on importing data.

2.9.2.3.1 AuditBridgePoint Model Builder provides an audit feature which scans an entire OOA for redundant ID’s, Objects without ID’s, unformalized Relationships, and other inconsistencies.

An OOA can be audited at the SPM, OIM, and SM levels. To access the Audit feature, MENU-Click on the SPM, OIM or SM Glyph, then SELECT-Click on Audit. This feature may also be accessed from each of the Model Builder windows via the File pull-down menu.

24 Fundamentals

If there is audit information to report, it is written to a text file in your home directory, and a message similar to the following is displayed:

Audit Results are in $HOME/ooa_audit.txt

Otherwise, a message is displayed which reports that there is no audit information.

2.9.2.4 Edit ButtonThis button provides context-sensitive editing functionality specific to the model (and selected drawing element) that is currently being edited. Use it to invoke model element-specific data editors, cut selected elements, or, when editing relationships, to add/delete points from a relationship line. Specific details are provided for the functionality described above in Chapter 3, Model Editing, and in the Model-specific chapters.

2.9.2.5 View ButtonThis button provides the ability to turn off the viewing of (and hence the printing of) object numbers, key letters, and/or attributes, to simplify model presentation. Note that the view button may have varied appearances dependent on the window in which you are working.

The View button is used for zooming (25% to 150%), and also for displaying the grid.

The Snap Grid and Zoom features are used to customize your model editing sessions. Adjusting the snap grid allows easy alignment of drawing elements, while using zoom allows you to view a series of elements on the screen that may not fit when viewed full size.

2.9.2.6 Preferences ButtonThis button provides access to the user/project specific preferences discussed earlier in Section 2.6.

25

2.9.2.7 Drawing AreaThis is the area in which OOA models are drawn and edited; this is also referred to as a canvas. A screen of approximately 10 x 10 is available for each model. The scrollbar jumps 32 pixels at a time.

When printing models, Model Builder currently scans the entire drawing area in all four directions, and centers the model on one page of output (scaling as necessary to fit on one page). Poster Printing is also available for large models.

Please refer to Chapter 3, Model Editing, for further information regarding the drawing area.

2.9.2.8 NavigationBridgePoint Model Builder provides a navigation facility, which gives you instant access to related models (or the Index Window) from any model in your current OOA. The navigation buttons are located on the lower left hand-side of the canvas.

You can navigate to models which are:

• at the same level, or

• at a higher level

than the level of the model that you are currently working on. For example, if you are viewing an Information Model, you can navigate to the OCM, OAM, or any of the domain-based models. Navigation to the next lower level is possible only when an appropriate element is selected. If you are currently working in an Information Model and you select an object, you can navigate to the State Model for that object.

26 Fundamentals

2.10 Data Editor ConstraintsIn BridgePoint Model Builder, all OOA model data is entered via a set of data editors. Data editors allow BridgePoint Model Builder to enforce the Shlaer-Mellor Method and ensure consistency and correctness. Table 2.2 describes the character limitations and value ranges where appropriate for each Data Editor.

TABLE 2.2 Data Editor Constraints

Data Editor Element # Characters Range

Subsystem Data Editor Subsystem Name 64

Subsystem Prefix 8

Auto Number Range 4 0 - 9999

External Entity Data Edi-tor

Entity Name 64

Entity Key Letters 8

Entity Data Item 64

Data Type Data Editor Data Type Name 64

Bridge Data Editor Bridge Name 64

Bridge Parameter Name 64

Object Data Editor Object Number 4 0 - 9999

Object Name 64

Object Key Letters 8

Attribute Prefix 64

Attribute Name 64

Transformer Data Editor Transformer Name 64

27

2.11 Data Editor Acceleration KeysAll data editors are built on a common set of editing capabilities. Common accelerator keys are:

Ctrl+A - Selects entire field

Tab - Allows you to advance to the next field and select

Shift tab - Allows you to recede to the previous field and select

If text is selected, the next key stroke will replace the selected text. To avoid losing all selected text, use the mouse and click at the desired location.

Transformer Parameter Name

64

Relationship Data Editor Relationship Number 4 0 - 9999

Relationship Phrase 128

Composition String 128

State Data Editor State Number 4 0 - 9999

State Name 64

Event Data Editor Event Number 4 0 - 9999

Event Label 8

Event Meaning 64

Event Data Item Data Edi-tor

Event Data Item Name 64

TABLE 2.2 Data Editor Constraints

28 Fundamentals

2.12 Description Editor

2.12.1 Description Editor MenusThe Description Editor consists of the following menus.File - This menu allows the user to Load, Save, or Include a file.

Edit - This menu supports Cut, Copy, Paste, and Clear. Keyboard accelerators are consistent with the look and feel chosen.

Tools - This menu supports the ability to GoTo a specified line.

2.12.2 Description Editor Acceleration KeysThe description editor supports:

Ctlr+A - This keyboard sequence selects all text.

keyboard arrows - The arrows advance up, down, left, or to the right.

The description editor menu accelerators are used in the description text window.

CHAPTER 3:

Model Editing

The graphical elements available to the user to draw OOA models are referred to in this chapter as SHAPES and CONNECTORS. Model editing encompasses drawing shapes and connectors for all the OOA models. Procedures described in this chapter are the same for all model editing screens.

This chapter describes procedures for drawing OOA models, and explains the model editing screens in detail, including:

• Screen Size

• Drawing

• Selecting

• Moving

• Resizing

3.1 Screen SizeThe underlying drawing area of each model is 8000 pixels wide by 6000 pixels tall. At 100 percent zoom (default), one drawing screen is 800 x 600 pixels (default). This gives you 10 x 10 screens on which to draw each model. When you invoke a modeling window, the default upper left hand corner of the drawing area defaults to 1600 x 1200 pixels on the underlying area. This allows you to draw

30 Model Editing

your models in a left-to-right fashion, leaving room to move the models to the left if necessary. When printing models, Model Builder currently scans the entire drawing area in all four directions, and centers the model on one page of output (scaling as necessary to fit on one page).

Note: The scrollbar jumps 32 pixels at a time.

3.2 Snap GridThe snap grid affects creation, move, and resize operations, with the exception of the text phrase boxes for connectors. The space for connector text phrases is often so tight that snap grids are a hindrance in that case.

• The snap grid is always on. You can choose whether or not you want it to be visible. The snap grid sizes range from 1 pixel to 64 pixels.

• The snap grid operation is unaffected by the visible grid. The visible grid is only for your convenience.

• When a shape is created, all corner points of the shape will align with the snap grid.

• When a shape is moved, the upper left corner will align with the snap grid. (All other corners will align if the grid size has not changed.)

• When a shape is resized, the corner being resized will align with the snap grid.

• When you resize a point of a connector, that point will align with the snap grid.

• The visible grid is turned off if the (grid size * zoom factor) is less than 16 pixels.

3.2.1 Turn Snap Grid Lines On/Off Automatically

Turning On/Off Snap Grid:

1. MENU-Click on the View button.

2. SELECT-Click on Snap Grid On/Off.

31

3.2.2 Adjust Snap Grid

To Adjust Snap Grid:

1. MENU-Click on the Draw button.

2. MENU-Click on Snap Grid.

3. Then SELECT-Click on the desired pixel setting.

3.3 ZoomThe overall modeling screen size is modified with zoom, so the relative size of the model is unchanged. No graphical elements can be created in one zoom level that cannot be accessed in another zoom level.

Note: Functionality is unchanged due to the zoom level.

To Adjust Zoom Level:

1. MENU-Click on the View button.

2. MENU-Click on Zoom.

3. SELECT-Click on the desired Zoom level.

3.4 Drawing ProceduresThe following sections provide the step by step procedures for drawing and editing graphical elements. For specific instructions on creating objects and relationships, states, events, and transactions, refer to the chapters on Information Modeling and State Modeling in the BridgePoint OOA manual.

Note: The model must be checked-out to allow drawing.

32 Model Editing

3.4.1 Drawing Shapes

Drawing Shapes:

1. SELECT-Click on the shape glyph (Object, State, etc. depending on the model editor in which you are currently working).

2. Move the pointer (which is now in the shape of a pencil) into the drawing area.

3. Press and hold SELECT.

4. Drag the pointer diagonally to draw the shape. The shape appears and changes size as you draw it.

5. When the shape is the proper size, release SELECT.

6. Press the ADJUST button or move the mouse out of the window to get out of drawing mode.

Steps 4 and 5 can be repeated so that multiple shapes can be drawn.

All shape glyphs allow multiple instances to be created without re-pressing the glyph. This speeds the creation process when many graphical elements are drawn in sequence.

Note: If the pointer moves out of the model window while you are drawing, theshape will still be drawn, and will end at the point you left the window.

Note: The shape must be big enough to accommodate resize handles. If theshape is too small, you will get an error message and the shape will notbe drawn.

3.4.2 Drawing ConnectorsThe procedure for drawing connectors is similar in all editing windows. Depending on the window in which you are currently modeling, different connector glyphs are available. For example, in the Information Modeling window the Simple, Associative, Sub-Type, and Super-Type connector glyphs are available. In the State Model window, the Transition connector glyph is available. The following procedure applies for all connector glyphs.

33

Drawing Connectors:

1. SELECT-Click on the connector glyph you wish to use.

2. Move the pointer to the desired location on the drawing area, and SELECT-Click.

3. Drag the pointer to draw the connector. The line appears and changes size as you draw it

To create a multi-point line, SELECT-Click anywhere in the drawing area (except inside another shape).

4. End the connection by SELECT-Clicking on the specified end-point depending on the type of connection you are drawing.

5. Press the ADJUST button or move the mouse out of the window to get out of drawing mode.

3.5 SelectingThe graphical element border will be highlighted when it is selected. The ADJUST button action allows multiple objects to be selected and acts as a select toggle. Pressing the select button in an area with no graphical elements causes all currently selected graphical elements to be deselected. Pressing the adjust button in an area with no graphical elements does nothing.

Selecting Elements:

1. To select a shape, SELECT-Click anywhere INSIDE the shape.

2. To select a connector, SELECT-Click anywhere along the connector

For shapes that are not rectangular, a move/resize box will be displayed around the object as part of the highlight process done for selection. For a selected connector, all line segment endpoints will be highlighted with a circle.

If two graphical elements (either a shape or a connector) overlay each other, then only the top graphical element is affected by the select and adjust buttons. In order to select or adjust the bottom graphical element, either move the pointer to a location on the bottom graphical element that is not overlaid, or move the top graphical element and then operate on the bottom graphical element.

34 Model Editing

3.5.1 Selecting Multiple Elements

Multiple elements can be selected at once to facilitate large moves.

Selecting Multiple Elements:

1. Move the pointer to an area without a graphical element.


The pointer changes to a panning pointer.

3. Sweep an area by dragging the pointer in a diagonal fashion. A box is generated to show the user the dynamic layout of the area.

4. Release SELECT to define the selected elements. All shapes and connectors in the area will become selected. If no objects exist in the area, nothing happens. The box is deleted.

The multiple select capability also works with the adjust button pressed. In this case, all graphical elements in the region will toggle their selection state.

3.6 MovingMove operations work for either an unselected single graphical element or a group of selected graphical elements. In both cases, all connectors stay attached to their shapes. If a shape is moved and a connector that is attached to that shape is not moved, then the attached line segment will rubber band to stay attached to the shape.

3.6.1 Moving Selected ElementsThis operation moves multiple graphical elements at the same time.

Moving Selected Elements:

1. Select one or more shapes or connectors.

2. Position the pointer within a selected shape or within a small delta distance from a selected connector.

The resize points of the selected graphical elements should be avoided. Resize points for shapes are in the resize corners and resize points for connectors are on the line segment end points over the circles.

35

The pointer will remain as the normal pointer. If the pointer becomes a bull’s eye then the pointer is over a resize point. In this case, just move the pointer until it becomes a normal pointer again.


4. Move the mouse. The pointer changes to the move pointer. The original graphical elements remain unchanged in the highlighted box. Move box(es) with no content move around to show relative position.

5. Release SELECT or move the pointer out of the window. The content of the box(es) is copied into the new box(es) location. The old boxes are deleted.

3.6.2 Moving Unselected ElementsThis operation moves a single shape. Connectors cannot be moved with an unselected move since connectors must stay attached to their shapes.

Moving Unselected Elements:

1. Move the pointer INSIDE an unselected shape. There may be selected graphical elements on the model; they are unaffected.

The pointer will remain as the normal pointer. If the pointer changes to the bull’s eye then the pointer is over a resize point. In this case, just move the pointer until the pointer changes back to the normal pointer.


3. Move the mouse. The pointer becomes the move pointer. The original shape remains unchanged. A move box with no content circulates to show relative position.

4. Release SELECT (or move the pointer out of the window). The content of the shape is copied into the new box’s location. The old box is deleted.

3.7 Cutting Graphical ElementsAny selected graphical element can be cut.

36 Model Editing

Cutting Graphical Elements:

1. Select the element you wish to cut (as described above).

2. In every modeling window there is an Edit button. MENU-Click on the Edit button and then SELECT-Click on Cut (or, use the keyboard CUT button).

3.8 Resizing ShapesThe shape to be resized must be selected, which causes resize handles to be displayed. See Section 3.5 for selecting.

Resizing Shapes:

1. Move the pointer over one of the shape corners. If the pointer is within the resize corner, it changes to the resize pointer.


Move the mouse. The original shape remains visible. A box outline of the resized box is displayed. This resize dynamically changes with pointer movement to let you know the current resize box size.

3. Release SELECT (or move the pointer outside the model window). The shape is resized to the new size. The pointer returns to the normal pointer.

3.9 Resizing ConnectorsThe connector to be resized must be selected. When this is done, circles are displayed around the resize points. See Section 3.5 for selecting.

Resizing Connectors:

1. Move the pointer over one of the resize points. If the pointer is within the resize corner, it changes to the resize cursor.


3. Move the mouse. The original connector remains visible. A dynamic resize connector will be shown and changed with each pointer movement.

4. Release SELECT (or move the pointer outside the model window). The connector is resized to the new size. The pointer returns to the normal pointer.

37

Note that the connector must stay attached to its shape for the OOA models to remain consistent. If the end point of a connector is resized to a point outside of the shape, then the connector will snap back to attach to the shape at the nearest point. If the end point is resized to within the shape (recommended), then the point at which the connector crosses the shape edge will become the attachment point.

3.9.1 Adding Points

Adding Points:

1. SELECT-Click on the desired connector to highlight it

2. MENU-Click, then SELECT-Click on Add Point. The pointer changes to a crosshair to denote that you are in an add/delete point scenario.

3. Move the pointer to the location on the connector where the point will be placed. The pointer becomes a cross when it is over a selected connector.

4. SELECT-Click to add a point, or ADJUST-Click or move the pointer outside of the window to cancel.

Pressing the select button when not on a selected connector (i.e., when the pointer is not a cross) will do nothing.

A point is added on the connector on the same slope. You can then use existing move operations to place the new point.

After an add or cancel operation the cross becomes a pointer.

3.9.2 Deleting PointsYou cannot delete first or last points. They must be attached to their respective shapes.

38 Model Editing

Deleting Points:

1. SELECT on the desired connector.

2. MENU-Click, then SELECT-Click on Delete Point. The pointer changes to a crosshair to denote that you are in a add/delete point scenario.

3. Move the pointer above the point to delete. The pointer will change to a target pointer when it is over the point.

4. SELECT-Click to delete the point, or ADJUST-Click or move the pointer outside of the window to cancel.

Pressing the select button when not on top of a point (i.e., when pointer is not a target pointer) will do nothing.

After the delete or cancel operation the crosshair becomes a pointer.

3.10 Working With TextText inside of shapes are automatically centered. If a line is too long for the shape, then the line will be broken at a word boundary and wrapped around. In the event that a single word is too long for a line, then the word will be broken and wrapped to the next line. If the shape is too shallow (too few lines), then the end lines will be truncated. In all cases, text is restrained within the shape.

To adjust for undesired line wraps and truncated lines, just enlarge the shape by resizing and the text will be re-centered.

Automatic hyphenation is not performed. However, if space is tight and hyphenation is desired, manually enter a hyphen and a space in the word from within the data editor.

Resize and move text on connectors the same way as described in the resizing shapes section. You must SELECT-click on the connector in order to see the selection box on the text.

Figure 3.1 shows moving and resizing a connector text box.

39

Figure 3.1 Adjusting Connector Text

40 Model Editing

CHAPTER 4:

Printing

Model Builder provides robust support for printing models and the text descriptions that accompany them. Currently, you can choose between portrait (vertical) and landscape (horizontal) printing of models. Model Builder automatically scans your models in all directions and sizes them to print on a single page. In addition, a poster print feature is available which allows you to print one model on several pieces of paper.

4.1 Printing from the Index WindowAny model can be printed from the Index Window.

Printing from the Index Window:

1. MENU-Click on the glyph that represents the model you wish to print.

2. MENU-Click on Print.

The current Print Setup will be used to determine the print location (whether to print to a file or printer), poster print options, and paper orientation. See Section 2.5.3 for Print Setup.

42 Printing

4.2 Printing from the Model EditorsIf you are currently in an Information Modeling or State Modeling session, you can print directly by utilizing the model editors.

Printing from Model Editors:

1. MENU-Click on the File button.

2. MENU-Click on the Print option.

The current Print Setup will be used to determine the print location (whether to print to a file or a printer), poster print options, and paper orientation. See Section 2.5.3 for Print Setup.

4.3 Printing with the Project NotebookThe Project Notebook is a powerful reporting tool that allows you to select, assemble and print various (or all) parts of your OOA.

From the index window, MENU-Click on either the OIM, SM, or SPM glyph, and choose Project Notebook.

The desired print command for the notebook output is taken from the current Print Setup. See Section 2.5.3 for Print Setup.

Project Notebook

1. SELECT-Click on the Printer rectangle.

2. To specify the Models and Descriptions to include in the print session, simply SELECT-Click on any desired model glyph and any desired description check box.

3. SELECT-Click on the Print button.

CHAPTER 5:

Version Management

To support cooperative work by a number of analysts working on common projects over a long period of time, BridgePoint Model Builder contains extensive version management facilities.

In this chapter, Typical Use Scenario, Version Management Concepts, OOA Databases, and the Domain Repository are described.

44 Version Management

5.1 Typical Use ScenarioThe following section explains a typical use scenario of Version Management.

Assume a team has been assigned to build a Video CD application. Doyt, Anita, and Doug have been assigned to work on the Video CD Domain.

After study and research of the Video CD Domain, Doyt, Anita, and Doug produce several technical notes describing the subject matter. The team is ready to begin Object-Oriented Analysis.

Doyt is designated as the leader for production of the Object Information Model (OIM) and as such, leads Anita and Doug through a post-it note / white board based OIM1. Once Doyt, Anita, and Doug have stabilized on a reasonable OIM, Doyt is ready to enter the work into BridgePoint Model Builder.

Doyt invokes BridgePoint Model Builder and selects the Create x.ooa & Domain Repository for New Domain (See Page 5.4.2.3). He checks out the Domain/Subsystems Configuration (See Page 5.4.3.2) and enters the Post-it Note/White Board based OIM. The OIM is printed and Doyt, Anita, and Doug review, discuss, research, modify... to refine the OIM. Doyt edits the OIM each time, checking it in (See Page 5.4.3.4) periodically to capture snapshots of the evolving work. At this point, one OOA Database and one Domain Repository exist (See Figure 5.1).

1. The Post-it Note /White Board technique for the OIM involves making one Post-it note for each object you identify and sticking each to the White Board. You then use white board markers to draw in the relationships. This technique promotes good small group interaction and easy revision as the first versions of the model are being produced.

45

or ch ain

Figure 5.1 OOA Database and Domain Repository for First User

As the OIM becomes stable, Doyt, Anita, and Doug turn their attention to the Object Communication Model (OCM). Doyt first uses the Object Data Editor (refer to the Object Information Model section of the OOA manual) to designate each object with a lifecycle as active. This automatically creates a State Model/Action Configuration for each active Object and places the Active Objects on the OCM. Communication Paths are added to the OCM and events are assigned to the Communication Paths. When Doyt uses the Event Data Editor (refer to the State Modeling section of the OOA manual) to define the Events for the Communication Paths, Model Builder automatically checks out the appropriate State Model/Action Configuration and adds the events to it. As a result, when Doyt completes the OCM work, he must check-in (See Page 5.4.3.4) the State Model/Action Configuration for each State Model.

Now that the OIM and OCM have become stable, the State Modeling activity can begin. Anita and Doug now need to work on the Video CD domain with BridgePoint Model Builder. Doyt checks in all of the Checked-Out Configurations and saves the Configuration Version View as an OOA Version (See Page 5.4.4.3). Anita then invokes BridgePoint Model Builder and uses the file operation “Create x.ooa from EXISTING Domain Repository” (See Page 5.4.2.2). Anita is prompted to select which OOA Version to use as the basis fthe creation of her OOA Database. Anita selects the version which Doyt justsaved. Doug does the same as Anita. At this point, Doyt, Anita, and Doug eahave their own personal OOA Databases. All are ’attached’ to the same DomRepository by the name of the x.ooa file itself (see Figure 5.2).

BridgePointModel Builder

OOADatabase

(videocd__1.ooa)

Domain videocdRepository

(Doyt)


Figure 5.2 OOA Databases and Domain Repository for Multiple Users

As analysis proceeds, Doyt, Anita, and Doug refine the OIM and OCM, develop State Models, and specify actions. As significant versions of the Domain OOA are generated, further OOA Versions are created.

BridgePoint Model Verifier is used and directly reads the OOA Database. BridgePoint Model Verifier stores the data instances and verification information in the Verification Database. Once the Video CD Domain is set, Doyt, Anita, and Doug are ready to move to the translation phase. Doyt assembles the latest and greatest view of the OIM, OCM, State Models, and Action Specifications and saves this as an OOA Version.

John is assigned the task of running the translator with the off-the-shelf Architecture which the project has purchased from Project Technology. John uses BridgePoint Generator to access the OOA Version of the Video CD Domain which Doyt just created, and then uses this to create the Generation Database. John then runs the BridgePoint Generator using off-the-shelf architecture and specification as input to generate the application source code (see Figure 5.3).


OOADatabase

(videocd__1.ooa)Domain videocd

Repository

(Doyt)


OOADatabase

(videocd__2.ooa)(Anita)


OOADatabase

(videocd__3.ooa)(Doug)

47

Figure 5.3 Databases and Domain Repository for Entire Project


OOADatabase

(videocd__1.ooa)(Doyt)


OOADatabase

(videocd__2.ooa)(Anita)


OOADatabase

(videocd__3.ooa)(Doug)

GenDatabase

(videocd.gen)

BridgePointGenerator

(John)Project Technology

Off-the-Shelf ArchitectureGenerated Application

Source Code

BridgePointModel Verifier

(Doyt)


(Anita)


(Doug)

VerificationDatabase



Domain videocdRepository


5.2 Version Management ConceptsThe version management capabilities must accomplish:

1. Control of concurrent work among a group of users, and

2. Management of evolving models over a period of time.

The following sections present in detail the approach taken by BridgePoint tools to accomplish the above goals.

5.2.1 Configurations and Configuration VersionsAssume a portion of the Domain OOA is managed separately as a set of configurations. A configuration can have multiple configuration versions. (see Figure 5.4).

Figure 5.4 Configuration and Configuration Versions

Each configuration version is conceptually a sheet of paper. Configuration Version 1 is a blank sheet of paper. Each subsequent configuration version is a sheet of paper which has successive additions/changes/deletions made to it.

In order to support a group of analysts cooperatively working on the same OOA Model, BridgePoint Model Builder allows an analyst to create new versions of a given configuration. Creating a new version conceptually adds a new sheet of

ver_1ver_2

ver_3ver_4

ver_5ver_6

Config 1

49

paper to the top of the version stack for the configuration. The following operations are provided for Configuration Version Management:

• Check-Out - make a copy of an existing configuration version and prepare the copy for edit (see Figure 5.5)

• Check-In - place the edited copy on the top of the stack of configuration versions (see Figure 5.6)

• Un-check-Out - throw away the copy (see Figure 5.7)

Figure 5.5 Check-out Configuration Version

Figure 5.6 Check-in Configuration Version

ver_1ver_2

ver_3ver_4

ver_5

Config 1

ver_6.11. Lock Configuration

2. Make copy of versionbeing checked out

3. Allow write access tocopy of checked-out version

ver_6

ver_1ver_2

ver_3ver_4

ver_5

Config 1

3. Unlock Configuration

2. Move copy of checked-out version to top

ver_6ver_7

of version stack

1. Disallow write access to copyof checked-out version

ver_6.1


Figure 5.7 Un-check-out Configuration Version

5.2.2 Domain ConfigurationsModel Builder supports 3 types of configurations:

1. OOA Version Configuration

2. Domain/Subsystem Configuration

3. State Model/Action Configurations

Figure 5.8 illustrates the configuration types in terms of the pattern of OOA models from the Index Window of Model Builder.

ver_1ver_2

ver_3ver_4

ver_5

Config 1

ver_6.1

3. Unlock Configuration

2. Destroy copy ofchecked-out versionver_6

1. Disallow write access to copyof checked-out version

51

Figure 5.8 Configurations in Terms of OOA Models

One analyst can have the Domain/Subsystem Configuration checked out while other analysts can have individual State Model/Action Configuration independently checked out. This allows several analysts to work on the same domain at the same time. For example, Doyt could be working on the disk drive state model config, while Anita is working on the Remote Control State Model Configuration.

Note: The state model for a given object is only visible if that object exists (andis active) in the current version (view) of the Domain/SubsystemConfiguration.

SPMSubsystemPartitionModel

SRMSubsystem

RelationshipModel

SCMSubsystem

CommunicationModel

SAMSubsystem

AccessModel

OIMObject

InformationModel

OCMObject

CommunicationModel

OAMObjectAccessModel

SMState

Model

STTState

TransitionTable

ASAction

Specification

Domain /Subsystem Configuration

State Model /Action Configuration


The boundaries of the Configurations are based on the OOA of OOA. (Recall that BridgePoint products are based on the OOA of OOA.) Model Builder is focused on capturing well formed data to support complete regenerative source code generation. Configuration boundaries through the OOA of OOA, which split apart heavily inter-related data instances, result in less effective point of entry checking. This in turn, reduces the quality of the data captured by Model Builder.

Many analysts expect the boundaries drawn to be based on graphical models, e.g., the OIM and the OCM would be in different configurations. Basing configurations on models causes artificial boundaries in the OOA of OOA since the OOA Domain (the subject matter which is described by the OOA of OOA) is a client domain in respect to the Graphical Data Domain and some OOA elements map to several Graphical Data elements.

Other analysts expect the OIM/OCM/OAM for each subsystem to be in a separate configuration. Unfortunately, this configuration boundary is an artificial one since subsystems are not independent of each other. All OIMs for a domain are intertwined, all OCMs for a domain are intertwined, and all OAMs for a domain are intertwined. Basing configurations on each subsystem causes artificial boundaries in the OOA of OOA data and leads to less complete point of entry check-in.

53

5.2.3 OOA & OOA VersionsA Domain OOA is made up of several configurations (see Figure 5.9).

Figure 5.9 Configurations in an OOA

Over time, each configuration builds up several configuration versions. At any point in time, a configuration version from each configuration constitutes an OOA Version:

Figure 5.10 OOA Version N

ver_1ver_2

ver_3ver_4

ver_1ver_2

ver_3

ver_1ver_2

ver_3ver_4

Config 3Config 2Config 1

ver_1ver_2

ver_3ver_4

ver_1ver_2

ver_3

ver_1ver_2

ver_3ver_4



As further work progresses on the OOA, further configuration versions are created (see Figure 5.11).

Figure 5.11 OOA Version N+1

The configuration versions which make up an OOA at any given time constitute an OOA Version.

OOA Versions are needed in long life projects since several OOA Versions may be active at one time. For example, one OOA Version may be deployed to the field, another OOA Version may be in System Test, and a third OOA Version may be under development.

Create OOA Version is provided for OOA Version Management. It lists the Configuration Version used for each Configuration of the OOA. For example, in the video cd domain, an OOA version may consist of version 5.0 of the Domain/Subsystem configuration, version 4.0 of the disk drive State Model configuration, and version 8.0 of the remote control State Model configuration. Note that an OOA version is not necessarily the latest version, but whatever you select it to be.

5.2.4 OOA of ’Version Management’As you may expect, Project Technology uses OOA as description technique, and Version Management is no exception. Figure 5.12 shows the OOA of Version Management. This OOA is described in the following sections.

ver_1ver_2

ver_3ver_4

ver_1ver_2

ver_3

ver_1ver_2

ver_3ver_4


ver_5ver_6

ver_4ver_5

ver_6

55

Figure 5.12 OOA of Version Management

5.2.4.1 Object and Attribute DescriptionsThis section describes Figure 5.12.

o 901. OOA (V_OOA)OOA (Dom_Name, Hi_VNum)

Identifier *: Dom_Name

901. OOA (V_OOA) * Dom_Name- Hi_VNum

902. Configuration (V_CONFIG) * Dom_Name (R901)* Config_ID- Hi_VNum- Hi_IDVal

is part of

R901

is made up of

903. OOA Version (V_OOAVER) * Dom_Name (R902)* OOA_VNum- Name- Abstract- Date- Creator

is snapshot in time of

R902

has

904. Configuration Version (V_CONVER) * Dom_Name (R903)* Config_ID (R903)* Con_VNum- Name- Abstract- Date- Creator

905. Configuration in OOA Version (V_CIOV) * Dom_Name (R904) (R904) (R905)* OOA_VNum (R904)* Config_ID (R904) (R905)- Con_VNum (R905)- Abstract

is a snapshot in time of

R903

has

contains oneversion of each of

R904

is part of

c

includes

R905

is part of

c


Description: A typical software system generally consists of distinct and independent subject matters. Each subject matter is called a Domain. A Shlaer-Mellor Object-Oriented Analysis (OOA) is developed for each of these subject matters.

OOA.Dom_Name

Full Name: Domain Name

Attribute Type: Base Attribute

Data Domain: string

Description: Since an OOA describes exactly one Domain, the Domain name can be used to uniquely identify the OOA.

OOA.Hi_VNum

Full Name: Highest OOA Version Number


Data Domain: integer

Description: This attribute serves to track the highest OOA Version number to be used for assignment of the OOA Version.OOA_VNum attribute upon creation of new instances of OOA Version.

o 902. Configuration (V_CONFIG)Configuration (Dom_Name, Confg_ID, Hi_VNum, Hi_IDVal)

Identifier *: Dom_Name, Confg_ID

Description: A Configuration is a piece of the OOA which is broken off and managed separately. A configuration can have multiple versions.

Configuration.Dom_Name

Attribute Type: Referential Attribute

Refers To: OOA.Dom_Name (R901)(See page 56)

Configuration.Confg_ID

Full Name: Configuration Identifier


Data Domain: unique_id

57

Description: This is an arbitrary identifier used to uniquely identify each configuration within an OOA.

Configuration.Hi_VNum

Full Name: Highest Configuration Version Number



Description: This attribute serves to track the highest Configuration Version number to be used for assignment of the Configuration Version.Con_VNum attribute upon creation of new instances of Configuration Version.

Configuration.Hi_IDVal

Full Name: Highest Identifier Values


Data Domain: string

Description: This attribute is used to track the used identifier values.

o 903. OOA Version (V_OOAVER)OOA Version (Dom_Name, OOA_VNum, Name, Abstract, Date, Creator)

Identifier *: Dom_Name, OOA_VNum

Description: An OOA Version is a snapshot of the OOA as it exists at a point in time. The OOA Version is made up of one version of each configuration in the OOA.

OOA Version.Dom_Name


Refers To: OOA.Dom_Name (R902)(See page 56)

OOA Version.OOA_VNum

Full Name: OOA Version Number




Description: This is an arbitrary identifier used to uniquely identify each OOA Version within an OOA.

OOA Version.Name

Full Name: OOA Version Name


Data Domain: string

OOA Version.Abstract

Full Name: OOA Version Abstract


Data Domain: string

OOA Version.Date

Full Name: OOA Version Creation Date


Data Domain: string

OOA Version.Creator

Full Name: OOA Version Creator


Data Domain: string

Description: This is the user who created the OOA Version.

o 904. Configuration Version (V_CONVER)Configuration Version (Dom_Name, Confg_ID, Con_VNum, Name,

Abstract, Date, Creator)

Identifier *: Dom_Name, Confg_ID, Con_VNum

Description: A Configuration Version is a snapshot of the Configuration as it exists at a point in time.

Configuration Version.Dom_Name


Refers To: Configuration.Dom_Name (R903)(See page 56)

59

Configuration Version.Confg_ID


Refers To: Configuration.Confg_ID (R903)(See page 56)

Configuration Version.Con_VNum

Full Name: Configuration Version Number



Description: This is an arbitrary identifier used to uniquely identify each Configuration Version within a Configuration.

Configuration Version.Name

Full Name: Configuration Version Name


Data Domain: string

Configuration Version.Abstract

Full Name: Configuration Version Abstract


Data Domain: string

Configuration Version.Date

Full Name: Configuration Version Creation Date


Data Domain: string

Configuration Version.Creator

Full Name: Configuration Version Creator


Data Domain: string

Description: This is the user who created the OOA Version.


o 905. Configuration in OOA Version (V_CIOV)Configuration in OOA Version (Dom_Name, OOA_VNum, Confg_ID)

Identifier *: Dom_Name, OOA_VNum, Confg_ID

Description: The Configuration in OOA Version is a correlation object that records what Configuration Versions are used in specific OOA Versions.

Configuration in OOA Version.Dom_Name


Refers To: Configuration.Dom_Name (R904)(See page 56)

Refers To: OOA Version.Dom_Name (R904)(See page 57)

Refers To: Configuration Version.Dom_Name (R905)(See page 58)

Configuration in OOA Version.OOA_VNum


Refers To: OOA Version.OOA_VNum (R904)(See page 57)

Configuration in OOA Version.Confg_ID


Refers To: Configuration.Confg_ID (R904)(See page 56)

Refers To: Configuration Version.Confg_ID (R905)(See page 59)

Configuration in OOA Version.Con_VNum


Refers To: Configuration Version.Con_VNum (R905)(See page 59)

Configuration in OOA Version.Abstract

Full Name: Configuration in OOA Version.Abstract


Data Domain: string

Description: This is a string that describes the Configuration in OOA Version. The information that is of interest here is the name of the Configuration as it is known in this OOA Version.

61

5.2.4.2 Relationship Descriptions

Ø R901Relationship Type: Simple

Multiplicity/Conditionality: M:1

OOA is made up of one or more Configurations

Configuration is part of on OOA

Formalized By: OOA.Dom_Name



OOA has one or more OOA Versions

OOA Version is a snapshot in time of OOA

Formalized By: OOA.Dom_Name



Configuration has one or more Configuration Versions

Configuration Version is a snapshot in time of Configuration

Formalized By: Configuration.Dom_Name, Configuration.Confg_ID

Ø R904Relationship Type: Associative

Multiplicity/Conditionality: 1-(M:Mc)

Configuration is part of zero, one, or more OOA Versions

OOA Version contains one version of each of one or more configurations

Formalized By: Configuration.Dom_Name, Configuration.Confg_ID, OOA Version.Dom_Name, OOA Version.OOA_VNum



Multiplicity/Conditionality: Mc:1

Configuration Version is part of one or more Configurations in OOA Version

Configuration in OOA Version includes one Configuration Version

Formalized By: Configuration Version.Dom_Name, Configuration Version.Confg_ID, Configuration Version.Con_VNum

63

5.3 Domain RepositoryAs a project progresses through its lifecycle, each domain OOA will progress through a lifecycle. A domain OOA lifecycle begins with creation of a Subsystem Partition Model (SPM), moves to creation of a set of Object Information Models (OIM) and Object Communication Models (OCM), and finally arrives at a set of State Models (SM) with Action Specifications.

When the project reaches its first release, a snapshot of the Domain OOA must be taken in the form of the OOA Version. This OOA Version must be capable of being re-created at any time in the Model Builder so that further editing can be made as problems are found in the field.

As the project delivers new revisions of the domain OOA to the field, a snapshot of an OOA Version must be made for each revision. This ensures re-creation if necessary.

BridgePoint is built on a powerful paradigm which is focused on deployment of multiple domain versions at various times. Once complete, domain OOAs do not change drastically (analysis is of the real world and the real world usually does not change). When the first production OOA Version is complete, it is unlikely that subsequent OOA Versions will be different.

An undesirable approach is to make disjoint copies of the OOA Versions as each revision of the product is produced. This results in maintenance of several disjoint OOA Versions that are nearly identical - a maintenance nightmare.

To address this issue, BridgePoint versions the domain OOA at the configuration granularity. If two OOA Versions are identical in all configurations except one, then the same Configuration Versions, except the one that is different, must be used in both OOA Versions.

5.3.1 Domain Repository Visibility from Model BuilderThe Domain Repository is transparent when utilizing Model Builder. Model Builder appears to be manipulating the OOA Database (x.ooa) only. In actuality, the OOA Database is a temporary copy of parts of the Domain Repository which allows the edit of specific configuration versions.


5.3.2 Domain Repository ContentThe Domain Repository contains a set of character based data and information files.

The following types of configurations exist within the Domain Repository:

• Configuration 0 - Used to store OOA Versions (i.e., Domain/Subsystem and State Model/Action Configuration Versions)

• Configuration 1 - Used to store Domain/Subsystem Configuration Versions

• Configuration 2, 3, 4,...511 - Used to store State Model/Action Configuration Versions

The same set of files exists for each Configuration created within the OOA:

• Configuration Data File - (one per configuration) Stores configuration information which is independent of the individual configuration versions.

• Version Information File - (one per configuration version) Stores information about the configuration version such as who created, when it was created, etc.

• Version Data File - (one per configuration version) Stores the data which represents the OOA which the user has captured.

Each file contains instances (records) of the objects (tables) listed in Table 5.3.TABLE 5.3 Contents of Domain Repository Files

The format of the contents of these files is SQL INSERT statements which represent instances (records) of objects (tables).

Files Configuration 0 Configuration 1 Configuration 2, 3... 511

Configuration Data File

V_OOA V_CONFIG V_CONFIG

Version Information File

V_OOAVER V_CONVER V_CONVER

Version Data File

V_CIOV

Full SQL data export ready for translation (fully derived OCM/OAM if on and no graphical data).

Domain/Subsystem Configuration Data which is all OOA of OOA Objects in ’Subsystem’, ’Object’, ’Relationship’, and ’Communication and Access’ Subsystems and graphical data for models.

State Model/Action Configuration Data which is all OOA of OOA Objects in ’State Model’ Subsystem and graphical data for models.

65

5.3.3 Default Domain RepositoryThe default Domain Repository is a simple directory structure created to store all of the Domain Repository files.

5.3.3.1 Domain Repository Directory Structure

The first level of directories is based around the configurations which exist in the OOA. One directory is created for each configuration (see Figure 5.13).

Figure 5.13 Domain Repository Directories

Note that the directory names are based on the configuration ID value. This is required since the configuration directory cannot be based on a name as names can change over the life of a project.

Within a configuration directory, a set of files exist:

• config_data - Contains data which is used internally by Model Builder.

• ver_N_data - One file for each version exists to store the data for that version. For example, if versions 1, 2, 3, and 4 existed, then they are represented by the files ver_1_data, ver_2_data, ver_3_data, and ver_4_data.

• ver_N_info - One file for each version exists to store information about the version. For example, if versions 1, 2, 3, and 4 existed, then

<domain_name>.rep config_0

config_1

config_2

config_511


.

tory

they are represented by the files ver_1_info, ver_2_info, ver_3_info, and ver_4_info.

• checked_out - While a configuration is checked out, this file serves as the lock file.

5.3.3.2 Domain Repository CommandsThe following commands are called by Model Builder to manipulate the Domain Repository:

• pt_check_in

• pt_check_out

• pt_config_create

• pt_config_data_get

• pt_config_data_put

• pt_config_exist

• pt_un_check_out

• pt_ver_data_audit

• pt_ver_data_get

• pt_ver_info_get

5.3.3.3 Using Default Domain RepositoryThe Domain Repository feature is designed for easy integration with external configuration management tools. Large projects will benefit substantially by integrating BridgePoint’s Domain Repository into their configuration management environment.

Small teams can utilize the Default Domain Repository. In order for this to beeffective, controls need to be instituted to prevent deletion of repository filesThese controls can vary from rules (ineffective technique) to directory permissions (more effective). A repository assumes all previous checked in versions remain in the repository. Therefore, any file deletion from the reposiwill cause unpredictable results.

67

5.3.4 Custom Domain RepositoryThe Domain Repository can be customized to tightly integrate with the Change Control System and/or Problem Tracking System already in place for your project source code and documents. See the appendix for details on how to customize the Domain Repository.


he sitory

User. els,

. A

base

(the g a

Anot

5.4 OOA Databases (x.ooa)OOA Databases are personal database files which are used to support building an OOA. The purpose of the OOA Database is to allow entry of a coordinated change for a short time frame. It is not the intent to use the OOA (personal) Databases for the lifetime of a multi-user project. The Domain Repository (See “Domain Repository”, page 63) is used for lifetime storage of the OOA.

Remember that the Domain Repository is a common area (shared) among tpersonal databases using that domain. The users access the Domain Repowhen the Version Management functions are used.

5.4.1 OOA Database AccessWhen an OOA Database is created, the user creating it is set up as the EditThe Edit User has the ability to check out models, edit models, check in modand create OOA Versions.

Any other user who loads that same x.ooa is only allowed in as a View UserView User has restricted “Read Only” browsing capabilities only.

5.4.1.1 OOA Database OwnershipWhen an OOA Database is created, the user creating it owns the OOA Datafile. In addition, the internal Edit User Workspace is set up for the user that created the OOA Database.

OOA Database file ownership can be changed by normal system commandsUNIX command chown) or by copying the OOA Database. However, copyindatabase will not allow write access to anyone other than the initial databasecreator.

Note: The Edit User is set for the lifetime of the OOA Database file. If an OODatabase is copied or the owner is changed, the Edit User will change to the new OOA Database file owner.

69

5.4.1.2 OOA Database PermissionsThe OOA Database is a standard UNIX file. Access to the OOA Databases is controlled through UNIX Read/Write file permissions.

The Edit User must have UNIX Read/Write access to a database file in order to create new versions of data via check-in and check-out mechanisms. If a user has read-only permission, the version management control widgets will not be shown.

5.4.2 OOA Database OperationsThe following operations are available in Model Builder to allow the analyst to manipulate the OOA Databases:

• Open x.ooa

• Create x.ooa from EXISTING Domain Repository

• Create x.ooa & Domain Repository for NEW Domain

5.4.2.1 Open x.ooaThis operation opens an OOA Database in Model Builder.

To Open x.ooa:

1. From the index window, MENU-Click on the File Button.

2. SELECT-Click on the Open x.ooa. A file chooser will appear.

3. Select the file for the x.ooa file. The file name of the file must take the form:

• <Domain_Name>.ooa

• <Domain_Name>__<id_string>.ooa

4. SELECT-Click on OK. The selected OOA Database will be opened in BridgePoint Model Builder.


5.4.2.2 Create x.ooa from EXISTING Domain RepositoryThis operation creates a new OOA Database file using data from an existing Domain Repository. The version of the data used from the Domain Repository is specified by selection of a previously saved OOA Version.

To Create x.ooa from EXISTING Domain Repository:


2. SELECT-Click on Create x.ooa from EXISTING Domain Repository. A file chooser will appear.

3. Specify a new OOA Database file name. The file name must take the form:



SELECT-Click on OK. The OOA Database is created and the underlying Domain Repository is consulted to determine which OOA Versions are available. This may take a few minutes to complete, depending on the underlying Domain Repository implementation. The window shown in Figure 5.14 will appear.

Figure 5.14 OOA Version List Window

4. Select the OOA Version from the OOA Version List. SELECT-Click on OK. The Configuration Versions in the OOA Version are imported into the OOA Database. The import may take several minutes to complete.

71

When this operation is complete, the configuration version named in the OOA version will be in the view.

5.4.2.3 Create x.ooa & Domain Repository for NEW DomainThe operation creates a new OOA Database and a New Domain Repository to be used for entry of the OOA of a New Domain.

To Create x.ooa & Domain Repository for NEW Domain:


2. SELECT-Click on Create x.ooa & Domain Repository for NEW Domain. A file chooser will appear.

3. Specify a new OOA Database file name. The file name must take the form:



SELECT-Click on OK.

When this operation is complete, a new OOA Database and Domain Repository will exist.

5.4.3 Configuration Version OperationsThe following operations are available from the index window to allow the analyst to manipulate the Configuration Versions:

• View Version

• Check-Out Latest Version From Domain Repository

• Check-Out Viewed Version

• Check-In Version

• Un-Check-Out Version

• Bring-In Version from Domain Repository

• Version Information


5.4.3.1 View VersionVersions build up in a chronological order as they are checked-in. The user can review previous versions, but cannot change them once they are checked-in. A previous version may be used, however, as a base when checking-out.

To View Configuration Version:

1. From the index window, select Configuration.

2. MENU-Click on the Version Stack Button located above and to the left of the Subsystems scrolling list. Note that the latest version number will always be directly next to the button.

3. SELECT-Click on the Version Number that you wish to view. Note, you will only have read access to all but the latest checked-out versions.

5.4.3.2 Check-out Latest Version from Domain RepositoryTo edit the SPM, SRM, SCM, SAM, OIM, OCM, or OAM, you must check-out the Domain/Subsystem Configuration.

To edit a State Model, State Transition Table, or Action Specification, you must check-out at the State Model/Action Configuration.

To Check-Out Latest Version from Domain Repository:

1. From the Index Window, select Configuration.

2. SELECT-Click on the Version Mgmt. button located above and to the left of the Subsystems scrolling list.

3. SELECT-Click on Check-Out Latest Version from Domain Repository.

Upon successful check-out, the version number n.1 appears beside the menu mark. Also, beside the version number, the check box contains a check-mark to indicate that the version is checked-out.

Since each Domain and all of its Subsystems are versioned together, you do not have to select a Subsystem from the scrolling list prior to check-out.

Only one user can check-out a given Domain/Subsystem at a time. All versions in the configuration are locked so that other users cannot check out a version in this configuration.

73

-in’ions.ationasge

fromionct

t.

the ion

e

Since each State Model and all of its Action Specifications are versioned together, you do not have to select an Action Specification from the scrolling list prior to check-out.

Only one user can check-out a given State Model/Action at a time. All versions in the configuration are locked so that other users cannot check out a version in this configuration.

Note: If a Configuration is already checked out and it needs to be checked backin (for example, if a user goes on vacation with a configuration checkedout), use the command pt_un_check_out in the <INSTALL_DIR>/bin directory to Un-Check-Out the configuration and to allow theCheck-Out operation to complete successfully.

Note: When checking-out the latest Version of a State Model/ActionConfiguration, the Configuration must first be brought in from theDomain Repository and then must be checked out. The ’Bringoperation may result in Action Language Parse Errors in some situatThe parse errors are sometimes due to differences in the ConfigurVersion View when the Action Language was originally parsed compared to the Configuration Version View when the Action Languais brought in. For example, if an Object Keyletter has been changed when the Action Language was originally parsed, then the ActLanguage parse during the ’Bring-In’ operation will fail since the ObjeKeyletters in the Action Specification being brought in no longer exis

5.4.3.3 Check-out Viewed VersionIf you need to check out a version which is not the latest, then you can viewversion to be checked out, and then use this option to check the viewed versout.

To Check-Out Viewed Version:


2. Select the desired Configuration Version. See “View Version” on pag72 and “Bring-In Version from Domain Repository” on page 75.


4. SELECT-Click on Check-Out Viewed Version.


5.4.3.4 Check-in VersionCheck-in Version is similar to the check-out version procedure.

Check-In Version:



3. SELECT-Click on Check-in Version. The window shown in Figure 5.15 will appear.

Figure 5.15 Configuration Version Information Window

4. Enter the name of the Configuration Version and the Abstract of the Configuration Version. This information is strictly for the user to track versions by more than just numbers. SELECT-Click on OK. This version will be checked into the Domain Repository as well.

Note: If a Configuration Version is Not Checked-out in the Domain Repository,then this operation will check the Configuration Version out and informthe user to repeat the check-in operation or perform an un-check-outoperation.

5.4.3.5 Un-check-out VersionAt any time during a model editing session, you can Un-Check-Out the current version. This DESTROYS ALL CHANGES made to the models since the last check-out.

75

Un-Check-Out Version:



3. SELECT-Click on Un-Check-Out Version. A warning will appear.

4. SELECT-Click on Yes.

Note: If a Configuration Version is Not Checked out in the Domain Repository,then this operation will check the Configuration Version out and informthe user to repeat the check-in operation or perform a check-in operation.

5.4.3.6 Bring-In Version from Domain RepositoryYou may need to Bring-In a version of a model which another user has created in a different OOA Database.

To Bring-in Version from Domain Repository:



3. SELECT-Click on the Bring-In Version from Domain Repository. The Domain Repository is queried for a list of versions not correctly loaded in the x.ooa. The window shown in Figure 5.16 will appear.


ailt in

Figure 5.16 Configuration Version List Window

4. Select the Configuration Version you desire to bring in from the Domain Repository. SELECT-Click on OK. The version is imported and is available for browsing.

Note: Bring-In Version for the Domain/ Subsystem Configuration re-creates thespecified configuration version exactly.

Note: Bring-In Version for the State Model/Action Configuration does notnecessarily re-create the specified configuration exactly. The State Model/Action configuration cannot be re-created exactly if OOAElements referred to from the actions within the state model are notpresent in other configurations. For example, if an Object Keyletter hasbeen changed from when the Action Language was originally parsed,then the Action Language parse during the ’Bring-In’ operation will fsince the Object Keyletters in the Action Specification being broughno longer exist.

77

5.4.3.7 Version InformationThe following Version Information is available from the index window.

• Configuration Identifier

• Version Number

• Version Name

• Version Abstract

• Creation Date and Time

• User responsible for creation

To View Version Information for Configuration:

1. Select the Configuration you wish to view.


3. SELECT-Click on the Version Information. A window will appear with the version information.

5.4.4 OOA Version OperationsThe following operations are available in Model Builder to allow the analyst to manipulate the OOA versions:

• View Configuration Version

• Bring-in Version

• Save View as OOA Version

• Create x.ooa from EXISTING Domain Repository

5.4.4.1 View Configuration VersionView can be used to modify the Configuration View and assemble a specific view of the OOA so that it is ready to snapshot as an OOA Version. See “View Version” in section 5.4.3.1.


ed as s

5.4.4.2 Bring-In VersionBring-In Version can be used to modify the Configuration View in order to assemble a specific view of the OOA and prepare it for snapshot as an OOA Version. See “Bring-In Version from Domain Repository” in section 5.4.3.6.

5.4.4.3 Create OOA Version from Configuration Version ViewOnce a view of the OOA has been assembled in Model Builder, it can be savan OOA Version. An OOA Version is simply a list of the configuration versionwhich make up the OOA Version at any point in time.

To Create an OOA Version View from Configuration View:

1. Select the desired view of each Configuration Version from the OOAVersion (see “View Version” in section 5.4.3.1 and “Bring-In Version from Domain Repository” in section 5.4.3.6).

2. MENU-Click on OOA Version.

3. SELECT-Click on Create OOA Version from Config Version View located above and to the left of the Subsystems scrolling list. The window shown in Figure 5.17 will appear.

Figure 5.17 OOA Version Information Window

4. Fill in the OOA Version name and abstract by which it will be identified. SELECT-Click on OK. A warning notice will appear letting you know that a full export will take place and that the operation willtake a few minutes to complete.

79

a

5. SELECT-Click on OK. This operation automatically does a check-out and check-in of configuration 0 to save the list of configuration versions currently being viewed.

6. SELECT-Click on OK. The operation is complete.

5.4.4.4 Create x.ooa from EXISTING Domain RepositoryThis operation creates a new OOA Database file using data from an existing Domain Repository. The version of the data used from the Domain Repository is specified by selection of a previously saved OOA Version. See “Create x.oofrom EXISTING Domain Repository” in section 5.4.2.2.

CHAPTER 6:

License Management

Licenses for Model Builder/Model Verifier are network floating licenses that are generally available to anyone on the network that can reach the server. For each license purchased, one concurrent usage of Model Builder/Model Verifier is allowed.

If all the licenses are in use when a user invokes Model Builder/Model Verifier, then a list of all the current users, their workstation, and their start times will printed to the screen and then Model Builder/Model Verifier will exit.

Model Builder/Model Verifier enforces a minimum hold period of 2 minutes after a user has exited. This allows a user to exit one session of Model Builder/Model Verifier and start another without the fear of losing the license. If the user has not started a new Model Builder/Model Verifier session within 2 minutes, then the license returns to the free license pool.

6.1 Available CommandsThere are a number of available commands to administer license management. The following commands are in the INSTALLDIR/BridgePoint/bin and INSTALLDIR/BridgePoint/admin directories. Full manual pages for these commands are online under directory INSTALLDIR/BridgePoint/man.

82 License Management

pt_lm_admin is a general purpose administration process. Typical uses are:

pt_lm_admin -l

list all current users holding licenses

pt_lm_admin -b

kill a Model Builder/Model Verifier session (root use only)

pt_lm_admin -k

kill the license manager (root use only)

pt_lm_notify is used to notify clients of available resources. This could be used if all licenses are in use and a new user wants to be notified when a license is available. Note that the feature name is analyst. Typical uses are:

pt_lm_notify -f -m analyst

get mail when a license is available

pt_lm_notify -f -o 80

get mail when 80% of licenses are in use

pt_lm_passwd is used by root to install a new password. New passwords will be issued to change the number of licenses available. There are no parameters.

pt_lm_report is used to print a report of the number of licenses granted and denied. Uses are:

pt_lm_report

print summary since installation

pt_lm_report -d daterange

print daily report

pt_lm_usage outputs the current number of licenses active versus available. The process loops forever printing out this information every 10 seconds.

83

ns an

n. hen

the up, n a

ol.

ense

rom ly

6.2 Resource FileThere exists a resource file that can customize some of the properties of license management. The resource file exists under file INSTALLDIR/<platform>/lm_server/logdir/resource_file. The file is ascii and can be modified with a text editor. See the full manual page on the description of the resource file, ELM_RESOURCE(5), when modifying the resource file. Note that the feature name for Model Builder is “01”, for BridgePoint Generator is “02”, for BridgePoint Model Verifier is “03”, and for evaluation of all 3 is “99”.

The file is used to specify reserved licenses, held license periods and contaiaddress mask for security.

Licenses may be reserved for an individual, group or to a specific workstatioThe number of reserved licenses are taken away from the free license pool. Wan individual, group or workstation with a reserved license needs a license, license will come from the reserved amount. If the reserved amount is used the license will come from the free pool of licenses. An individual that is not ireserved license group cannot utilize a reserved license. The resource file defaults to no reserved licenses, where all licenses are in the free license po

The held license period is the time that a license is not returned to the free licpool after Model Builder is exited. The default for this time is 2 minutes. Thetime may be increased for individuals, groups, workstations or all users.

The address mask is used to prevent license requests from being honored fdifferent networks or from different subnetworks. The default resource file onallows requests from the same network.

84 License Management

CHAPTER 7:

Exchanging Data

BridgePoint Model Builder is able to export and import various text files in order to exchange data between versions of BridgePoint software and other CASE tools.

BridgePoint Model Builder can import text files containing data in the CDIF (CASE Data Interchange Format) format for the Entity Relationship Diagrams and State Transition Diagrams. Model Builder can also export and import text files containing data in the SQL format for the BridgePoint OOA of OOA.

7.1 CDIF Import BridgePoint Model Builder allows Entity Relationship Diagrams and State Transition Diagrams to be imported into the Object Information Model Editor and State Model Editor. Use of this feature can facilitate the conversion of models from other CASE tools to BridgePoint Model Builder.

86 Exchanging Data

7.1.1 CDIF Import of Entity Relationship DiagramsIn order for BridgePoint Model Builder to recognize CDIF Entity Relationship Diagrams such as an OIM, users must ensure that the placement and direction of the arrows on relationship lines are consistent with Figures 7.1, 7.2, and 7.3.

Figure 7.1 CDIF Associative Relationships

Figure 7.2 CDIF Simple Relationships

87

Figure 7.3 CDIF Subtype/Supertype Relationships

The procedure for importing CDIF Entity Relationship Diagrams is:

1. Open an OIM Model Window from the Index window. This OIM should be void of any objects and relationships.

2. Select-Click the File Menu. The Model Window File Menu will appear.

3. Select-Click the Import menu item. A pull-right menu will appear.

4. Select-Click the CDIF menu item. A file chooser will appear.

5. Choose the file which contains a CDIF description of the Entity Relationship Diagram which you want to import.

Note: This operation may take several minutes.

Since the CDIF Entity Relationship Diagram description does not contain enough information to determine relationship formalization, you must manually formalize relationships once the CDIF import is complete.

88 Exchanging Data

7.1.2 CDIF Import of State Transition DiagramThe procedure for importing CDIF State Transition Diagrams is:

1. Open an SM Model Window from the Index window. This SM should be void of any events, states, and transitions.

2. Select-Click the File Menu. The Model Window File Menu will appear.


4. Select-Click the CDIF menu item. A file chooser will appear.

5. Choose the file which contains a CDIF description of the State Transition Diagram which you want to import.

Note: This operation may take several minutes.

Since the CDIF State Transition Diagram description does not contain enough information to determine event signatures, you must manually create events and assign them to transitions.

7.2 SQL Export and Import of BridgePoint OOA of OOABridgePoint Model Builder is internally based on the BridgePoint OOA of OOA which is published in the manual describing code generation. BridgePoint Model Builder is able to export and import all information needed to reconstruct your OOA Model as a set of instances of the OOA of OOA Objects.

The OOA of OOA Objects are exported as SQL Tables (via the SQL CREATE TABLE statement). The OOA of OOA Object instances are exported as SQL records (via the SQL INSERT statement).

Information in the Communication and Access Subsystem of the OOA of OOA create a need for two types of exports. The Communication and Access Subsystem is used to capture all information about the Object Communication Model (OCM) and Object Access Model (OAM). BridgePoint Model Builder supports two modes for entry of the OCM and OAM:

• Normal Mode: The analyst manually draws the communication/access paths and manually selects the events/attributes which are associated with the paths.

• Derived Mode: BridgePoint Model Builder automatically draws the communication/access paths and automatically selects the events/

89

attributes which are specified in the Action Specifications of each State Model.

The analyst is free to switch between modes on demand. This presents a problem for export: Which information is exported? If the ’Normal’ mode information is always exported, then it may not be correct since the user is not required to keep it up to date with the state models (correctness of data is important when the data is used as input to translation). If the ’Derived’ mode information is always exported, then the ’Normal’ mode information will be lost.

This problem has been solved by providing two types of export:

• Backup: Always exports the ’Normal’ mode information for the Communication and Access Subsystem. No loss of data since the ’Derived’ mode information can be re-derived from the Action Specifications once the OOA Model has be imported back into BridgePoint Model Builder.

• SQL: Always exports the mode which the user is currently viewing in BridgePoint Model Builder. This provides the most ’correct’ view of the data and is suitable for translation input for automatic source code or documentation production.

In order to manage the export files of each type, the user should use the following naming convention for export files:

• Backup: file suffix must be ’.bak’

• SQL: file suffix must be ’.sql’

In addition, BridgePoint Generator enforces the naming convention by requiring input files with the suffix ’.sql’.

7.2.1 Exporting a Backup File1. Select-Click the SPM button on the Index Window. A pull-down menu

will appear.

2. Select-Click the Export menu item. A pull-right menu will appear.

3. Select-Click the Backup menu item. The backup will be performed. The output file will be available in the file <domain_name>1.bak in the directory specified in the “Backups” User Preference.

90 Exchanging Data

7.2.2 Exporting an SQL File1. Select-Click either the SPM button, OIM button, or SM button on the

Index Window. A pull-down menu will appear.

Selecting from the SPM button will cause all subsystems, state models, and actions to be exported. Selecting from the OIM button will cause the selected subsystem, state models from the selected subsystem, and actions from the selected subsystem to be exported. Selecting from the SM button will cause the selected state model and actions from the selected state model to be exported.

2. Select-Click the Export menu item. A pull-right menu will appear.

3. Select-Click the SQL menu item. Export Window will appear.

4. Fill out the export file name and indicate if you would like to export graphical data and if you would like to export the schema only.

Note: Most translation does not make use of graphical data so not includinggraphical data in the export reduces the amount of data and speedstranslation performance.

7.2.3 Importing a Backup File1. Make sure the Domain/Subsystem Configuration is checked out (Import

will write information into this configuration so it needs to be checked out.)

2. Select-Click the SPM button on the Index Window. A pull-down menu will appear.


4. Select-Click the Backup menu item. A file chooser will appear.

5. Choose the backup file to be imported. The file chooser only allows selection of files with the suffix ’.bak’. BridgePoint Model Builder will import the file into the current domain.

Note: The import may take several minutes, depending on the size of the datafile being imported.

91

The data imported will be added to the data which is already present. An effective technique for recreation of a domain without extra data is:

1. Select-Click on the Index Window File Menu. The File Menu will appear.

2. Select-Click on the Create x.ooa & Domain Repository for NEW Domain menu option. A file chooser will appear.

3. Choose the x.ooa file name where x is the domain name. A new x.ooa file will be created and will be selected on the Index Window.

4. Select-Click on the Domain/Subsystem Configuration Version Mngt. The Version Stack will appear with Version 1.0 and Version 2.0 in the stack.

5. Select-Click on Version 1.0.

6. Select-Click on the Domain/Subsystem Configuration Version Mngt menu button. The version management menu will appear.

7. Select-Click on the Check-Out Viewed Version menu option. Model Builder will check out Version 1.0.

8. Follow the IMPORTING A BACKUP FILE procedure above.

7.2.4 Importing an SQL File1. Select-Click either the SPM button, OIM button, or SM button on the

Index Window. A pull-down menu will appear.

Selecting from the SPM button will cause import into the selected domain. Selecting from the OIM button will cause import into the selected subsystem. Selecting from the SM button will cause import into the selected state model.


3. Select-Click the SQL menu item. A file chooser will appear.

4. Fill out the import file name. The file chooser only allows selection of files with the suffix ’.sql’. BridgePoint Model Builder will import the file into the current selected level.

92 Exchanging Data

7.3 Importing old BridgePoint .ooa filesPlease read the release notes for current conversion techniques for previous versions of .ooa files. If the release notes do not cover your specific version of .ooa files, please contact your system administrator or BridgePoint customer support.

APPENDIX A:

Solaris 2.x Platform Guide

A.2

uld

What Sections Should You Read?If you are installing BridgePoint software for the first time, then you should follow Section A.1 “Installation Requirements for Solaris 2” on page 94, and Section“First Time Installation Procedure for Solaris 2” on page 95. This typically includes anyone who is evaluating the products.

If you are upgrading from an existing BridgePoint software installation you shoreview Section A.1 “Installation Requirements for Solaris 2” on page 94 and follow Section A.3 “Upgrade Installation” on page 103.

What Does The BridgePoint Software Include?The BridgePoint family of products includes three products:

• BridgePoint Model Builder (pt_builder)

• BridgePoint Model Verifier (pt_verifier)

• BridgePoint Generator (pt_gen_import, pt_gen_file)

BridgePoint software has a client/server architecture. The server runs a database manager and performs license checks. The client runs the pt_builder, pt_verifier, pt_gen_import, and pt_gen_file processes. There is one server and multiple

94 Solaris 2.x Platform Guide

clients. The maximum number of clients is controlled by a concurrent license manager.

KeywordsThe following keywords are used throughout this Appendix:

INSTALLDIR - Installation directory where the BridgePoint directory will be placed.

HOSTNAME - Name of the UNIX machine.

MOUNTPOINT - UNIX mount point.

A.1 Installation Requirements for Solaris 2

System RequirementsThis release of BridgePoint software supports SUN workstations running Solaris 2.4.

Disk SpaceTo successfully install BridgePoint software, your system must have the following:

• at least 65 megabytes of free disk on the server to store the BridgePoint products. The BridgePoint load must physically reside on the server. This disk space must be accessible via NFS to all client machines.

• at least 16 megabytes of swap space for each invocation of BridgePoint Model Builder or BridgePoint Model Verifier on each of the client workstations. For each invocation of BridgePoint Generator, at least 6 megabytes is needed. These swap space requirements are in addition to the existing swap space requirements from the operating environment and other applications.

• at least 4.5 megabytes of free disk on each of the client workstations for cache space for each concurrent invocation of any of the BridgePoint products. For example, if both BridgePoint Model Builder and

95

it one

BridgePoint Model Verifier were run at the same time, 9 megabytes of free disk is needed for cache space. The disk space defaults to a location under /tmp, but may be changed during the installation procedure.

• sufficient disk space on the server to hold the OOA, SIM, and GEN databases. Ballpark estimates for allocation are 1 megabyte per OOA database (1 domain/OOA database), 1 megabyte per SIM database (1 test scenario/SIM database), and 1 megabyte per GEN database (1 domain/GEN database). Note that as of the 3.2 release, each user has his/her own personal OOA database.

• sufficient disk space to hold the Domain Repository. This disk allocation is not required to reside on the server, but must be accessible via NFS from the server and all clients. Ballpark estimates for the Domain Repository are 5 MB per OOA domain. The location of the Domain Repository defaults to the BridgePoint installation directory, but this can be changed during installation.

Memory SpaceA minimum of 32 megabytes of memory is required on the Sun on the server and each of the clients that will run BridgePoint products.

A.1.1 Pre-Installation

Pre-Installation Instructions:If you haven’t already received a password from Project Technology, Inc. support, call our support at 800-482-3853 with the following information:

IP address: $ ypcat hosts | grep <your server>hostid: $ hostid

The Project Technology password will be a 21 digit number, similar to a credcard number. The password will be asked for during the server installation din Section A.2.2 “Performing Installation Step On the Server” on page 97.

A.2 First Time Installation Procedure for Solaris 2


A.2.1 Loading BridgePoint Files

Loading Files

1. Log into workstation with the tape drive. You may log in as either root or a normal ID for the steps in this section to read in the files. Note that files will be created the ID of the log in used.

2. Physically insert tape.

3. Change directory to your installation directory (referred to as INSTALLDIR from now on). All the files will be read in under INSTALLDIR/BridgePoint. The installation directory should physically reside on the workstation where you will run the database and license manager server.

$ cd INSTALLDIR

4. Verify permissions are writable in INSTALLDIR by the current login.

$ ls -ld

97

5. Verify that INSTALLDIR has enough free disk space. The disk space required for reading in tape and operating the server is 60 Mbytes.

$ df

6. Read in the tape.Files will come in with current login permissions. A listing of all files read in will come out on stdout.

All files read in will be INSTALLDIR/BridgePoint.

$ tar xvf <tape dev device>

A.2.2 Performing Installation Step On the Server

Server Installation

1. Login as root to the workstation acting as the BridgePoint server. This is the workstation whose physical disk contains INSTALLDIR.

$ su - root

2. Make INSTALLDIR the present working directory.

$ cd INSTALLDIR/BridgePoint

3. Verify that the server has adequate /tmp space to be used for database cache if a BridgePoint product is run directly on the server. Four Mbytes are needed (only taken if a user of BridgePoint works on the server). If there is enough room, then proceed to step 5.

$ df /tmp

4. Perform this step only if you are putting the database cache in a directory other than /tmp. HOSTNAME used below is the name of the server. Use the UNIX hostname command to determine this.

$ cd INSTALLDIR/BridgePoint/sol2/dbserver/etc$ cp squid_cache_manager_parameters HOSTNAME_cache_manager_parameters

$ vi HOSTNAME_cache_manager_parameters

Change /usr/cache_dir on both lines to the directory chosen to hold the


cache. Make sure the directory is physically on the disk resident on the server.

5. Choose the installation option. There are two installation options: default or full_server.

The default option will keep the default location of the Domain Repository under INSTALLDIR/BridgePoint/repository. The installation script will not ask any questions. This is the option recommended for evaluations.

The full_server option will allow the installer to select a different location for the Domain Repository.

The installation scripts will automatically create shell scripts and will automatically start the database and license servers.

For the default installation, continue on to step 6. For the full_server installation, go to step 7.

6. Perform the default installation:

# cd INSTALLDIR/BridgePoint

#./ install_script. . .

The database server is running.

Input password provided or call Project Technology, Inc. supportat 800-482-3853 to get a password.

Please enter your key:

At this point, enter in the key provided to you by Project Technology. After doing so, you should receive the following message:

99

Feature name: <product>[xx]Number of licenses: xExpiration date: xxx xxx xx xx:xx:xx 199x (xx.x days from now)

Successfully installed key in /INSTALLDIR/BridgePoint/sol2/lmserver/keydir/xx.lic.

Proceed to step 8.

7. Perform the full_server installation:


# ./ install_script full_server

Enter the Full Pathname to Locate the Domain Repository [default to INSTALLDIR/BridgePoint/repository]

At this point, input the full pathname where to locate the Domain Repository. See the discussion on the Domain Repository in Section A.1.

Would you like to copy the sample OOA ODMS to this Domain Repository? [Yes|No]

Enter yes if you want to examine the sample OOA.

Enter the Default Permissions Level for the Domain Repository (GROUP is suggested default) [USER|GROUP|WORLD]

This sets the Unix file permissions for the Domain Repository. GROUP or WORLD access is required if multiple users need access to the repository.





se ded



Key successfully installed in /INSTALLDIR/BridgePoint/sol2/lmserver/keydir/xx.lic.

8. If you have additional product keys to install:# cd INSTALLDIR/BridgePoint/admin# ./pt_lm_passwd

Follow the instructions to enter your additional keys.

9. Done with root. Done with Installation on the Server.$ exit

A.2.3 Performing Installation Step On Each Client

Client Installation

1. Verify that the client can access the file system which contains INSTALLDIR. In the mount command output, look for the file system containing INSTALLDIR. If the mountpoint on the client is different than the mountpoint on the server, the users of this client workstation must set the UNIX environment variable $PT_HOME. See step 3 in Section A.2.4 “Providing Access To The User Community” on page 101. If the mountpoint of INSTALLDIR is not mounted on the client, then mount it before proceeding.

$/etc/mount

2. Verify that the client has adequate /tmp space - to be used for databacache if a BridgePoint product is run on the client. 4.5 Mbytes are neefor each BridgePoint product executed concurrently. If there is enoughroom, then you are done with this client.

101

$ df /tmp

3. Perform this step only if you are putting the database cache in a directory other than /tmp. HOSTNAME used below is the name of the client. Use the UNIX hostname command to determine this.

$ hostname$ cd INSTALLDIR/BridgePoint/sol2/dbserver/etc $ cp squid_cache_manager_parameters HOSTNAME_cache_manager_parameters


Change /usr/cache_dir on both lines to the directory chosen to hold the cache. Make sure the directory is physically on the disk resident on the local client.

A.2.4 Providing Access To The User Community

Providing Access

1. The executable BridgePoint processes are located in INSTALLDIR/BridgePoint/bin.

Make sure each user puts INSTALLDIR/BridgePoint/bin on his/her $PATH.

2. The online manual pages for the BridgePoint products are located under INSTALLDIR/BridgePoint/man.

If users want access to these online manual pages, then have users add INSTALLDIR/BridgePoint/man to their $MANPATH.

3. If the NFS pathname for INSTALLDIR is different on the server than on a client, all users of that client must set and export the UNIX variable $PT_HOME to the NFS pathname for INSTALLDIR/BridgePoint.For example:

If INSTALLDIR on the server is /usr/tools


and the client mounts (either hard mount or automount) server: /usr/tools to client: /tool

Then, users on the client must set and export PT_HOME to /tool/BridgePoint.

A.2.5 Modifications To The Server Boot Sequence

Server Boot Sequence Modifications

1. Login as root on the server.

$ su - root

2. BridgePoint depends on an underlying Database server and License management server to be started at boot time on the server. A boot start up script must be linked into the /etc/rc2.d directory to accomplish this.

# cd /etc/rc2.d # ln -s INSTALLDIR/BridgePoint/admin/rc.pt S80BridgePoint

103

A.3 Upgrade InstallationIf you are upgrading from an existing BridgePoint release, the BridgePoint servers and applications from the prior release must be shut down and system configuration information copied into the new release.

Special note for the upgrade to the 3.2 release from 3.0.0 or 3.0.1: Installation directory and file names have changed to reflect to ownership of BridgePoint by Project Technology. The following has changed:

• INSTALLDIR/objective is now INSTALLDIR/BridgePoint

• All obj_* scripts are now pt_* scripts.

• The names of the BridgePoint applications have changed.

• analyst --> pt_builder

• sim_ooa --> pt_verifier

• gen_import --> pt_gen_import

• gen_file --> pt_gen_file

A.3.1 Preparation for Upgrade Process1. In BridgePoint Model Builder (analyst), analysts should perform an

export of all domain (.ooa files) using SQL format (with graphical data included). These exports will be reimported into the upgraded release of Model Builder.

A.3.2 Upgrade Process2. Work as root.

$ su -

3. Verify that no users are using any of the BridgePoint products.# INSTALLDIR/objective/admin/obj_lm_admin -l


es”

had

ill ers.

d. ous

hine

Note: script name is obj_lm_admin on the prior release. On the 3.2 release the script name will be pt_lm_admin.

4. Stop the database server and the license manager sever.# INSTALLDIR/objective/admin/obj_stop_servers

5. Read in the new BridgePoint release from the tape.# cd INSTALLDIR# tar xvf <tape device>

Note: This is the same step as Section A.2.1 “Loading BridgePoint Filon page 96.

6. Copy over all customer database server files. These files exist if youto move the location of cache directory on the server or anyone of theclients.# cd OLDINSTALLDIR/objective/sol2/dbserver/etc # cp *cache_manager_parameters INSTALLDIR/BridgePoint/sol2/dbserver/etc

7. Copy over all the BridgePoint licenses. # cd OLDINSTALLDIR/objective/sol2/lmserver/keydir# cp * INSTALLDIR/BridgePoint/sol2/lmserver/keydir

8. Run the new release installation script. Goto step 6 in Section A.2.2 “Performing Installation Step On the Server” on page 97. This step wstart the new release’s version of database and license manager serv

A.3.3 Providing Access To The User Community1. User should reset their $PATH variables to access the BridgePoint loa

Users can still use the BridgePoint application products from the previload, if they desire, by keeping their $PATH the same. The previous application processes can work with the new servers.The file OLDINSTALLDIR/objective sol2/dbserver/etc/ports must be removed if the previous application products are to be run on the macrunning the new servers.

105

$ setenv PATH INSTALLDIR/BridgePoint/bin:$PATH <csh>$ PATH=INSTALLDIR/BridgePoint/bin:$PATH <sh, ksh>

2. If users have defined UNIX environmental variables $OBJECTIVE_HOME and $OBJECTIVE_PWD, they must now use $PT_HOME and $PT_OOA_DIR respectively.

A.3.4 Modifications To The Server Boot Sequence1. Since the installation directory has changed to INSTALLDIR/BridgePoint

from INSTALLDIR/objective, you must find the BridgePoint entry in the /etc/rc file and make the changes from Section A.2.5 “Modifications ToThe Server Boot Sequence” on page 102.

APPENDIX B:

HPUX Platform Guide

ho

uld

What Sections Should You Read?If you are installing BridgePoint software for the first time, then you should follow Section B.1 “Installation Requirements for HP” on page 108, and Section B.2“Installation Procedure for HP” on page 111. This typically includes anyone wis evaluating the products.

If you are upgrading from an existing BridgePoint software installation you shoreview Section B.1 “Installation Requirements for HP” on page 108 and followSection B.3 “Upgrade Installation” on page 118.

What Does The BridgePoint Software Include?The BridgePoint family of products includes three products:

• BridgePoint Model Builder (pt_builder)

• BridgePoint Model Verifier (pt_verifier)

• BridgePoint Generator (pt_gen_import, pt_gen_file)

BridgePoint software has a client/server architecture. The server runs a database manager and performs license checks. The client runs the pt_builder, pt_verifier,

108 HPUX Platform Guide

pt_gen_import, and pt_gen_file processes. There is one server and multiple clients. The maximum number of clients is controlled by a concurrent license manager.

KeywordsThe following keywords are used throughout this Appendix:

INSTALLDIR - Installation directory where the BridgePoint directory will be placed.

HOSTNAME - Name of the UNIX machine.

MOUNTPOINT - UNIX mount point

B.1 Installation Requirements for HP

System RequirementsThis release of BridgePoint supports HP workstations running HPUX 9.0.5 or higher.

Note: HP-Cluster environments are not supported by the BridgePoint software.If you have this environment, please call customer support.

Disk SpaceTo successfully install BridgePoint, your system must have the following:

• at least 65 megabytes of free disk on the server to store the BridgePoint products. The BridgePoint load must physically reside on the server. This disk space must be accessible via NFS to all client machines.

• at least 16 megabytes of swap space for each invocation of BridgePoint Model Builder or BridgePoint Model Verifier on each of the client workstations. For each invocation of BridgePoint Generator, at least 6 megabytes is needed. These swap space requirements are in addition to

109

the existing swap space requirements from the operating environment and other applications.

• at least 12 megabytes of free disk on each of the client workstations for cache space for each concurrent invocation of any of the BridgePoint products. For example, if both BridgePoint Model Builder and BridgePoint Model Verifier were run at the same time, 24 megabytes of free disk is needed for cache space. The disk space defaults to a location under /tmp, but may be changed during the installation procedure.

• sufficient disk space on the server to hold the OOA, SIM, and GEN databases. Ballpark estimates for allocation are 1 megabyte per OOA database (1 domain/OOA database), 1 megabyte per SIM database (1 test scenario/SIM database), and 1 megabyte per GEN database (1 domain/GEN database). Note that as of the 3.2 release, each user has his/her own personal OOA database.

• sufficient disk space to hold the Domain Repository. This disk allocation is not required to reside on the server, but must be accessible via NFS from the server and all clients. Ballpark estimates for the Domain Repository are 5 MB per OOA domain. The location of the Domain Repository defaults to the BridgePoint installation directory, but this can be changed during installation.

Memory SpaceA minimum of 32 megabytes of memory is required on the HP on the server and each of the clients that will run BridgePoint products.

B.1.1 Pre-Installation

Pre-Installation Instructions

1. For HP-UX 9.05 based systems, two HP-UX patches are required. The patch numbers are different based on the specific load level. To determine which patch numbers to request, run the following command:

$ grep fv /system/UX-CORE/index


nc. n:

a

PATCH TABLE

Use your existing HP maintenance channel to get these patches. These patches must be loaded on the server and each of the client workstations.

2. This is an optional step to modify the kernel parameters to optimize system performance. The following kernel parameters are recommendations. Use SAM (System Administration Manager) with the Kernel Configuration --> Configurable Parameters to verify/modify. maxdsiz 134217728 maxssiz 16777216 maxtsiz 134217728 shmmax 67108864

3. If you haven’t already received a password from Project Technology, Isupport, call our support at 800-482-3853 with the following informatio

IP address - $ ypcat hosts | grep <your server> hostid - $ uname -i

The Project Technology password will be a 21 digit number, similar tocredit card number. This password will be asked for during the serverinstallation done in Section B.2.2 “Performing Installation Step On theServer” on page 112.

9.05 (base) 9.05.1M

PHKL_4937 PHKL_5165

PHKL_3798 PHKL_5049

111

B.2 Installation Procedure for HP

B.2.1 Loading BridgePoint Files

Loading Files

1. Log into workstation with the tape drive. You may log in as either root or a user id for the steps in this section to read in the files. Note that files will be created in the user id of the login used.

2. Physically insert tape.

3. Change directory to your installation directory (referred to as INSTALLDIR from now on). All the files will be read in under INSTALLDIR/BridgePoint. The installation directory should physically reside on the workstation where you will run the database and license manager server.

$ cd INSTALLDIR

4. Verify permissions are writable in INSTALLDIR by the current login.

$ ls -ld

5. Verify that INSTALLDIR has enough free disk space. The disk space required for reading in the tape and operating the server is 65 Mbytes.

$ bdf INSTALLDIR

6. Read in the tape.

Files will come in with current login permissions. A listing of all files read in will come out on stdout.

All files read in will be INSTALLDIR/BridgePoint.

$ tar xvf <tape dev name>


B.2.2 Performing Installation Step On the Server

Server Installation

1. Login as root to the workstation acting as the BridgePoint server. This is the workstation whose physical disk contains INSTALLDIR.

$ su - root

2. Make INSTALLDIR the present working directory.


3. Verify that the server has adequate /tmp space to be used for database cache if a BridgePoint product is run directly on the server. 4.5 Mbytes are needed (only taken if a user of BridgePoint works on the server). If there is enough room, then proceed to step 5.

# bdf /tmp

4. Perform this step only if you are putting the database cache in a directory other than /tmp. HOSTNAME used below is the name of the server. Use the UNIX hostname command to determine this.

# cd INSTALLDIR/BridgePoint/hpux/dbserver/etc# cp squid_cache_manager_parameters HOSTNAME_cache_manager_parameters

# vi HOSTNAME_cache_manager_parameters

Change /usr/cache_dir on both lines to the directory chosen to hold the cache. Make sure the directory is physically on the disk resident on the server.

5. Verify that there is a console running on the server. Subsequent steps will generate output into the console and if the console does not exist, the messages will output on the screen.

To get to a console window:

A. Bring up the General ToolboxB. Select UtilitiesC. Select Console

6. Choose the installation option. There are two installation options: default or full_server.

113

The default option will keep the default location of the Domain Repository under INSTALLDIR/BridgePoint/repository. The installation script will not ask any questions. This is the option recommended for evaluations.

The full_server option will allow the installer to select a different location for the Domain Repository.

The installation scripts will automatically create shell scripts and will automatically start the database and license servers.

For the default installation, continue on to step 7. For the full_server installation, go to step 8.

7. Perform the default installation:


# ./install_script. . .






Successfully installed key in /INSTALLDIR/BridgePoint/hpux/lmserver/keydir/xx.lic.


Proceed to step 9.

8. Perform the full_server installation:


# ./install_script full_server

Enter the Full Pathname to Locate the Domain Repository [default to INSTALLDIR/BridgePoint/repository]

At this point, input the full pathname where to locate the Domain Repository. See the discussion on the Domain Repository inSection B.1.

Would you like to copy the sample OOA ODMS to this Domain Repository? [Yes|No]

Enter yes if you want to examine the sample OOA.

Enter the Default Permissions Level for the Domain Repository (GROUP is suggested default) [USER|GROUP|WORLD]

This sets the Unix file permissions for the Domain Repository. GROUP or WORLD access is required if multiple users need access to the repository.





Feature name: <product> [xx]Number of licenses: x

115

f

e ded

tory e

Expiration date: xxx xxx xx xx:xx:xx 199x (xx.x days from now)

Key successfully installed in /INSTALLDIR/BridgePoint/hpux/lmserver/keydir/xx.lic.

9. If you have additional product keys to install:# cd INSTALLDIR/BridgePoint/admin# ./pt_lm_passwd

Follow the instructions to enter your additional keys.

10. Done with root. Done with Installation on the Server.$ exit

B.2.3 Performing Installation Step On Each Client

Client Installation

1. Verify that the client can access the file system that contains INSTALLDIR. In the mount command output, look for the file system containing INSTALLDIR. If the mountpoint on the client is different than the mountpoint on the server, the users of this client workstation must set the UNIX environment variable $PT_HOME. See Step 3 in B.2.4”Providing Access To The User Community". If the mountpoint oINSTALLDIR is not mounted on the client, then mount it before proceeding.

$ /etc/mount

2. Verify that the client has adequate /tmp space to be used for databascache if a BridgePoint product is run on the client. 12 Mbytes are neefor each BridgePoint product executed concurrently. If there is enoughroom, then you are done with this client.

$ bdf /tmp

3. Perform this step only if you are putting the database cache in a direcother than /tmp. HOSTNAME used below is the name of the client. Usthe UNIX hostname command to determine this.

$ hostname$ cd INSTALLDIR/BridgePoint/hpux/dbserver/etc


$ cp squid_cache_manager_parameters HOSTNAME_cache_manager_parameters


Change /usr/cache_dir on both lines to the directory chosen to hold the cache. Make sure the directory is physically on the disk resident on the local client.

B.2.4 Providing Access To The User Community

Providing Access

1. The executable BridgePoint processes are located in INSTALLDIR/BridgePoint/bin.

Make sure each user puts INSTALLDIR/BridgePoint/bin on his/her $PATH.

2. The online manual pages for the BridgePoint products are located under INSTALLDIR/BridgePoint/man.

If users want access to these online manual pages, then have users add INSTALLDIR/BridgePoint/man to their $MANPATH.

3. If the NFS pathname for INSTALLDIR is different on the server than on a client, all users of that client must set and export the UNIX variable $PT_HOME to the NFS pathname for INSTALLDIR/BridgePoint.

For example:

If INSTALLDIR on the server is/usr/tools

and the client mounts (either hard mount or automount)server: /usr/tools to client:/tool

Then, users on the client must set and export PT_HOME to/tool/BridgePoint.

4. The HP Style Manager allows the user to customize settings for opaque moves. It is recommended to users to not have opaque moves set. This causes many more screen updates to take place hurting performance.

117

B.2.5 Modifications To The Server Boot Sequence

Boot Sequence Modifications

1. Login as root on the server.

$ su -root

2. Add the following entries to the /etc/rc file. Search for “localrc()” and place the entry within the localrc function.

if [ -d INSTALLDIR/BridgePoint -a -f INSTALLDIR/BridgePoint/admin/pt_start_servers ]; then

INSTALLDIR/BridgePoint/admin/pt_start_serversecho “BridgePoint Servers Started”

fi


B.3 Upgrade InstallationIf you are upgrading from an existing BridgePoint release, the BridgePoint servers and applications from the prior release must be shut down and system configuration information copied into the new release.

Special note for the upgrade to the 3.2 release from 3.0.0 or 3.0.1: Installation directory and file names have changed to reflect to ownership of BridgePoint by Project Technology. The following has changed:

• INSTALLDIR/objective is now INSTALLDIR/BridgePoint

• All obj_* scripts are now pt_* scripts.

• The names of the BridgePoint applications have changed.

• analyst --> pt_builder

• sim_ooa --> pt_verifier

• gen_import --> pt_gen_import

• gen_file --> pt_gen_file

B.3.1 Preparation for Upgrade Process1. In BridgePoint Model Builder (analyst), analysts should perform an

export of all domain (.ooa files) using SQL format (with graphical data included). These exports will be reimported into the upgraded release of Model Builder.

B.3.2 Upgrade Process2. Work as root.

$ su -

3. Verify that no users are using any of the BridgePoint products.# INSTALLDIR/objective/admin/obj_lm_admin -l

119

had

ill ers.

d. ous

if the

Note: script name is obj_lm_admin on the prior release. On the 3.2 release the script name will be pt_lm_admin.

4. Stop the database server and the license manager sever.# INSTALLDIR/objective/admin/obj_stop_servers

5. Read in the new BridgePoint release from the tape.# cd INSTALLDIR# tar xvf <tape device>

Note: This is the same step as Section B.2.1 “Loading BridgePoint Files” on page 111.

6. Copy over all customer database server files. These files exist if youto move the location of cache directory on the server or anyone of theclients.# cd OLDINSTALLDIR/objective/hpux/dbserver/etc # cp *cache_manager_parameters INSTALLDIR/BridgePoint/hpux/dbserver/etc

7. Copy over all the BridgePoint licenses. # cd OLDINSTALLDIR/objective/hpux/lmserver/keydir# cp * INSTALLDIR/BridgePoint/hpux/lmserver/keydir

8. Run the new release installation script. Goto step 6 in Section B.2.2 “Performing Installation Step On the Server” on page 112. This step wstart the new release’s version of database and license manager serv

B.3.3 Providing Access To The User Community1. User should reset their $PATH variables to access the BridgePoint loa

Users can still use the BridgePoint application products from the previload, if they desire, by keeping their $PATH the same. The previous application processes can work with the new servers. The file OLDINSTALLDIR/objective/hpux/dbserver/etc/ports must be removedthe previous application products are to be run on the machine runningnew servers.


o

$ setenv PATH INSTALLDIR/BridgePoint/bin:$PATH <csh>$ PATH=INSTALLDIR/BridgePoint/bin:$PATH <sh, ksh>

2. If users have defined UNIX environmental variables $OBJECTIVE_HOME and $OBJECTIVE_PWD, they must now use $PT_HOME and $PT_OOA_DIR respectively.

B.3.4 Modifications To The Server Boot Sequence1. Since the installation directory has changed to INSTALLDIR/BridgePoint

from INSTALLDIR/objective, you must find the BridgePoint entry in the /etc/rc file and make the changes from Section B.2.5 “Modifications TThe Server Boot Sequence” on page 117.

APPENDIX C:

Customizing the Domain Repository

Customizing the Domain Repository is useful to enhance your development environment such that OOAs are stored right along side your other software files such as source code and documents. It also allows for integration with your underlying problem tracking systems to manage changes as they occur to the OOA.

This appendix describes the Domain Repository Files and Domain Repository Commands. This information can be used to customize the Default Domain Repository Commands for your environment.

122 Customizing the Domain Repository

C.1 Domain Repository FilesThe Domain Repository contains a set of character based data and information files.

The following types of configurations exist within the Domain Repository:

• Configuration 0 - Used to store OOA Versions (i.e., combinations of Domain/Subsystem and State Model/Action Configuration Versions)

• Configuration 1 - Used to store Domain/Subsystem Configuration Versions

• Configuration 2, 3, 4,...511 - Used to store State Model/Action Configuration Versions

The same set of files exists for each Configuration created within the OOA:

• Configuration Data File - (one per configuration) Stores configuration information which is independent of the individual configuration versions.

• Version Information File - (one per configuration version) Stores information about the configuration version such as who created, when it was created, etc.

• Version Data File - (one per configuration version) Stores the data which represents the OOA which the user has captured.

The format of the contents of these files is SQL INSERT statements which represent instances (records) of objects (tables). These files must be stored without changing the content in any way.

In addition, a mechanism for lock configuration must be available for check-in/out. This can take the form of a checked_out file as in the Default Domain Repository or can be a built in check-in/check-out mechanism available with the underlying version management system.

C.2 Domain Repository CommandsThe following commands are called by Model Builder to manipulate the Domain Repository. Each command is passed information via environment variables and files and is expected to pass back information via command exit status and files.

123

All Domain Repository Commands have available the following environment variables:

• PT_OOA_DB_DIR - full path name to the OOA Database (x.ooa) from the point of view of the pt_builder process executing on the client workstation.

• PT_OOA_DB_NAME - name of the OOA Database (x.ooa).

• PT_DOMAIN - name of the Domain. The Domain Name is extracted from the OOA Database name by stripping off the ’.ooa’ suffix and stripping off any characters which follow the ’__’ character sequenceincluding the ’__’ characters themselves.

• PT_ERROR_MSG_FILE - full path name to a file which can be used to pass error messages back into pt_builder. pt_builder will display the contents of the error message file when the Domain Repository Command exits with a non-zero exit status.

Some Domain Repository Commands have available additional environment variables:

• PT_CONFIG_ID - Configuration Identifier - an integer value between 0 and 511 inclusive.

• PT_VER_NUM - Version Number - an integer value which is greater than or equal to 1.

• PT_CONFIG_DATA_FILE - Configuration Data File - a file containing the configuration data.

• PT_VER_INFO_FILE - Version Data File - a file containing the version information.

• PT_VER_DATA_FILE - Version Data File - a file containing the version data.

All Domain Repository Commands must exit with an exit status of 0 to indicate success and non-0 to indicate failure. When pt_builder detects an exit status of non-0, pt_builder reads and displays the contents of the PT_ERROR_MSG_FILE.


TABLE C.1 OOA Database Commands

Command & Description Input / Output

pt_repository_exist

Exit with exit status 0 if Domain Repository exists. Exit with exit status non-0 if Domain Repository does not exist.

Output:

• Exit status

• Error File

pt_config_exist

Exit with exit status 0 if the Configuration exists in the Domain Repository. Exit with exit status non-0 if the Configuration does not exist in the Domain Repository.

Additional Input Variables:

• PT_CONFIG_ID

Output:

• Exit status

• Error File

pt_config_create

Create a new configuration within the Domain Repository. The initial version number, initial version information file, and initial version data file are available to this command and must be used to set up the initial version data.


• PT_CONFIG_ID

• PT_VER_NUM

• PT_VER_INFO_FILE

• PT_VER_DATA_FILE

Input Files:

• Version Information File

• Version Data File

Output:

• Exit status

• Error File

125

pt_config_data_get

Place copy of the Configuration Data File in the file with name provided by the PT_CONFIG_DATA_FILE environment variable.


• PT_CONFIG_ID

• PT_CONFIG_DATA_FILE

Output:

• Configuration Data File

• Exit status

• Error File

pt_config_data_put

Place copy of the Configuration Data File contained in the file with name in the environment variable PT_CONFIG_DATA_FILE into the Domain Repository for the indicated configuration.


• PT_CONFIG_ID

• PT_CONFIG_DATA_FILE

Input File:

• Configuration Data File

Output:

• Exit status

• Error File

pt_check_out

Check out the specified Configuration Version. This operation must lock the Configuration so that no other Version of this configuration can be checked out at the same time.


• PT_CONFIG_ID

• PT_VER_NUM

Output:

• Exit status

• Error File




pt_check_in

Check in the specified Configuration as the Version specified.


• PT_CONFIG_ID

• PT_VER_NUM



Input Files:



Output:

• Exit status

• Error File

pt_un_check_out

Un-check out the specified Configuration Version. This operation must unlock the Configuration so that any Version of this Configuration can be checked out.


• PT_CONFIG_ID

• PT_VER_NUM

Output:

• Exit status

• Error File

pt_ver_info_get

Place copy of the Version Information File in the file with name provided by the PT_VER_INFO_FILE environment variable.


• PT_CONFIG_ID

• PT_VER_NUM


Output:


• Exit status

• Error File



127

pt_ver_data_get

Place copy of the Version Data File in the file with name provided by the PT_VER_DATA_FILE environment variable.


• PT_CONFIG_ID

• PT_VER_NUM


Output:


• Exit status

• Error File

•

pt_ver_data_audit

Audit the Version Data File provided in the file with name in the PT_VER_DATA_FILE environment variable against the Version Data File stored in the Domain Repository.


• PT_CONFIG_ID

• PT_VER_NUM


Input Files:


Output:

• Exit status

• Error File



cxxix

AAbout 10Adding Points 37Adjust Snap Grid 31Audit 23Audits 12Auto Numbering 11Available Commands 81

BBackups 12BridgePoint - Automation iiiBridgePoint - OOA iiiBridgePoint - Tool Guide ivBridgePoint Model Builder Index Window 5Bring-In Version from Domain Repository 75

CC.2.2 Performing Installation Step On the Server 112Canvas Color 12checked_out 66Check-in 49Check-in Version 74Check-out 49Check-out Latest Version from Domain Repository 72Check-out Viewed Version 73Commands 122config_data 65Configuration 56Configuration Data File 64, 122Configuration in OOA Version 60Configuration in OOA Version.Abstract 60Configuration in OOA Version.Con_VNum 60Configuration in OOA Version.Confg_ID 60Configuration in OOA Version.Dom_Name 60Configuration in OOA Version.OOA_VNum 60Configuration Version 58Configuration Version Operations 71Configuration Version.Abstract 59Configuration Version.Con_VNum 59Configuration Version.Confg_ID 59Configuration Version.Creator 59Configuration Version.Date 59Configuration Version.Dom_Name 58Configuration Version.Name 59Configuration Versions 48Configuration.Confg_ID 56Configuration.Dom_Name 56Configuration.Hi_IDVal 57Configuration.Hi_VNum 57

cxxx

Configurations 48Control Buttons 23Create OOA Version from Configuration Version View 78Create x.ooa & Domain Repository for NEW Domain 71Create x.ooa from EXISTING Domain Repository 70Custom Domain Repository 67Customizing the Domain Repository 121Cutting Graphical Elements 35

DData Editor Acceleration Keys 27Data Editor Constraints 26Default Domain Repository 65Deleting Points 37Derived Mode 88Description Editor 28Description Editor Acceleration Keys 28Description Format 18Description Templates 17Disk Space 94, 108Documentation Roadmap iiiDomain /Subsystem Configuration 50Domain Configurations 50Domain Repository 45, 46, 47, 63, 121Domain Repository Commands 66, 122Domain Repository Content 64Domain Repository Directory Structure 65Domain Repository Files 122Domain Repository Visibility from Model Builder 63Drawing Area 25Drawing Connectors 32Drawing Procedures 31Drawing Shapes 32Drawing Tools 23

EExchanging Data 85

FFile Button 23File Operations 6Files 122First Time Installation Procedure for HP 111First Time Installation Procedure for Solaris 2 95Font 13Fundamentals 3

GGlyphs 21

cxxxi

HHPUX Platform 107

IInstallation Requirements for HP 108Installation Requirements for Solaris 2 94Introduction 1Invoking BridgePoint Model Builder 4

LLicense Management 81Loading BridgePoint Files 96, 111

MMemory Space 95, 109Miscellaneous 16Model Editing 20, 29Model Editing Windows 21Model Selection 19Modifications To The Server Boot Sequence 102, 117Motif 5Moving 34Moving Selected Elements 34Moving Unselected Elements 35

NNavigation 25

OObject and Attribute Descriptions 55OOA 53, 55OOA Database 45OOA Database Access 68OOA Database Operations 69OOA Database Ownership 68OOA Database Permissions 69OOA Databases 46, 68OOA of ’Version Management’ 54OOA Version 57OOA Version Configuration 50OOA Version Operations 77OOA Version.Abstract 58OOA Version.Creator 58OOA Version.Date 58OOA Version.Dom_Name 57OOA Version.Name 58OOA Version.OOA_VNum 57OOA Versions 53OOA.Dom_Name 56

cxxxii

OOA.Hi_VNum 56Open x.ooa 69OpenLook 5

PPerforming Installation Step On Each Client 100, 115Performing Installation Step On the Server 97Preferences 10Preferences Button 24Pre-Installation 95, 109Print Setup 9Printing 41Printing from the Index Window 41Printing from the Model Editors 42Printing with the Project Notebook 42Project Properties File 14Project Specific Properties 17Properties Button 24Providing Access To The User Community 101, 116pt_check_in 66, 126pt_check_out 66, 125pt_config_create 66, 124PT_CONFIG_DATA_FILE 123pt_config_data_get 66, 125pt_config_data_put 66, 125pt_config_exist 124PT_CONFIG_ID 123PT_ERROR_MSG_FILE 123PT_OOA_DB_DIR 123PT_OOA_DB_NAME 123pt_repository_exist 66, 124pt_un_check_out 66, 126pt_ver_data_audit 66, 127PT_VER_DATA_FILE 123pt_ver_data_get 66, 127PT_VER_INFO_FILE 123pt_ver_info_get 66, 126PT_VER_NUM 123

RR1 61R2 61R3 61R4 61R5 62Relationship Descriptions 61Resizing Connectors 36Resizing Shapes 36Resource File 83

cxxxiii

SScreen Size 29Selecting 33Selecting Multiple Elements 34Shape Color 15Snap Grid 30Solaris 2.x Platform 93SQL Formats 19State Model /Action Configurations 50Subsystem Partition Model (SPM) 63System Requirements 94, 108

TTool 1Turn Snap Grid Lines On/Off Automatically 30Typical Use Scenario 44

UUn-check-out 50Un-check-out Version 74User Specific Properties 11

VV_CIOV 60, 64V_CONFIG 56, 64V_CONVER 58, 64V_OOA 55, 64V_OOAVER 57, 64ver_N_data 65ver_N_info 65Version Data File 64, 122Version Information 77Version Information File 64, 122Version Management 43Version Management Concepts 48Versioning 20View Button 24View Previous Versions 72, 77View Version 72

WWindows 5Working With Text 38

Xx.ooa 68

ZZoom 31

BridgePoint - Tool Guide

Documents

Transcript of BridgePoint - Tool Guide