CONCEPT RELATIONSHIP PROPERTIES

The SOCRATES project describes concept relationships by specialisation and association. Objectification is an extra feature when the association can be encapsulated as a concept itself. However, there are some useful primitive relationships that have a clear description and occur frequently in concept modelling. We define these relationships as subtyping, composition, grouping, linking and referencing. Before we look at them in detail, it is useful to identify the properties of a concept relationship.

Some meta modelling techniques suggest a rich description of concept relationships. For instance, the OPRR model in MetaEdit identifies property types and role types, whereas the concept structure in SOCRATES defines roles and role numbers in association. However, the other approaches simply ignore their existence, such as the product part in MethodBase. The main reason is the different approaches have different perspectives. MetaEdit is a metaCASE tool, and properties such as roles and cardinalities are important to construct a target tool; SOCRATES represents an information modelling knowledge to capture conceptual details. However, MethodBase needs to demonstrate meta modelling for method integration, whereas the detailed concept properties have less significance.

Nevertheless, in order to give a true and complete representation of SDMs the concept relationship properties are investigated. We look at seven properties, namely cardinality, optionality, directional, role, constraint rule, overlapping and completeness features.

5.3.2.1 CARDINALITY

There are two ways to describe cardinality of relationships. The first way is adopted by most entity relationship models, and is normally known as multiplicity (OOSA, OMT uses this term interchangeably with ‘cardinality’). In this method, there are only three types of cardinality : 1-to-l, 1-to-many and many-to-many relationships. Sometimes (such as OOSA), conditions can be added onto the relationship. The second method is to include both minimum and maximum cardinalities on both sides (such as cardinality constraint in Ptech). It allows relationships such as 0-to-l, 0-to-many, l-to-2 etc.

In our model, we adopt the second method since it contains the optional and mandatory features (see next section). Hence, the cardinality of a concept relationship is a 4-tuple of (minimumSourceCardinality, maximumSourceCardinality, minimumTargetCardinality,

maximumTargetCardinality). For instance, the cardinalities of grouping relationship

splittingControl are (0,1,1,1) on the host side and (0,l,2,n) on the element side, as shown in figure 5.2. In cardinality, n stands for a many (>1) relationship.

5. Product Model

splittingControl h (0,1,1,1) y ,

e (0,1,2,n) transition

Figure 5.2 OMT: splittingControl Grouping Cardinalities

53.2.2

OPTIONALITY

In our product model, optionality is given by the minimumCardinality of each side of a relationship. If the cardinality is zero, the required concept is optional; otherwise the concept is mandatory. In the grouping relationship shown in figure 5.2, splittingControl is an optional group concept, whereas transition is mandatory in both host and element sides.

5.3.2.3 DIRECTIONAL

All concept relationships in our model are described in binary form. For identification purposes we present concept types in a relationship as source and target concepts. A bidirectional relationship is a relationship that is recognised by both concepts, whereas a unidirectional relationship is only recognised by the source concept. Subtyping, composition, grouping and linking are all bidirectional relationships, but the referencing relationship can be either bidirectional or unidirectional depending on the nature of the concept relationship.

Figure 5.3 illustrates the bidirectional linking relationship between process and controlFlow, and the unidirectional referencing relationship from process to operation in OMT.

operation — -— process ^ s >>> controlFlow Figure 5.3 Bi- and Uni- Directional Relationships in process

5.3.2.4 ROLE

Some meta models, such as OPRR, allow user-defined role names. However, in a fixed simplified number of relationships, we choose to use a set of uniform roles. A role is a formal name given to a concept in a relationship. Each relationship connects two concepts, each concept is given a role for identification.

As mentioned in the previous section, all relationships are directional, so the role types can be known as sourceRole and targetRole. The uniform role names of relationships are shown in table 5.1.

5. Product Model

relationship subtyping composition grouping linking referencing

sourceRole superconcept whole group group link link from

targetRole subconcept component host element source target to

notation o

t

\ h / \ e / \ / * \ / \ r /

Table 5.1 Uniform Roles for Concept Relationships

In addition, the corresponding notations are also illustrated. For instance, a subtyping relationship is depicted by drawing the subconcept inside the superconcept, whereas a composition relationship is shown by drawing a solid arrow from the whole to the component. The notations illustrated in the above table only denote the roles of different concept relationships, that is letter labels for different roles in the source end. The multiplicity (none, single, or multiple) of v-shape or solid arrows are used to represent different cardinalities of concepts, and these are not shown in the illustration. However, the notation demonstrates the most common cardinality in each corresponding concept relationship.

5.3.2.5 OVERLAPPING AND COMPLETENESS FEATURES

In some software product models, overlapping and completeness features of relationships are important. For instances, male and female are the disjoint and complete subtypes of human, whereas projectManager and programmer are overlapping and incomplete subtypes of

employee. Some SDM product models identify these two features. The following figure illustrates the above examples in different SDMs.

male female project

DC human manager programmer II employee human female employee project m anager programmer

disjoint/complete overlapping/incomplete complete partition incomplete partition

a. ADM3 b. Ptech

Figure 5.4 Examples of Overlapping and Completeness Features

Figure 5.4a shows the relationships in Firesmith ADM3 (see section 2.5.2) subclassing notation. The features are denoted in the central triangular boxes: DC stands for

5. Product Model

disjoint/complete and 01 stands for overlapping/incomplete. Moreover, the Martin/Odell Ptech partition notation (see section 2.4.4) also depicts the completeness feature. In figure 5.4b, the human subtyping shows a complete partition and the employee subtyping represents an incomplete partition. However, at meta level the distinction is not that significant, and most relationships are in the disjoint/complete category.

These features are not directly denoted in the concept diagram for the following three reasons. Firstly, a complete representation is required for our product model to documenting concept relationships, therefore no incomplete partition is allowed. Secondly, overlapping concepts are very rare in method modelling, and then they can be described by subtyping of multiple supertypes. Finally, if it is really necessary to describe these features, the particular relationships can be denoted as constraint rules in the concept heuristic model (see chapter seven for details). The next section briefly describes the constraint rule and method representation is discussed in chapter eight.

5.3.2.6 CONSTRAINT RULE

The relationship properties mentioned above should be able to document most conditions in a concept relationship. However, there are some special constraints which are very difficult to denote. We shall identify two examples to illustrate these description problems. The first one is a typical example in a dataFlowDiagram (also refer to figure 3.12) and the second one is a special complex pattern of objectDescriptionSkeleton in HOOD (see section 2.4.2).

In a dataFlowDiagram, as shown in figure 5.5, dataFlow is used to represent data passing amongst process, dataStore and actor (sometimes known as source or sink). However, the model should detect and avoid dataFlow connecting directly from dataStore to actor or vice versa. This is because dataflow only occurs through the data transformation in process, and by definition a static data transfer between dataStore and actor is not allowed. This can be considered as a meta relationship between the source and target links of a dataFlow. There is no easy way to document this constraint in the model.

dataFlowDiagram actor

7F F

vv

v v 7 \ process

"7o r

vv

dataFlow dataStore ^ 7 0 T

\/vt

s V V t

_vv

5. Product Model

We shall now look at a more complicated example. In HOOD, objectDescriptionSkeleton

describes each object by an objectType, where objectType must be one of passive, active, environmentPassive, environment Active, classPassive, class Active, instanceOf, opControl or

virtualNode (this list of concepts is in fact a complete composition partition of the concept

objectType). objectDescriptionSkeleton A object _<■ providedlnterface

T

objectType

passive] [environmentPassive] classPassive active | environmentActive ] classActive

[ opControl

instanceOf virtualNode

objectControlStructure operationControlStructure

Figure 5.6 HOOD: objectType Subtyping

The objectType affects the layout of objectDescriptionSkeleton, since certain parts of the

objectDescriptionSkeleton are optional. The following table shows the optional sections included according to objectType.

objectType description

passive no objectControlStructure active contains objectControlStructure environment providedlnterface only

class contains formalP ammeters

instanceOf refers to class and has parameters

opControl no providedlnterface, internals contain one operationControlStructure virtualNode allocation to physical node always a parent so no operationControlStructure

Table 5.2 HOOD: objectDescriptionSkeleton layout based on objectType

There is no simple way to get round these representation difficulties, other than using a formal description of the internal constraints. In our product model we document them as concept rules in the heuristic model. The concept relationship or fragment is valid only if all of the rules attached with it are satisfied, i.e. a well-formed product model should necessarily meet the conditions (see section 5.5 for details). We place a letter ‘c’ at the top-right comer of the concept box to indicate that a constraint rule is bound to that concept. For instance, in figure 5.5, dataflow is a constrained concept, whereas three conditioned concepts are shown in figure 5.6.

5. Product Model

In document A generic model for representing software development methods (Page 111-116)