JeeWiz Home  
The Model-Driven System Builder
JeeWiz Modeler's Help File for RSA/RSM
 
Contents  >   4.  Service Data and Operations
 


4.7 How to Relate Dataviews

Dataview relationships are modeled from stereotyped associations from the class diagram. You can do this by selecting an association from the pallet by clicking on the Class Diagram Drawer in the palette to open it, finding the association creation section, then drawing a line between the two entities you want to relate. Afterward making sure the association is still highlighted, add a dataViewRelation stereotype using the Add Stereotype button in the stereotype tab of the properties view.

The first thing to get right here is the multiplicity. Don't worry about the difference between 1, 0..1 and 1..1, or 0..n, 1..n and *. Just use 1 and *, where * stands for many. You can set the relationship to be required (a minimum of one on the relationship) elsewhere. All this is the same as relating entities.

If both dataviews being related are backed by entities, and the dataview relation matches an entity relation between the two entities backing the dataviews, the multiplicities on the dataview relation ends must be the same as on the entity relation ends. This is less complicated than it sounds! For example, if the Order entity is related one-to-many to the OrderLine entity and the OrderDV dataview (backed by Order) is related to the OrderLineDV dataview (backed by OrderLine) then the dataview relation must also be one-to-many.

A dataview relationship generates an accessor attribute on each end which needs to be stereotyped as a dataViewEnd. The properties that may need to be set about a dataview relation need to be set on the dataViewEnds. After drawing the dataview relationship, RSA puts attributes on each of the dataview. These can be accessed most easily via the model explorer. Either go to the parent dataview directly and search for the relevant attribute under the tree, or select the dataview, go into the attributes tab of the properties view, right click on the relevant entry and choose select in explorer. When the accessor attribute is selected in explorer, you can go to the stereotype tab of the properties view and use the Add Stereotype button to stereotype it as an "dataViewEnd".

Ideally the role/accessor name should be a lowercased (initial character) version of the dataview on the other end; however if there are multiple relationships defined between entities backing the dataviews, the role/accessor names are used to distinguish which entity relationship should back the dataview relation. The names should match the accessor names at the entity level.

Dataview relations like dataview fields play roles as data carrier, as display item and in queries. The value object generated at either end contains an embedded value object (or list of value objects) representing the other end. Data in these embedded value objects can be used when displaying the related dataviews on a page and all data items displayed or entered on a page can be encapsulated in a single value object this way.

Of course embedded value objects can also contain embedded value objects and a complete tree can be built up by an application programmer and this can be passed through to a service. The generated dataview objects know how to split up these value objects trees and pass them through to their native dataview objects for processing (update, create or delete).

The layout of a page is determined by its template and style, but most pages have an area in the centre which is used to display and input data. These data items, their format and their order is defined by the dataview structures linked to the page. Most page styles accept a single dataview type set using the "dataview" property on the page. Some page styles also accept a masterDataView property, in this may add to the layout. The effect of style and templates on layout are dealt with elsewhere, as is the detail of how individual dataview fields are displayed.

In displaying a dataview relation the displayStyle of the relation dictates how the related dataview is displayed. Unless the displayStyle is set on a modeled dataview end , the relation will not be shown. Some modelers like to set a displayStyle of noshow, which has the same effect also indicating that this is intended and not just forgotten. Maintenance dataviews that are created from entities are shown even when the displayStyle on the relation end is not set, as during creation the transform adds a default displayStyle based on the multiplicity. If you want to override these styles for the maintenance pages, you can set the displayStyle on the ends.

Display styles are only valid for particular multiplicities. -to-one relationships can be displayed as contained, dropdown or lookup. -to-many relationships can be displayed as grid, assocgrid, displaygrid, selectgrid or multidropdown, owningdropdown.


Links:  

Copyright © 2001-2006 New Technology / enterprise Ltd.