Modeling Environment

ModelMaker has different views on the models you design. This enables you to select the view (and detail of information) you need during the different stages in your design. These views are:

Diagrams View

Purpose

You will use the Diagrams View to make different diagrams of your model. Every diagram shows classes and associations between classes. In a class diagram you can add and edit classes and visually change inheritance associations add fields and properties and select the current class. The class parts (fields, methods, properties and events) that make up the selected class are displayed in the Class Parts View.

Functionality

Create a new diagram by clicking the Add button in the Diagrams View. After typing in a new name, the diagram is created. Click the diagram name in the listbox to enable the diagram. You can change a diagram name by selecting it in the listbox and then clicking the Rename button or you can remove a diagram by selecting it in the listbox and then clicking the Remove button.

To visualize the existing model, you can either click the diagram wizard button to add a selection of the model to your diagram, or you can start dragging classes from the Class Tree View to your currently active diagram. These classes will be visualized on the fly. You are allowed to drag duplicate classes to the diagram. This is handy when you want to create different fields with the same class as data type.

To edit the model visualize it as described above, or click the Add class to model tool and click on the diagram. The new classes that are added to the diagram this way are also added to the model. Now you can add fields and properties or change inheritance with the Add field to model, Add property to model and Change inheritance in model tools.

You also can add weak associations to the diagram. Weak associations are only known in the diagram itself and thus have no meaning in the model. This type of association is extremely useful in the initial sketching of your class structures, when you don't want to commit yourself to fields and properties yet.

You can edit a class, properties and fields in the diagram by double clicking them.

You can prune the diagram with the Remove from diagram tool. Classes and associations that you no longer want to see in the diagram can be deleted by clicking on them with this tool.

You can remove a class (and all it's class parts: field, methods etc.) from the model with the Remove from model tool. Clicking with this tool on a class, field or property will remove it from both the diagram and the model.

To make a screenshot of a diagram, click the copy screenshot to clipboard button. This will put a metafile image of the current diagram on the clipboard. A metafile can be imported in many text editors.

Clicking the right mouse button on the diagram will popup a menu that allows you to clear the diagram, print the diagram or change the diagram settings like the location of the text labels, symbol size and symbol font.

Class Tree View

Purpose

You will use the class tree view to get an overview of the classes in the model you are designing. From the Class tree view you can add and edit classes and the inheritance relations and select the current class. The class parts (fields, methods, properties and events) that make up the selected class are displayed in the Class Parts View.

Functionality

Add a class as descendant to the current class by clicking the Add button in Class Tree View. You may add a duplicate class to your model by selecting a class and then press the Ctrl key while dragging the class to the required ancestor. This will also copy the original classes class parts.

Edit a classes name and / or it's ancestor by clicking the Edit button in the Class Tree View. You may also edit a classes ancestor by simply dragging the class and drop it on the new ancestor.

Remove a class (and all it's class parts: field, methods etc.) from the model by clicking the Delete button in the Class Tree View. Any descendent class will automatically change it's ancestor.

Edit a classes documentation. This documentation will be available in the Documentation View where you can print or just browse it.

To copy class parts to an other class select these class parts in the Class Parts View and drop them on the target class in the Class Tree View (which can of course be the source class as well). You do not need to worry about unique identifier names: ModelMaker will add the parts with a default name if necessary.

Class Parts View

Purpose

With the Class Parts View you can add and edit fields, methods, properties and events of the currently selected class. You can select the current class in the Class Tree View or Diagrams View . The Class Parts View will always show the parts of the current class.

There are four different types of class parts: Field, Methods, Properties and Events. In the Delphi language an Event is a property with type 'procedure (or function) of object', but ModelMaker has a separate event type to set it apart from normal properties. This allows ModelMaker to generate a method that is compatible with an event. The mediator pattern we created relies on this distinction to generate event methods.

Class parts have a lot in common, because they all have: a name, a scope, a data type and data name (e.g. Integer or TComponent). Also each class part has documentation. This documentation can be browsed in the Documentation View .

Fields, are the basic class parts. You will use fields to store the state (data) of a class. If the data type of a field is a class, ModelMaker will update the fields data type name if the class it points to changes its name.

Methods, can be either constructors, destructors, procedures or functions. They let you perform some action. Methods come in two flavors: ordinary methods created at your request and access methods that give you read or write access to properties. The latter are created automatically if you add a property to the class.

You may override an inherited method by declaring the same method name in a descendant class. In ModelMaker the method which overrides an inherited method can be made inheritance restricted to ensure that all changes (Name, Parameters etc.) made in the inherited method are automatically reflected to it. To do this, create a new method, in the Method Editor enter just the name of the method and click the inheritance restricted box. ModelMaker will update all other settings of that method for you. If you override a static or message method not all properties of the method are restricted. ModelMaker can also add the call to an inherited method in the implementation for you: just click the corresponding option in the Method Editor. If the inherited method's name or parameters change, this call is updated automatically.

Overriding methods is even easier with the Override Methods wizard: Click the Override Methods Wizard button in the Class Parts View. ModelMaker displays all methods available for overriding. Just select the methods you want to override and ModelMaker will create these methods for you in the current class.

Properties, let you define a property of any data type. A property automatically will insert a field, read method or write method corresponding to your choice of access settings. ModelMaker will also take care of updating the state fields and access methods for you when you change the property. You can also define events by using a method type as data type, but we promote the use of events for this.

Events are a special predefined properties. They usually have a have read and write access to a field. Except when an event 'wraps' another event, in that case read and write access is done through methods (See wrapper pattern). The event type can be selected from the event library. ModelMaker patterns will be able to create an event handler for you at request (see Mediator pattern). You may of course create a property with a method type as data type and ModelMaker will output the normal property code for it, but ModelMaker will not recognize this property as an event.

Functionality

Adding parts: You may add a field, method, property or event by clicking the corresponding button in the Class Parts View. Note that once the part is created, it is not possible to change it's type. For example, you cannot change a method into a property or a property into an event.

Editing parts: You may edit a part by double clicking it or by clicking the edit button.

Copying parts: You may copy a single or multiple parts by simply selecting them and then drag them to the Class Tree View and drop them on the target class. The target class may also be the source class in case you want a duplicate of a class part. You also may copy parts to the clipboard and then paste them in a (different) class. This way you can even copy parts between classes in different models.

Deleting Parts: Select the parts you want to delete and click the Delete button in the Class Part View.

Editing a method's implementation code: for this you need to select the method in the Class Part View and open the Method Implementation View. This view will display the code of the selected method.

Display Filter: lets you select which parts to display in the Class Parts View. There are two independent filters:

Part filter: let's you select which part types to display. E.g. display methods only, properties only or display all parts. The Access Method filter let's you select whether you do or do not want a property's read and write access methods to be displayed when displaying methods.

Scope filter: Lets you select by scope which parts are to be displayed. Display private and / or protected and or public and published parts. Note that public and published scope are combined in the User scope filter.

Override Methods Wizard: Quite often you need to override methods already defined in a an ancestor class. The Override methods wizard lets you select from all inherited methods the ones to override. All selected methods are then automatically created and made inheritance restricted. Select also whether to call the inherited method from within a method's body.

Field Wizard. This wizard is generates code for fields in the class. If you set the option "initialize" in a the field, this wizard will search the constructor Create and add initialization code for fields which have this option set. This wizard will also add destruction code to the destructor Destroy if you have set a field's Owned option. If you are using TStreamable descendants which have a Load and Store method, the wizard automatically adds load and store code to these methods if you have the option Persistent set.

Documentation Wizard. This wizard creates predefined documentation for automatically created class parts. This includes documentation for: read and write access methods and the state field of a property and event handlers and wire / unwire methods created with a mediator pattern.

Method Implementation View

Purpose

With the Method Implementation View you may view and edit a method's implementation code. In ModelMaker a implementation consists of: local variables, local procedures (procedures, functions, constants, types etc.) and the body. The body is on it's turn the begin/end clause and a list of code fragments which make up the method code. Because the body is devided into fragments, ModelMaker can distinguish automatically generated code from code inserted by you.

Functionality

From top to bottom you'll find in the Method Implementation View:

The local vars list with buttons to Add, Edit or Delete a local var for this method. You'll find it very convenient to add local vars from within the body code editor: double click on the var identifier in the code and ModelMaker will add this var for you!

On the right of the local vars you find the local procedure memo: here you put your local procedures, functions, constant declarations etc. for this method. In the generated code this block will be put exactly as you type it here. Double click on the memo or click the Edit Local Procs button to move the code to the code editor where you can edit it.

In the middle you find the list of code fragments making up the method's body. This is a folding editor: each fragment is collapsed to a limited number of lines. If a fragment is collapsed it is marked with a purple bar an only the first and last lines are displayed. You may adjust the folding height. You will notice that ModelMaker can add automatically generated code in some methods. e.g. when the 'call inherited method' options is set for a method. This code is put in a separate fragment and has a red colored bar in the margin. All code fragments you add yourself (usually only one for each method) have a green colored bar in the margin. This is the only code you can edit in the code editor. There are buttons to add, edit or delete a code fragment.

At the bottom you'll find the actual code editor. Here you edit your body fragments and local procedures. To move a fragment to the editor click on it. To move the local procedure to the editor double click on it. To save changes you made in the editor click the Save button. Clicking the Restore Button will do the opposite and reload into the editor and undo changes you made. ModelMaker will automatically save code for you if you select a new fragment or a new method.

A Speedbar with the most common statements lets you quickly add statements in the code editor. Especially useful is the 'call inherited' button which add a call to the inherited method with the correct parameters.

You can assign your own code editor shortcuts by using Alt+<Key>. With the options|shortcuts menu you can configure your shortcuts, or press Ctrl+Alt+Key> to edit just a single shortcut.

Patterns View

Purpose

ModelMaker helps you to implement many patterns described in the book 'Design Patterns, Elements of Reusable Object Oriented Software' by E. Gamma ea. In ModelMaker a pattern can be instantiated and stays alive to reflect any changes you make to your model. The Patterns View displays all patterns alive in your model. Here you create, edit and delete patterns.

Functionality

The pattern palette tabset displays the currently available patterns. Click on a pattern button to add a pattern to your model. Usually you first have selected the class to which to pattern applies in the Class Tree View or Diagrams View and/or selected a class part in the Class Parts View.

To edit a pattern, click on the Edit button. To delete a pattern click the Delete button.

The behavior of each pattern depends on the pattern you selected.

Behavioral: Visitor Pattern

To create a visitor pattern, first create a visitor and visited class in your model. Then click the Visitor Pattern button in the pattern palette and assign the Visitor and Visited Classes. The Pattern will add the correct AcceptXXX and VisitXXX methods e.g.

AcceptPartVisitor(Visitor: TPartVisitor);

VisitPart(Instance: TPart).

If you now add a descendant class to the visited class, the pattern will automatically add a Accept / Visit combination for you. If you delete the pattern all Visit / Accept methods will be removed again! This also happens if you delete the visitor or visited class or if so edit the pattern and assign new classes to visitor and visited classes.

Wizards: Lock Pattern

The Lock Pattern lets you simply add a multi-step lock/ unlock mechanism to a class, similar to the TStringList.BeginUpdate / EndUpdate methods. The Lock / Unlock methods automatically generate code which call the SetLocking(Updating: Boolean) method on locking state changes. You may of course edit the method names. If you remove the Lock Pattern, all methods and the state field are removed from the class. Edit a lock pattern to change the methods and state field's names.

Structural: Decorator Pattern

The decorator pattern lets you create a decorator class that decorates another class. The decorator class is generated for you. Use this pattern also to create a Proxy Pattern, since the structure of this pattern is basically the same. Select a class you want to decorate, click the Decorator button in the pattern palette and add methods, properties etc. you want to decorate. If you remove the pattern the decorator class will be removed as well.

The decorator pattern creates a Create and Destroy method in the decorator class. There is an option to select whether you want the reference passed in the Create constructor's parameters. The Decorator pattern adds a read/write property for the reference to the decorated class. A property defining the ownership of the reference is also generated. If this property is set True, the decorator will dispose the reference before assigning a new reference in the write access method. The Destroy destructor will also free a owned reference. There is an option to select whether you want the ownership passed in the Create constructor's parameters.

Structural: Wrapper pattern

This pattern lets you 'use' a class via another class. Before inserting the pattern you select a class A that should use a class B. Create a property, field or method in Class A that has Class B as data type. Select this property , field or method and click the Wrapper button on the pattern palette. You then get a dialog that lets you select what fields, properties and methods have to be wrapped. ModelMaker generates a property for each field or property you selected including read and write access methods and code of the properties. For each method you wrap ModelMaker generates a method in the wrapping class with exactly the same signature: name, parameters etc. including the code to call the method in the wrapped class. If you change the signature of a wrapped part the wrapper pattern will automatically reflect these changes to the wrapped parts.

Structural: Mediator Pattern

The mediator pattern creates event handlers and wiring / unwiring methods for you. This is more or less what Delphi does for you in the Form Designer. In ModelMaker you can do the same with your own components. The mediator needs a mediator class which has a field, method or property with the data type of the class you want to mediate. Select this class part and click the mediator button on the pattern palette. All available events in this class are displayed, and you may select which events you want to mediate. For each event ModelMaker generates an Event Handler method with the correct parameters. ModelMaker uses the Event Library currently loaded to find out about method signatures, so it can generate the correct parameter list and method type. If you click the appropriate options in the Mediator Editor, ModelMaker can generate a WireXXX and UnwireXXX method for you as well, e.g. WirePart, UnwirePart. In WireXXX the events are wired to the event handlers, e.g.

Part.OnChange := PartChange;

in UnwireXXX the events are reset to nil. e.g.

Part.OnChange := nil;

Call these methods from your own code e.g. in constructors and destructors or factory methods.

Units View

Purpose

The Units View displays all currently active Units in the Model. A Unit in ModelMaker consists of references to a class plus all other code you want to include in your unit. Units can be active and react to any change in a class in that unit by regenerating the unit for you. If you have included the ModelMaker Expert DLL (MMEXP.DLL) in Delphi, ModelMaker will request Delphi to reload the generated unit in the code editor.

Functionality

To add a unit to a model click the Add button in the Units View. A default unit is generated. You may edit the unit name and add some classes to the unit. Each class has three parts: Interface, Implementation and Initialization. Each part consists of three lines of code. Please do not change these anything in these lines or your unit will be undecipherable to ModelMaker ('Syntax Error' will be displayed in this case). You may however move any set of lines to an arbitrary place in your code.

Add classes to a unit: Simply drag the class from the Class Tree View to the unit list and drop it on the unit you want to add the class to. Or press the Edit button and manually add the class to list of classes contained in the Unit.

To remove a class from a unit, press the Edit button and remove the class from the list of classes in the unit.

To remove a unit from the Units View, click the Delete Button. The unit will not be erased from disk. Click the Erase button delete the unit from the units list and erase the file from disk.

To actually generate a unit press the Generate button. To enable automatic generation (all changes in a class are immediately reflected by regenerating the unit) click the Enabled button. To disable this feature click the Disable button.

If you change your non class related code in an other editor (as we could imagine), you might (re-) Import the unit again in a unit. Click the Import button in the Units View. ModelMaker will try to separate class related code from other code, but relies on the tags put in the source file. As long as you do not remove these tags you should be able to import your code in a ModelMaker unit. Note that by default the option 'No Tags' is true, so no tags are generated. Switch this option off to enable tag generation.

Importing a unit that you created using Unit Links usually works fine, since Unit Links do generate tags.

Unit Links View

Purpose

Usually you will create units (source code files) for your classes with the Units View. However, sometimes you do not want ModelMaker to create the complete file. This may be the case if you are incorporating a ModelMaker class in a Delphi generated Form unit file or if your files get really large and contain a lot of non-class related code (since the Unit Editor uses a simple Windows Memo it can only contain up to 32 Kbytes of chars). In these cases you can use Unit Links. A Unit Link let's you 'hot-link' a class to a unit. ModelMaker puts tags around the class related code and is able to update the class in your unit code without knowing what other code you put in it. Be careful using Unit Links: Experience has shown that using Unit Links in a Windows NT environment may cause complete units to disappear due to a bug in the NT file system. In a Win 3.11 or Win 95 environment there have been no problems so far.

Make sure that a Unit Link NEVER uses the same target source file as a Unit in the Unit Views. This might cause 'strange' behavior!

Functionality

To add a Unit Link select the class you want to link. Then press the Add button in the Unit Links View. Enter the source file name and Click OK. If no file of that name exists ModelMaker will generate a new unit for you and insert the class into it. If a file with that filename already exists you have two options: Overwrite it or click: 'No' I don't want to overwrite it and use the Class Insertion Editor to tell ModelMaker where to insert the interface, implementation and initialization parts for this class.

Edit a Unit Link if you changed the unit filename or want the class to be placed in a different unit. Note: there are no restrictions in the number of unit links operating on the same class (this place the class in different source files). You may also have multiple classes linked to the same source file using multiple unit links.

Delete a unit link: this will not remove the unit file from disk, but simply remove the 'hot-link' between class and unit file. To remove the linked code or just the 'tags' from the linked unit click the 'Remove Code' button and select the code you want to remove.

Just as with Units, you can enable and disable Unit Links.

Documentation View

Purpose

The documentation view is used to view both the online system documentation, as well as the automatically generated model documentation. It is essentially a HTML browser.

Functionality

To view documentation, click an entry in the index listbox on the left side of the view. Special functions like history or changing fonts can be called up by clicking the right mouse button on the view which will popup a menu.

The generated model documentation is generated from both a user and a designer perspective. The user perspective includes only public and published methods, fields, properties and events. The designer perspective includes all methods, fields, properties and events.

Event Library View

Purpose

In order to generate the appropriate event handlers for the mediator pattern ModelMaker needs to know the signature of the Event types you are using. These event types typically survive a single model. Therefore ModelMaker has an Event Library View in which you define your events.

Functionality

Add an event type to a library by clicking the Add button. Define Name, Method kind, Data Type of a function and a parameter list.

Edit or delete an event type by clicking the appropriate buttons. Deleting an event will just remove it from this library and have no effect on event handlers generated with a mediator using this event. But as soon as a mediator needs to update an event handler and it cannot find the appropriate event type, it will substitute a TNotifyEvent instead.

New, Open, Save, Save as applies to the library as a whole and speak for themselves. It does not matter where you store your events as long as you store them. ModelMaker will (try to) automatically load the event library next time you run ModelMaker.

To add the Event type definition code to a Unit, simply drag the event to the Unit Code Editor and drop it there. It will be added to the line at the current caret position. So better first select the unit and set the caret on the location you want the event to be inserted before dragging the event onto the unit.