JeeWiz Architect's Guide - AssociationEnd Object


	The Model-Driven System Builder

JeeWiz Architect's Guide

Contents > 14. 'Business Object' Reference

14.3 AssociationEnd Object

Subclassed By

baseViewEnd

end

Description The core information relating to two associated objects.

Imagine a class diagram with an association between two classes.

Then the 'association-end' gives information about one end of the association.

Contained
Lists

1

Name   style

Type   String

Description   You can specify one or more styles to give information to the code generation scripts. The meaning of the styles is up to the script writer.

The styles can be used as flags by the script calling $styleList.contains( "styleOfInterest" )

[ Currently, there is no built-in support for style="styleType=value" type semantics. This would have to be defined by each script writer. ]

Examples of the use of styles:

characteristics of a web page (e.g. should it be included in one of the menus)
whether an entity should be automatically mapped to a data-view (the 'maintain' style).
Note that styles and the 'group' property are different concepts, and therefore complimentary. Many modelling objects - such as data-views and their fields, or business methods - can be put into groups as a hint as to where to render the UI pages. Typically groups are used to define 'where' to place the meta class, whereas styles indicate how to render the object.

Unique   false

2

Name   rolesReadonly

Type   String

Description   If the principal is not in the roles-allowed or the roles-blocked, they may have their access limited to read only by being included in a role here.

Unique   false

3

Name   rolesAllowed

Type   String

Description   If no roles are specified all roles are allowed that are not explicitly prohibited, otherwise only the specified roles are allowed.

Unique   false

4

Name   rolesBlocked

Type   String

Description   Members of these roles are blocked, whether they are granted permission elsewhere or not.

Unique   false

Inherited
properties

template (base property)

text (base property)

jwpattern (base property)

14.3.1	Property 'name'
14.3.2	Property 'description'
14.3.3	Property 'multiplicity'
14.3.4	Property 'allowDuplicates'
14.3.5	Property 'required'
14.3.6	Property 'useOnSummary'
14.3.7	Property 'useOnSearch'
14.3.8	Property 'accessor'
14.3.9	Property 'roleName'
14.3.10	Property 'initialRoleName'
14.3.11	Property 'access'
14.3.12	Property 'package'
14.3.13	Property 'readable'
14.3.14	Property 'writeable'
14.3.15	Property 'uid'

14.3.1 Property 'name'

*Type*	String
*Hidden*	true

14.3.2 Property 'description'

*Description*	Optional description of the role of the entity in the parent relationship.
*Type*	String

14.3.3 Property 'multiplicity'

*Description*	Specifies the multiplicity of the named entity in the relationship. This can be One or Many.
*Type*	String
*Choices*	One (default) Many

14.3.4 Property 'allowDuplicates'

*Description*	Only applicable to ends with an accessor that returns One to Many instances (i.e. where the other end of the relation has a mutliplicity of "Many"). This specifies whether the same entity may appear more than once in the relationship.
*Type*	boolean
*Default*	true

14.3.5 Property 'required'

*Description*	This determines whether a value needs to be input into this relationship and is carried forward to the dataview level. We refer to relationships with an end required="true" as 'required', otherwise as 'optional'. This is used in preference to multiplicity eg 0..n or 1..n.
*Type*	boolean
*Default*	false

14.3.6 Property 'useOnSummary'

*Description*	Use-on-summary tells the standard patterns whether to render this connection as a summary "field". How it's rendered depends on the style of the view end.
*Type*	boolean
*Default*	false

14.3.7 Property 'useOnSearch'

*Description*	Use-on-search tells the patterns whether to use a view end (or a default entity end) on a search screen.
*Type*	boolean
*Default*	false

14.3.8 Property 'accessor'

Description

Specifies the name accessor/mutators (represented as a pair of getter/setter methods) in the parent entity by which the related instances of the other entity are accessed.

If not set, this will default to the uncapitalised name of the other end's entity (this is set by the initialisation code rather than a fixed default).

[ In IBM Rational RSM/RSA, this property is joined with the concept of the role-name. ]

Type

String

14.3.9 Property 'roleName'

Description

Optional name to be used to describe the parent entity's role in the relationship. If not provided, the default naming pattern sets the role name to the same name as the attached object - entity or data-view. Role name is used to uniquely define a relationship (end) between two entities or views where there is more than one relationship between the objects. It fulfils a similar function on a relation between an entity (or view) and itself, distingusihing which end is which. This is required to allow dataview relationship ends to map uniquely to entity ends. Both the initial role name and the role name must be unique, so in the case where a role name is modelled as blank, and another is modelled as the entity name, the role names will not be unique, even though they were initially, as the blank name will be set to the entity.

Type

String

14.3.10 Property 'initialRoleName'

*Description*	This is the user input role-name, before any patterns are used to set the role-name.
*Type*	String
*Default*
*Hidden*	true

14.3.11 Property 'access'

*Description*	In the business model, business object/methods and attributes are by definition public - they are designed for access by clients outside the object. Therefore the 'access' value is fixed at 'public'. This factor hides the 'access' property from users. However, the attribute can be set programmatically (i.e. in some patterns access is set to private) so that it will be rendered via normal field generators according to the architect's design.
*Type*	String
*Default*	public
*Hidden*	true

14.3.12 Property 'package'

*Alias*	namespace
*Description*	This is the package attribute: it declares the name of the package that this interface (or class, or entity, etc.) belongs to. It can be used on reference types (interfaces and classes) and all their derivatives associations assemblies of model-objects containers of same, like jars. It uses delegation of responsibility to search its parent chain. For example, in the J2EE realm, this means that the package can be specified on (working up the containment chain): an entity, or its ejb-jar, or the application, or in the assembly or in the build properties '.jwp' file. If none of these is specified the package will be null. Null packages are not recommended but legal for simple Java builds. For larger systems, null packages are not allowed. The combination of the package and class name (i.e. the fully-qualified Java classname) must be unique across all reference types and their derivatives in a build.
*Type*	String
*Delegates*	true

14.3.13 Property 'readable'

*Description*	Defines whether a public 'getter' method will be generated to get the value.
*Type*	boolean
*Default*	true

14.3.14 Property 'writeable'

*Description*	Defines whether a public 'setter' method will be generated to set the attribute.
*Type*	boolean
*Default*	true

14.3.15 Property 'uid'

*Description*	The 'uid' is a Unique IDentifier for a methods in the business object model (and derivatives like J2EE). The 'uid' uniquely identifies the method, even if the name or signature of the method changes. This will normally be generated by the modelling tool; if not, it can be entered manually (but make sure it is unique!).
*Type*	String