
	The Object Engineering Workbench for C++ (tm)

	The Object Relationship Modeler (tm)


	Notes for the Small Project Version
	===================================


To logon
========

Enter OEW in uppercase for the Name and Password.


Support and Sales
=================

	Please contact:

		Stephan Wolf
		Innovative Software GmbH
		Germany

		Telephone:	++49 69 236929
		Fax:		++49 69 236930

	

		Bill Whittakers
		Object Software Engineering Pty Ltd
		Australia

		Telephone:	++61 52 377066
		Fax:		++61 52 377054



Introduction
============

The purpose of the small project version is for you to evaluate The 
Object Engineering Workbench.  Its single limitation is that it will 
only save a model of up to 12 classes.  This means you can see 
exactly how the workbench operates, as if you were using the full 
version.

These notes highlight points about the operation of OEW.  Please 
read them through.  If you have any difficulties, please make 
contact with the support address listed below.


Table of Contents
=================

	Glossary of Special Terms in OEW/C++
	To logon
	Online help
	The Main Window and the ORM Window
		Differences between the two main windows
	Importing Source Code
	Printing Documentation
	Rearranging diagrams
	Inheritance diagram (class hierarchy)
	Relationship diagram (Object Relationship Model)
	Marking classes
	New class
	Import from objectbase
	Quick reference
	Global file names
	Edit main program
	Modules
	Container classes
	Using a Makefile or a Borland project file
	Views
	Class overview
	Class list
	Access to Objects in an Objectbase
	Editor
	Code generator options
	To logout
	Support and Sales information


Glossary of Special Terms in OEW/C++
====================================

There are some special terms used in OEW.  It would be useful to 
review these.  They are defined in the OEW/C++ glossary in the 
online help.


	OEW terms:  	control statement, focus, objectbase, object, 
			scheme, slot, view


Online help
===========

The current online help from the full version is provided.  We 
suggest you review the online help topics listed below to start 
with.  Other topics are accessible through the alphabetic listing.

	Directories and files
	Mouse operation
	Main window
	Main processes
	Toolbar

You can purchase the manuals for US $99.00 by contacting the support 
address below.  If you subsequently order OEW you will receive a rebate.


The Main Window and the ORM Window
==================================

Both the main window and the ORM window can be open at the 
same time (especially on a big screen).

OEW/ORM is an additional module that adds to the analysis level 
of the workbench.  It does this by displaying member class 
relationships (that is: "has a", "whole/part", "uses", or "contains", 
depending on your terminology), and reference relationships, as 
well as inheritance relationships.  Note that in the Edit 
relationship dialog box you can add your own terminology for 
relationships.  These are called "relationship labels".  The ability 
to name relationships lets you incorporate terminology from the 
methodology of your choice.  This is in keeping with the design 
philosophy of OEW, in not seeking to introduce a new 
methodology, but to support the concepts inherent in existing 
methodologies.  It aims to support the ideas that express meaning 
in a model, and at the same time map these meanings to constructs 
supported by the language.

To concentrate on member class and reference relationships, use 
the ORM window.  To concentrate on inheritance relationships, 
use the main window.

You can have both windows open at the same time.  Classes are 
accessible through the Class dialog box in both windows.  
Double click on the class icon.


Differences between the two main windows
========================================

Relationships can be declared in either window.  What varies 
between the two windows is which relationships can be 
displayed and which ones can be declared and defined.  The 
differences can be seen when you compare the following 
tables:

	Main window

		relationship	visible		declaration	definition
		------------	-------		-----------	----------

		inheritance	yes		yes		yes
		member class	no		yes		yes
		reference	no		yes		yes

	ORM window

		relationship	visible		declaration	definition
		------------	-------		-----------	----------

		inheritance	yes		yes		no
		member class	yes		yes		yes
		reference	yes		yes		yes


Importing Source Code
=====================

We find that one of the first things people wish to do with OEW is 
parse existing code.  Please be aware of the following:

1.  The import mechanism is 'semi-automatic'.  It can be an 
iterative process in which you run the import process, review the 
result (which will depend on the code being imported) and assign 
code fragments the parser does not know what to do with.  It is 
work that needs to be done once.  The result is an objectbase that 
can be reused.

2.  The parser analyses code for constructs that can be stored in 
the objectbase (classes, data members, member functions and 
datatypes).  Fragments of code that cannot be recognised (for 
example: includes to C function libraries, or some comments) are 
filed in a separate file, the UNKNOWN.COD file.  These code 
fragments can be assigned to objects that have been added to the 
objectbase.  They are catalogued by source code file, and can be 
viewed and assigned from within the Assign unrelated source 
code dialog box.  The UNKNOWN.COD file can also be viewed by 
any file viewer.  This can be useful to decide on code assignment.  
It can be useful to print the UNKNOWN.COD file for review and for 
reference while assigning code.

It is useful to know what the code generator creates, because 
some of the code fragments that the parser does not place, will be 
recreated by the code generator.  Code for ifndefs, includes to 
superclasses, includes to member classes, and includes to 
referenced classes are automatically generated.  Because this will 
happen, you can discard (use the Forget button) these code 
fragments when assigning code fragments.

3.  It is not necessary to assign all the unrecognised code 
fragments immediately before proceeding to a review of the initial 
result.  You can by-pass the process (click OK in the Assign 
unrelated source code dialog box after the parsing operation is 
finished).  Then review the resulting diagram and its contents to 
see what the parser has done.  Then you could generate code and 
compare the result with the original.  You can return to the 
assignment process later to assign missing code fragments.  
Remember that once this work is done, the objectbase (and its 
associated scheme files) can be reused in new applications (see 
Import from objectbase on the Edit menu).

4.  Please read the online help topics and glossary definitions that 
explain the function of the scheme files for modules and classes to 
get an understanding of their significance and operation.  In 
summary, the scheme files do two things:

	A.  They contain the "control statements" (for example 
	@@ClassDeclarations) that drive the code generator.

	B.  They can contain valid C/C++ code that cannot be 
	entered into the objectbase.  The code generator combines 
	this code with the information in the objectbase to generate 
	code for each module.

When importing code, you can assign unrelated code fragments to 
the scheme files if it is not possible to assign them to objects in 
the objectbase.

There are default scheme files.  Instances of scheme files for 
modules and classes are only created when required (otherwise 
the default schemes are used).

5.  It is important to check that the include path in the Import 
from source dialog box is set properly.  For example, if you select 
a source file, make sure there is a path to the directory containing 
the header file.  It is not necessary to set a path to included C 
function libraries.  The include path defaults to the path defined in 
the SET INCLUDE statement (if there is one) in your 
AUTOEXEC.BAT file.  It is possible to enter a series of paths in the 
include path edit field.

6.  It is not necessary to import a large group of classes to test the 
parser.  We suggest that you choose a small group of classes that 
are representative of the way you work.  Remember the parser is 
looking for 'object-oriented' code, and also that any other code 
that is not 'recognised' can be assigned to the scheme files.  
OEW's purpose is to encourage you to design and program 
applications using C++ as an object-oriented language.  In 
practice, not everything may be 'object-oriented', because of 
design and time limitations.  OEW therefore provides the scheme 
mechanism to incorporate these functional elements of the design 
into the model.

7.  It is a good idea to create (save) an objectbase for a model 
before generating or importing code.  This ensures that the source 
code files are generated into a unique directory.  Also, during an 
import, an UNKNOWN.COD file is created for each objectbase; 
rather than being overwritten each time, in the main directory.

8.  You can save a model while working in the dialog boxes by 
using the Shift + F12 key combination.

9.  After an import, it is advisable to check the list of datatypes 
(enumerations and typedefs) added to the built-in types.  Select 
Edit datatypes from the Types menu.


Printing Documentation
======================

Please note that the font size can be important when printing 
documentation.  For a standard A4 laser or inkjet printer, Arial 
and 10 are suggested for type and size respectively.  It is also 
recommended to set the printer to landscape mode so the table layout 
will work.


Rearranging diagrams
====================

Both diagrams can be rearranged for better presentation and easier 
reading.

Inheritance diagram (class hierarchy)
-------------------------------------

Focus on a class in the class hierarchy and use the Crtl key 
with the right mouse button.  Hold down the button and drag 
the class to its new position, then release the button.  This 
option does not work if you choose to have the Sort classes 
alphabetically option on (see the View menu).

Relationship diagram (Object Relationship Model)
------------------------------------------------

Mark a class (single left click), and use the Crtl key with the 
right mouse button.  Hold down the button and drag the class 
to its new position, then release the button.  This diagram is 
based on a grid, the size of which is dependent on the longest 
class name, and the font type and size.  Note that you can 
mark and move more than one class at a time.


Marking classes
===============

It can be useful for some tasks to work on a number of classes at 
once, for instance moving classes in the relationship diagram, or 
marking classes as library classes.  See the online help topics 
Marking classes and Edit multiple classes.


New class
=========

There are a number of ways to enter a new class.  See the Add 
new class topic.  In the ORM window, you can position the cursor 
in a selected spot on the background of the window and double 
left click to add a new class.  The new class will be added to the 
diagram at the selected grid position.

Note also that you can enter more than one class at a time by 
separating the class names by commas.

See the Class dialog box help topic for detail on creating a class 
and its attributes and methods.


Import from objectbase
======================

Once you have created a model, you can reuse classes, instances 
and datatypes in a new model by using the Import from 
objectbase function (on the Edit menu).  Note that you have the 
option to import the associated scheme files as well.


Quick reference
===============

The quick reference is a browser which you can access with the 
F5 function key while you are in another dialog box, for example, 
in the Class dialog box.  It can be very useful when you are 
working on one class, and you want information about another 
class.


Global file names
=================

You can set file endings and subdirectories for the source code 
files.


Edit main program
=================

You can edit a main program from this option on the Edit menu.


Modules
=======

Each class has a module.  By default there is one module for each 
class.  You can have more than one class in a module.  You can 
enter the Modules dialog box either from the Source menu, or by 
clicking the Filenames button in the Class dialog box and then the 
Modules button.


Container classes
=================

You can link container classes to 'descriptive tags'.  Container 
classes can be used to manage the cardinality of attributes in 
classes by selecting the related 'descriptive tags' from drop down 
list boxes.  These container classes can be template classes.


Using a Makefile or a Borland project file
==========================================

If you are using the Borland compiler, you can choose between 
using a makefile or a project file (see the Options menu).  When 
code is generated either the makefile is generated, or the Borland 
project file is updated.


Views
=====

You can choose subsets of classes and arrange them in separate 
views, in both diagrams.  Views allow you to focus attention on 
aspects of a model.  A class can be in any number of views.  A 
view can be set exclusive, in the Select view dialog box, to isolate 
the classes in the view from the other classes in the model.  When 
a view is selected the name of the view is included in the title bar.


Class overview
==============

Use the overview to see a complete diagram when it is too large 
to fit on the screen.  The dark area in the miniaturised overview, 
which is the visible section of the diagram, can be moved by 
dragging it with the mouse.


Class list
==========

Use the class list to help with navigation in a large diagram.  
Highlight a class in the list to move it into the visible section of the 
diagram.


Access to Objects in an Objectbase
==================================

Access is based on the level of the user group of the user who 
creates an object.  If another user belongs to a group with a higher 
level, he or she will be allowed access.  Objects to which a user 
does not have access are displayed in grey.  The user can browse 
them, but not make any changes.  You can however create a 
subclass of a class to which you are not allowed access.

If you want to test the access mechanism, then follow this 
example.

1.  Create three user groups (for example, Developers, 
Contractors and Guests).  Set the levels for the groups to 
900, 600 and 500 respectively.

2.  Add three users, one in each group.

	user	user group
	----	----------

	Bill	Developers
	David	Contractors
	Justin	Guests

3.  Logon as David and enter the classes: Wheel and Engine.
4.  Logon as Justin and enter the classes: Body and Door.
5.  Logon as Bill and enter the classes: Vehicle, Car and 
Truck, where Vehicle is the superclass of both Car and 
Truck.
6.  Now logon as each user again and you will see which 
objects they are allowed access to.


Editor
======

You can use any Windows or DOS editor, or the built editor built 
in.  We suggest you test the link to another editor later (look at the 
main functions first).


Code generator options
======================

There is an option for the code generator that determines the level 
of detail for comments in the generated code.  We suggest you set 
it off for a start.  This will simplify the look of the code you 
generate while testing, which will make it easier to see what the 
code generator does.


To logout
=========

When you select logout from the File menu, it is a two step 
operation.  The login screen is displayed first, giving the 
choice to enter again as another user, or to logout.

If you want to exit directly in one step, press Alt + F4.


Support and Sales information
=============================

	Please contact:

		Stephan Wolf
		Innovative Software GmbH
		Germany

		Telephone:	++49 69 236929
		Fax:		++49 69 236930


		Bill Whittakers
		Object Software Engineering Pty Ltd
		Australia

		Telephone:	++61 52 377066
		Fax:		++61 52 377054
