BRIM™ Class Diagram Syntax: UML Repository Objects
This section
describes the objects in the BRIM™ Unified
Modeling Language (UML) Repository.
A
rule in BRIM™ includes all
of the business rules that are in effect at any point in time.
A rule is a
collection of business rules corresponding to a database in Oracle. Only one rule can be active at a time. You
can have multiple rules for the purpose of versioning, rules that in
development, etc.
The related BRIM™ methods to manipulate rules are:
Uml_ddl.CreateRule
Uml_ddl.DeleteRule
Uml_ddl.InstantiateRule
The related BRIM™ methods to obtain information about rules are:
Uml_rep.IsRule
Uml_rep.GetRuleId
Uml_rep.GetGeneralizationStructure
Uml_rep.IsRuleInstantiated
The properties of
rules are as follows:
·
Rule Name
(Name_TX)
This
property stores the name of the rule.
Rule Name is unique in the system.
·
Instantiated
This
property indicates whether or not the rule is instantiated. When a rule is
instantiated, its associated database is generated.
·
Description
(Descr_TX)
A
text description of the rule.
·
Active
(Activ_YN)
Logical
deletion of the rule. Only active rules can be instantiated. Most lists of
rules will only show active rules.
Implementation Notes
When a rule is
instantiated, all changes made to the repository object in that rule are first
validated to see if the existing objects violate the change request.
Example:
Let the class
“Person” be a concrete class in an instantiated rule and have an attribute
called “LastName.” Further assume that LastName has the domain Str255 that it
is a simple domain of type Varchar2, length 255. Assume Str10 is a simple
domain of type Varchar2 and length 10. An attempt to change the domain of
attribute LastName from Str255 to Str10 will succeed only if there are no
persons with a last name longer than 10.
A class is a basic
UML class. It roughly corresponds to an
entity in relational database. Classes are physicalized into tables and views
(see the Table View generator document for more details.
The related BRIM™ methods to manipulate classes are as follows:
The properties of
classes are as follows:
Class
Code
This
property stores the code of the class and will be the name of the generated
view. It must be less than 25 characters and be a valid Oracle table name.
Class
Name
This
property stores the name of the class and is used in UI applications.
Description
(Descr_TX)
A
description of the class
Note
(Note_TX)
A
designer note about the class.
An association class arises from a
many-to-many association.
For
example, an organization can be associated with different currencies, and the
roles of each currency can be different.
This situation can be represented correctly only through an association
class as shown in Figure 1:
Figure
1: Association Class Example
At the physical level, association class will store its own
attributes and IDs of classes from both sides.
In this example, Organization Currency will store currency_id and
organization_id.
The main difference between an association class and a
regular class is that an association class does not have any meaning without
the classes in the basic association.
The association and the association class object are created
and deleted at the same time.
Association classes can have attributes, and they have all the features
of a regular class.
Related BRIM™ methods:
Manipulations:
uml_ddl.uml_ddl.CreateAssociationClass
uml_ddl.ConnectClass
uml_ddl.DisconnectClass
Information:
uml_rep.IsAssociationClass
uml_rep.HasClass
Primary keys are a
traditional relational database concept not normally used in the context of
object-oriented design. However, we have found that having a mechanism for
uniquely identifying an object in the table other than its OID to be a useful
and timesaving concept. Also, specifying primary keys for classes adds rigor to
the design and helps decrease modeling errors. Although not essential to making
the system function, we believe that primary keys should be specified for each
class in the system.
Attributes and/or
object associations may be part of a primary key specification. Primary keys
may be made up of multiples of these attribute/object association components.
Primary key
constraints are checked:
1.
On creation of
objects and every time any of the PK components for that object are updated.
2.
To ensure that
only one object in the class may have a particular set of PK component values.
The only exception is if the PK constraint has been relaxed through a history
specification.
When a PK constraint
fails, an error message should be generated in the form “Primary Key constraint
on class X was violated. Duplicate record found” or “PK constraint on class X
violated component. Component name may not be null.”
Primary keys are
stored in a PK_TX column within the UML_RULE_CLASS table. The syntax for this
is as shown here:
|
Primary Key Type |
Syntax |
|
Attribute |
ATTRIBUTE-name
of attribute |
|
Association |
ASSOCIATION-association_id |
|
Generalization |
SUPERCLASS |
Primary key
components are separated by a comma. Logically, the order of the PK components
is irrelevant. However, because we will be physically instantiating tables
based on the classes, we will form the PK constraint in the same way that
Oracle does, i.e. in the order of its components. This means that searches
based on a subset of the PK components will only take advantage of the index if
the search is based on the first few PK components. If the first PK component
is not in the search criteria, the index will not be used and a full table scan
may be required.
The actual physical
implementation of primary keys uses a PK table behind the scenes with three
columns: Class Name, OID, and PK Value. For PK Value, a text-based
concatenation of the PK values is stored. When records are being inserted into
the generic physical tables, a record is also placed into this centralized PK
table. This allows for rapid and consistent validation of PK values without
requiring complex searches through generic value tables.
Example:
ATTRIBUTE-DEPTNO,ASSOCIATION-123,SUPERCLASS
The abstract property
indicates whether a class is abstract or concrete. (See section 5 about Generalization).
In particular,
concrete classes are characterized as follows:
·
Have
instances,
·
Have their own
attributes, either logical or physical attributes, and
·
Attribute
values belong to the instances of the class
In contrast, abstract
classes are characterized as follows:
·
Cannot
be instantiated, that is, there are no objects of that class in the database,
·
Can have only logical
attributes, and
·
Values of the
attributes physically belong to instances of concrete sub classes
Related BRIM™ Methods
Manipulation
uml_ddl.CreateAbstractClass
uml_ddl.MakeAbstractClass
uml_ddl.MakeConcreteClass
Information
Uml_rep.IsAbstract
Uml_rep.IsAbstractGener
History is specified
by applying the keyword “History” to the class. Note that history can also be
applied to an association, meaning that it is being applied to the automatically
generated association table. With simple history, two additional attributes are
automatically added: StartDate and EndDate.
StartDate and EndDate
are added as attributes to the class.
NOTE: StartDate and
EndDate are not specified in the UML diagrams. By default, start dates and end
dates allow any valid date except where they violate the history constraints as
described below. Both are optional.
Neither the start
date nor the end date may be after the current system date. If you want objects
with future effective dates, you should add additional attributes to the class
for this purpose. The History keyword has a very precise meaning and does not
support this functionality.
If StartDate and
EndDate are both not null, StartDate must be less than EndDate. Records may
exist without Start Date when the start date is indeterminate. This is often
the case for data migrations. However, you cannot have a logically deleted
record without an end date since deleted records are detected by a non-null end
date.
By placing a
“History” keyword on a class, when that class is created in the repository, a
Start Date and End Date will automatically be added to the class.
When you create an
object with history, a start date of sysdate is assigned to the start date
attribute by default. StartDate is an optional parameter in the Create Object
command and can be overridden by passing a start date parameter at object
creation.
StartDate behaves
like any other attribute and can be modified or made null using a Set Attribute
command.
Applying a keyword of
“History” to a class does not affect the behavior of its primary key. This is
equivalent to setting an active flag on a relational database record. The
record still exists. If an Employee with an EmpID as a primary key exists and
history is associated with the Employee class, when the Employee is deleted,
you cannot insert a new employee with the same ID.
To remove the
Employee record from the database, use the overloaded DELETE-OBJECT function.
You can either pass the delete date or the character string “remove” in the
position of the optional parameter. If you pass “remove,” the record will be
removed from the database.
For manipulation
Uml_ddl.CreateHistory,
Uml_ddl.DeleteHistory
For Information:
Uml_rep.GetHistoryType
History has an impact
on the cardinality of rule associations. In particular, sometimes you want the
association to be considered part of the object and the history class. At other
times, you do not. In Figure 2 shown below, there are sales attached to
customers and customers are placed together in customer groups with no more
than ten customers in each group.
Figure 2: History on Associations
Example
If the customer is no
longer in business and needs to be deleted from the system, in the case of a
sale, we do not want the deletion of the customer to orphan the sales records.
Neither do we want to inactivate the association of the sale record since that
would allow the sale objects to be attached to an additional customer.
However, in the
customer group, the opposite situation exists. When the individual customer is
inactivated or deleted, that customer’s position in the customer group should
be available to another customer. Sometimes the deletion of the object should
also invalidate or delete its associations, but not in every case.
The way in which the
engine works, associations are stored independently from the objects that they
attach. Cardinality rules are validated by counting valid records in the
association table. Therefore, in the implementation of history, when a command
is received to delete a history object, this triggers no validation of any
cardinality rules since the engine cannot determine whether cardinality
restrictions should or should not be observed in any given situation.
When deleting history
objects, the applications must determine (on a case by case basis) whether a
particular association should be deleted, invalidated or ignored. The
cardinality rules will be enforced when any attempt is made to invalidate or
delete an existing association.
Complex history
involves the tracking of history on the record and allows duplicate primary key
values in the class, and is called PkHistory.
Primary key history
behaves in a similar way to regular history since start date and end date can
be added. The commands used are the same and behave in the same way with the
following exceptions:
·
When you execute
a Delete command, the associated record is removed from the PK table enabling
the primary key of the class to be reused. Because the primary key is not
really the PK (in the actual physical table) the primary key will be the
logical primary key plus the OID.
·
If you have
multiple records with the same primary key, there is a further stipulation that
the start dates and end dates may not overlap as illustrated in the following
examples.
The following are
examples of successful and unsuccessful insertions to an organization class,
(PK = OrgID)
|
|
Original |
New |
|
|
|
|
Object |
Object |
|
|
|
OrgID |
100 |
100 |
|
|
|
StartDate |
1/Jan/2000 |
1/Jan/2001 |
Succeed |
|
|
EndDate |
1/Jan/2001 |
|
|
|
|
|
|
|
|
|
|
OrgID |
100 |
100 |
|
|
|
StartDate |
Null |
1/Jan/2001 |
Succeed |
|
|
EndDate |
1/Jan/2001 |
|
|
|
|
|
|
|
|
|
|
OrgID |
100 |
100 |
|
|
|
StartDate |
1/Jan/2000 |
1/Jan/2001 |
Fail |
|
|
EndDate |
Null |
Null |
|
|
|
|
|
|
|
|
|
OrgID |
100 |
100 |
|
|
|
StartDate |
1/Jan/2000 |
1/Feb/2000 |
Fail |
|
|
EndDate |
1/Jan/2001 |
Null |
|
|
Effectively, we are
relaxing the PK constraint so that the class may have duplicate primary keys as
long as the StartDate and EndDate do not overlap. This constraint must be
checked every time any primary key columns are changed, when the StartDate or
EndDate attributes are set and whenever an object is created.
The StartDate and
EndDate are implemented in the PARTY_VAL table. The Activ_YN is in the
generated class views.
For manipulation:
Uml_ddl.CreateHistory,
Uml_ddl.DeleteHistory
For Information:
Uml_rep.GetHistoryType(ClassCode)
The audit trail
property allows the user to keep an audit trail of a particular class, that is,
all of the values that a particular class receives over time are stored. This can be useful for a variety of reasons,
including retaining information for auditing purposes or identifying the source
of error in data.
There are
four different types of audit events or changes that the Engine can track, and
they can be grouped into the following two categories:
1.
Object-level
events belong to the objects:
a.
Create
event
b.
Delete
event
c.
Reactivate
event
2.
Value-level events belong to attributes or
associations of the object:
a.
Modify
event
If the
audit event type is modified, the UML Engine will store both old and new
values.
Schematically,
audit data is stored can be represented as shown in Figure 3:
Figure
3: Data Model for Audit Trail
Implementation Notes:
The class
must have no objects. Right now the DDL
command does not support starting an audit trail for instantiated classes.
Once the
audit trail is started the engine will create an audit object for each object
in the audited class and keep track of the changes applied to the object.
Related BRIM™ Methods:
BRIM™ Constants
Uml_system.AuditTrail
– keyword to define class to be audited
Uml_system.CreateAuditEvent
Uml_system.ModifyAuditEvent
constants for events
Uml_system.DeleteAuditEvent
Uml_system.ReactivateAuditEvent
Manipulation
Uml_ddl.StartAuditTrail
Uml_ddl.StopAuditTrail
Information
Uml_rep.HasAudit
The Class Out of
Engine keyword or property allows a class to be implemented outside of the UML
Engine. The UML Engine will not
recognize the objects in that class nor the associations of these objects. Consequently it is not responsible for
enforcing the business rules for that class and its associations.
Classes that are not
in the UML Engine will not be able to take advantage of the features in the
Engine. The following list of features
will be excluded for every class out of the Engine:
1)
Object Builder
support
2)
Multi-lingual
data
3)
Complex
cardinality enforcement
4)
History
5)
Primary Key
History
6)
Audit Trail
7)
Specialization
from a concrete class (specialization from an abstract class is ok)
8)
Subclasses
9)
Primary key
constraints
10)
Domain
enforcement
11)
Class triggers
12)
Association
classes
There are some rules
that govern which classes are available for removal from the engine. These rules make sure that the engine can
maintain the classes in its scope. The
rules for a class to be available for removal are as follows:
1)
The class
cannot be the master in a master-detail association if the detail class is in
the engine.
2)
The class
cannot have a subclass that is in the engine.
3)
The class
cannot have any associations to classes in the engine that have a minimum
cardinality of 1 on the side where it resides.
4)
The class must
be concrete.
5)
The class
cannot be an association class.
6)
The
associations of the class cannot have association classes.
If the class has objects the objects
will be removed from the data repository once the class is out of the engine.
Display functions
take the OID from a class as one of the input parameters and return a string.
Display functions tell the engine how to present a particular object for
viewing.
Display functions
defined for a generalization class will be inherited down to specialization
classes unless overridden by a display function defined for the specialization
class.
An example of how to
display the information would be to display the Account Number followed by a
four letter account code. An alternate
way to display that information would be Account ID and Account Codes in
separate fields.
Account ;
1012247–BOAC (This is what user would see for an account by using display
functionality.)
The developer has the flexibility of writing a display function that supports
these or other requirements.
The display functions
are stored in a database package called Display. This package has consolidated functions for
different classes describing how attribute values should appear to the user.
Each display function
accepts two input parameters:
-
OID: unique identifier of object
-
Disp_mode: preferable display mode
(forwarded from uml.getobjectdisplay)
Each display function
returns one output parameter:
-
Varchar2
Once the display
function is written, it is associated with a particular class. Internally in the engine, this is done by
updating a column in the table uml_rule_class for active rule in the
field disp_funct_cd. This field
is not case sensitive, but data should be stored as package_name.function_name,
such as display.GlAcct_display, in the following example. This task can
also be accomplished using the following special procedure:
set_function (rule in number, m_mode varchar2 default
'c')
Analyses the specification of DISPLAY package for the
functions that can be used for each class, existing in the active rule. It
search for this type of lines in the code:
FUNCTION <Code of class>_DISPLAY. However there is one limitation – this string should start
from the first symbol of the line.
This procedures has the following modes that initiate different behaviors:
- c[opy] repopulate field disp_funct_cd (in
the uml_rule_class) for all classes in the active rule by location of
existing display functions.
- a[dd] add new references to the functions (in the uml_rule_class)
for only those classes, which did not have associated display function
- d[elete] clean field disp_funct_cd (in
the uml_rule_class) for all classes in the active rule
By default,
immediately after creating new rule field disp_funct_cd for all classes
is blank. It should be populated
manually or by using special procedure:
display.class_rule_move
(old_rule_id, new_rule_id, mode)
– moves all associations to display functions for all existing classes from
existing old rule to the new one.
The three modes that
are relevant using this procedure are as follows:
- c[opy] - full overwrite
- a[dd] - add to the New_rule functions
from Old_rule that not exists in New_rule
- f[orce] - overwrite the different
(non-equal) associations in the New_rule from Old_rule. This third mode identifies the differences
between the old rule and the new rule, and only overwrites the differences,
which is faster than doing the full overwrite.
A.
Display
functions are unique for each class.
B.
All display
functions have mode ‘DEFAULT’.
C.
For the
purposes of performance in dsp-function you should avoid joins. For advanced
dsp-modes you should use uml.getobjectdisplay with special modes (see advanced
example). GetObjectDisplay gets the
display of object OID. This function is
used a lot in the front-end.
uml.getobjectdisplay(OID,mode).
Example:
FUNCTION GlAcct_DISPLAY ( oid IN number,
disp_mode IN varchar2 DEFAULT 'DEFAULT')
RETURN VARCHAR2
IS
V_RET VARCHAR2(400);
BEGIN
if disp_mode='DEFAULT' then
SELECT GLACCT_OID||' '||NAME
INTO V_RET
FROM GLACCT
WHERE GLACCT_OID=OID;
elsif disp_mode='SMALL' then
SELECT NAME
INTO V_RET
FROM GLACCT
WHERE GLACCT_OID=OID;
end if;
RETURN V_RET;
EXCEPTION
WHEN no_data_found THEN
return 'Error';
END GLACCT_DISPLAY;
An attribute is a
piece of information about an object. It
is exactly the same as the concept of an attribute in relational database.
There are two important properties of attributes: domain, cardinality. Both are discussed
below.
Each attribute must
be associated with a domain. Each domain has:
1.
Code – without
spaces and special symbols (maximum length = 80 chars)
2.
Name –
descriptive (maximum length = 200 chars).
3.
Data Type
(Oracle-based) – can be:
a.
Varchar2
b.
Number
c.
Date
4.
Default value.
5.
Type (of
domain) – can be:
a.
Simple text –
the same, as varchar2. Maximal length for this type can be populated in the
block ‘Numeric definition’, which in this case looks:
b.
Simple number
– mostly the same, as Number, but can be restricted by minimum and maximum
values and precision
c.
Simple date –
standard date format with user defined precision:
- Year
- Quarter
- Month
- Day
- Hour
- Minute
- Second
d.
Value list –
user-defined data type, that is described by list of possible values, domain
details
6.
Order number –
for reports and sorting purposes.
7.
Active –
status of domain
Description (maximum
length = 2000 chars). Each domain detail has one and only one domain code in
the default database language encoding.
-
Each domain
detail has one or more (at least one) display values in any supported by engine
language.
The logical data
model for domains is shown in Figure 4.
Figure
4: Logical Data Model for Domains
Domain Details have:
1.
Unique
Identifier coming from database sequence
2.
Code – maximum
length = 80 chars
3.
Order number –
for better sorting in the tree structures
4.
Active –
status of domain detail.
5.
Selectable –
allows ignoring some details in the applications it is there to facilitate the
developer in making more meaningful hierarchies of types.
6.
Description
(maximum length = 2000 chars).
Value
List domain may contain a tree structure of values up to seven levels deep.
Tools:
Domain Builder (see
documentation)
Related BRIM™ Methods:
uml_ddl.modifyattributedomain(;
Information
uml_rep.isdomain
uml_rep.getattrdomain
uml_rep.getdomaindatatype
uml_rep.getdomainmaximumnumber
uml_rep.getdomainminimumnumber
uml_rep.getdomainprecision
uml_rep.getdomaintype
In terms of Oracle,
‘cardinality’ can be described as:
-
‘1’ (mandatory
attribute)
-
‘0..1’ (optional attribute)
-
Related BRIM™ Methods:
uml_ddl.modifyattributecardinality(classcode,attrcode,newcard,validationmode);
uml_rep.ismandatory(classcode,associd,stateid)
uml_rep.ismandatory(classcode,attrcode,stateid)
uml_rep.getcardinality(in_card_tx,out_min_nr,out_max_nr);
There are three types
of associations:
1) Simple association
2) Composition
3) Aggregation
There are four
properties of associations:
1)
verb
2)
end class/head
class
3)
end
cardinality/head cardinality
4)
foreign key
The cardinalities
supported by simple association are 0..1, 1, * , 1..*
A phrase and a
direction are attached to all associations as shown in Figure 5. The
directionality is mandatory.
NOTE: Directionality
on a relationship is not the same as navigability. Associations between objects are stored in an
association table where the left side object is associated with the right side
object.
Figure 5: Association direction
5.2
Composition and Aggregation
Composition and
aggregation are types of associations where the child object is closely
associated with the parent object. They
are similar to the idea of the dependent relationship in relational theory. The
UML engine ignores these and treats them just like an association. The object builder does take advantage of
this structure. See the Object Builder
documentation for more details.
Each association is
identified by a verb phrase.
The verb name should
briefly represent the relationship between the two classes involved in the
association.
For user-friendly
interfaces, associations have a verb name. It should be created in such style,
that phrase “<End_Class> <Verb_Name > <Head_Class>” would be
logically correct. Take the following example:
Employee Works in
Department makes
sense
Department Works in
Employee does
not make sense
There is both an
association code (used in diagrams) and an association name (used in
applications).
Related BRIM™ Methods:
Manipulation:
uml_ddl.ModifyAssociationVerb
uml_ddl.ModifyAssociationVerbName
Information:
uml_rep.GetAssociationVerb
uml_rep.GetAssocVerbName
An association is
defined by the classes that are connected to it. But from the prospective of data modeling,
each association has orientation or directionality, that is, one class
associated with the verb is the end class, while the other class associated
with the verb is the head class.
General standards are
illustrated in Figure 6:
Figure
6: End Class, Head Class Illustrated
Association should be
read as “End_Class Verb_Name Head_Class,” which in the example above is
“Employee works in Department.”
Specification of
head/end class determines directionality. Associations always point to the head
class.
Related BRIM™ Methods:
Information:
uml_rep.getheadclass(associd)
uml_rep.getendclass(associd)
5.5 End
Cardinality, Head Cardinality
One of
the main tasks of associations is define (and limit) number of objects on each
side of the association – minimum and maximum. In general, cardinality of each
side of association can be represented as:
<M>..<N>
where M,N 
{0,1,2,…;*}; any integer or unlimited
N 
each object from the opposite side must be
associated with M
Supported
cardinalities are:
0..1 – each object from the other
side may be (optional) associated with no more than 1 object from the specified
side
1 – each object from the other side must be
associated with one and only one object from the specified side.
0..*
– each object from the other side may be (optional) associated with any number
with objects from the specified side
1..*
– each object from the other side MUST be associated with at least one object
from the specified side.
Related BRIM™ Methods:
Information:
uml_rep.ismasterdetail(associd)
uml_rep.getassocinfo(associd)
From the
physical point of view: if there is association between class ‘Emp’ and class
’Dept’, where ‘Emp’ is a child of ‘Dept’,
it means that in the class ‘Emp,’ there has to be column to store unique
identifiers of parent records from the class ‘Dept’. By default, it should be
column Dept_OID. But there may be situations where there is more than one
association between two classes. In such case, there cannot be more than one
column with the same name to store parent IDs. New column names must be used.
To
support this requirement, associations can have keyword ForeignKey. If
association has this keyword – value of this key word will be used as the name of
the column in the child object when it will be generated. Example – financial
book has “Open period” and “Close period”:
Figure
7: Multiple associations between the
same two classes
Without
foreign keys physicalization of the class ‘GlFnclBook’ would have two columns
with the name FyPeriod_oid, which, of course, would give us an error. However,
now we will have column ‘Open’ and column ‘Close’
Related BRIM™ Methods:
uml_ddl.CreateForeignKey;
uml_ddl.DeleteForeignKey;
Information:
uml_rep.GetFkName(associd)
In the
BRIM™
architecture there is possibility, that class should have only one of possible
associations, but not all of them at the same time. For example, budget book
can be built based on either report book, or financial book. This situation is
covered by usage of special logic, called ‘Exclusive OR’
Figure
8: Exclusive Or (XOR) Association
Implementation
Issues:
XOR must
be placed on the “many” side of the association. All associations in the XOR
group must have exactly the same cardinality on both sides.
Related BRIM™ Methods:
uml_ddl.CreateXor
uml_ddl.DeleteXor
Information:
uml_rep.IsXor
uml_rep.IsXored
uml_rep.GetXor
uml_rep.GetXorAssociationList
Generalization is the
identity relationship between a more general element and a more specific element.
Generalizations are specified in the Repository Manager on the generalization
class. Only generalization classes may be {abstract}.
The view
v_inheritance_tree shows the generalization structure for the active rule in
the system.
The view consists of
the following columns:
Class_cd: Shows the SubClass
Head_class: Shows the SuperClass
Abtract_head_YN: Indicates if the head_class is abstract or
not.
First_conc_parent: Shows the first concrete super class of the
subclass
Gener_id: Shows Repository ID of the
generalization
This view shows only
classes that participate in a generalization structure as a subclass or a super
class. Any class may have a single unnamed generalization where it acts as the
generalization class. Concrete classes may instead have any number of named
generalizations. A class may act as a specialization in no more than one
generalization.
Related BRIM™ Methods:
Manipulation:
Uml_ddl.CreateGeneralization,
Uml_ddl.DeleteGeneralization
Uml_rep.GetGeneralizationStructure
Uml_rep.IsGener
Uml_rep.GetAllSub
Uml_rep.GetGenerClass
Uml_rep.IsAbstractGener
Uml_rep.GetGeneralizationId
Uml_rep.GetSuperClass
Uml_rep.GetSuperClass
Uml_rep.GetGenerName
Uml_rep.GetFirstConcreteSubClasses
Uml_rep.GetSubClasses
Uml_rep.GetSuperClasses
Uml_rep.HasSuperClass
Uml_rep.HasConcreteSuperClass