5.2 Editing

5.3 Creating a New Diagram

To create a new diagram use Diagrams:New Diagram... in the source browser. Below the command New BETA program has been used:

The title of the diagram corresponds to the name and the category (attributes) of the new BETA fragment:

ORIGIN '~beta/basiclib/betaenv'; INCLUDE '~beta/freja/associations'; -- lib: Attributes -- <<NameDecl>>: (# #)

5.3.1 Creating a New Class

When an attribute or a title of a diagram is selected it is possible to create a new class using the Class command in the New menu [tip: you may also right-click the class or attribute and select New:Local Class... from a popup-menu]. Doing this you get a dialog where the name of the new class can be typed in.

The BETA code corresponding to new class looks like this:

Person:(# #)

5.3.2 Adding Attributes and Operations

To add an attribute to a class, select the class and use New:Attribute... [tip: you may also right-click the class and select New:Attribute... from a popup-menu]. As above a dialog is presented and you can now type in the name of the new attribute.

The corresponding BETA code looks like this:

Person(# FirstName: @Text #)

In the same manner as with attributes a new operation "display" can be added to the class using New:Operation.... This makes the diagram appear as follows:

5.3.3 Specifying Specialization

In the following situation one class further, FlightReservation, has been added to the diagram. To specify that FlightReservation is a subclass of Reservation the Specialization command of the Relations menu is used. As the status message of the menubar states in the example below it is now possible to create a specilization by clicking the left mouse button on the subclass and hereafter clicking the right mouse button on to the superclass.

The result will look like this:

The code correspondingly changes from:

Reservation: (# ... #); FlightReservation: (# ... #);

to:

Reservation: (# ... #); FlightReservation: Reservation(# ... #);

5.3.4 Specifying Aggregation

Below the class Flight has been added to the diagram.

We wish to specifify a by-reference aggregation between FlightReservation and Flight. To do this select Aggregation in the Relations menu. This brings up the following dialog:

The aggregation dialog makes it possible to:

• give the aggregation a name
• specifify the multiplicities of the whole and the part
• specify the implementation of a one-to-many ^[1] aggregation; that is to specify if a repetition or one of the basic container classes should be used in the resulting code (using the Implementation tab)
• specify if the aggregation is to be implemented by-reference or by-value (using the Implementation tab)
• give a textual description of the aggregation
• set a number of preferences for the visual presentation of the aggregation (using the Display Preferences tab)

In this example we only specify the name of the aggregation (defaults are such that we get a one-to-one by-reference aggregation).

After choosing Ok in the dialog left click on the class designating the whole (FlightReservation) and, after that, right click on the class designating the part (Flight).

The BETA code correspondingly changes from:

Flight: (# #); FlightReservation: Reservation(# #)

to:

Flight: (# ... #); FlightReservation: Reservation(# theFlight: ^Flight #)

As can be seen the name of the aggregation is reused in the code and the fact that we created a by-reference aggregation is reflected by the dynamic reference implementation of the new declaration (had we instead chosen by-value a static reference would have been declared).

5.3.5 Specifying Association

Below a new class Company has been added to the diagram.

We wish to specify a one-to-many association between Company and Person. To do this select Association in the Relations menu. This brings up the following dialog:

The Association dialog makes it possible to:

• give the association a name
• specify role names for both sides of the association
• specify multiplicities for both sides of the association
• specify if the association should be embeded or not; that is to specify if the generated code is to result in a separate association class or if it is to be embedded in the source and destination classes (using the Implementation tab) (see below)
• give a textual description of the association
• set a number of preferences for the visual presentation of the association (using the Display Preferences tab)

In this example we specify the name of the association, WorksFor, the name of the source role, employee, the name of the destination role, employer, and the multiplicities. Specifying that the multiplicity of the employee end of the association is more than one (in this case '*') automatically sets the implementation to the default, List.

After choosing Ok in the dialog left click on the class designating the source (Person) and right click on the class designating the destination (Company).

The resulting code looks like this:

Person: (# ...; employer: ^WorksFor #); Company: (# employee: ^WorksFor #); WorksFor: OneToManyAssociation (# oneType:: Company; manyElmType:: Person #)

Where the things added to code are the employer and employee declarations and the WorksFor class.

Had the embed option been chosen the code would have looked like this:

Person: (# ...; employer:@AssociationOne(# element:: Company #) #); Company: (# employee:@AssociationMany(# element:: Person #) #)

Notice that in this case no separate association class is generated.

5.3.6 Completing the Code in Code Editor

Consider the following design diagram which could be considered as complete at the design level:

To fill out the code details, the code editor, the textual representation editor must be activated:

The textual representation of the design might, however, not be complete. For example, it still contains operations with empty do-parts. To fill out the do-part of the getFlightNo operation in the FlightReservation Class select the entire getFlightNo pattern in the code editor. Enter text edit mode and type in the appropriate action sequence. For example:

getFlightNo: (# do theFlight.no->putint #)

After filling out more code in the code editor, e.g. further action sequences of the objects, the compiler is activated in the Compile/Run menu of the code editor.

If the compiler reports a semantic error, the corresponding node is also selected in Freja.

When the program is semantically correct and it can be executed and tested. In this phase Freja will typically not be activated. When the program has been tested and considered fulfilling the requirements, the design diagrams may have become obsolete, and need to be updated, i.e. reverse engineering is necessary. This is done by activating Freja on the BETA program.