Lo nacional debe contener a lo local, no desenfocarlo.

examples were found. The main purposes of subtyping in the meta model is to generalise common features, and this should be kept as simple as possible. The source and target roles are known as superconcept and subconcept respectively according to their nature. Subtyping is always a one-to-one relationship in meta level, although there may be a number of instances in a subtype concept. The cardinality is not as significant as other relationships.

IPSYS ToolBuilder supports subtyping relationships. Moreover, it allows various data models to be stored as modules. An entity in one module can be a subtype of entity in another module, hence another layer of multiple inheritance is permissible (see appendix B.2.4.1). However, this relationship can only be shown in the structured text and not in the entity diagram. In our meta model, we do not encourage subtyping across concept diagrams, since it loses the semantic dependence. However, we provide different zoom displays which effectively give the same result and do not lose the dependence (see section 5.6 for details). MethodBase’s product part refers to subtyping as is_a relationship, but the fundamental generalisation/specialisation structure amongst concepts is still the same.

5.3.3.2 COMPOSITION

Composition is a bidirectional whole-component relationship. Sometimes it is known as a containment relationship. A concept contains another concept if the concept is a component of the other, or the concept exists within another concept. Composition is denoted by an arrow from source to target with the solid arrow head(s) at the target side. The source and target roles of composition relationship are known as whole and component respectively. This whole-component relationship of concepts forms another type of hierarchy in a concept model. For instance, in OMT, a stateDiagram must have one or more state, and each state

may have an entry Action, an exitAction and a number of internal Actions as shown in figure 5.8. Since all the composition relationships flow out from the abstract state concept, these features apply to all state subtypes, namely startState, interstate and stopState.

action interstate startState stopState exitAction entryAction stateDiagram - - j. internalAction state

5. Product Model

As with subtyping, composition is always bidirectional. Therefore, a concept can navigate through other concepts to a root concept or vice versa. The root concept is an aggregate concept known as method, which comprises of a number of fragment concepts.

By definition, a component must belong to one and only one owner, but not necessarily the same concept type. In other words, the maximum source cardinality is always one, whereas minimum source cardinality can be either zero or one (depicted as question mark in the figure). The optional v-shape arrow head at the source side and the solid arrow head(s) at the target side, are used to depict the minimum and maximum target cardinalities respectively. The four possible combinations of composition cardinalities are shown in figure 5.9.

notation description cardinality example

A B

each A may have zero or one B (?,1,0,1) state activity each A may have zero or many B (?,1,0,n) state internalAction ^ e a c h A must have one B (?,1,1,1) scenario eventTrace < --- ►► each A must have one or more B (?,1,1 ,n) stateDiagram state

Figure 5.9 Composition Cardinalities

In general, the minimum source and target cardinalities show the optionality of the corresponding concepts. For instance, the first example in figure 5.9 shows that each state

must have zero or one activity, so activity is an optional composition for state. On the other hand, the third example shows that each scenario must have one eventTrace, hence this composition is manatory. MethodBase also denotes composition as a has_a relationship, though cardinality and optionality are not represented in its meta model.

5.3.3.3 LINKING

Subtyping and composition are basic relationships which form hierarchical structures. From this section onward, we identify three types of association in the product model. The first one is known as a linking relationship. Unlike subtyping and composition, a linking relationship is denoted by a link concept and normally it is physically shown in a fragment concept with a notation. A link relates two entity concepts, so it includes two parts: a source part connects a link to a source entity and a target part connects it to a target entity. Figure 5.10a shows the method model of a simple stateTransitionDiagram: transition is a link concept and both the source and target entities are state s. Figure 5.10b demonstrates a possible software model for this stateTransitionDiagram. Due to the natural characteristics of a link, the cardinality tuple for both source and target parts is in the form of (0,1,0,1) or (0,n,0,l), (0,1,1,1) or (0,n,l,l), depending on the number of links and whether the link has a choice of different types of concepts or not.

5. Product Model

In the simple stateTransitionDiagram example, each state may be involved in any number of

transitions, whereas each transition must have exactly one source state and one target state

since state is the only entity concept. Therefore, a linking relationship is depicted by a two v- shape arrow head on the link concept and one v-shape arrow head on the entity concept (many-to-1 relationship). The small letter ‘s’ or ‘t’ on the link concept is used to denote the source or target part of a link respectively.

state 7v7\ s V V t transition a. method model so] _[S4] [S2] [S6J S3] [S5] _keys: 0 state -> transition b. software model Figure 5.10 A Simple stateTransitionDiagram Example

Now let us look at a more complex model - the OMT stateDiagram. A state must be one of the startState, interstate or stopState. A startState is only involved in the source part and a

stopState only in the target part, whereas an interstate is involved in both parts as shown in figure 5.11a. Therefore, there are four possible paths for transition: startState to interstate

(e.g. transition LI in figure 5.11b), interstate to interstate (transition L2), interstate to

stopState (transition L3), and startState to stopState. The last path is abnormal, and it is forbidden by the constraint rule (see section 5.3.2.6 for details). Moreover, the link concept

transition has a specialised type automaticTransition. An automaticTransition is a transition

with no event (e.g. LI). This effectively doubles the number of possible paths. We defer the discussion to the exclusion section (see later for details).

state

startStat e (in terStcite s topState ] ^— 7

*

1 \

**

a. method model: transition links

Start . White s turn checkmate stalemate stalemat black moves ■ V white moves Black's turn checkmate Black w ins Draw White wins

b. software model: chess game

5. Product Model

IPSYS ToolBuilder defines linking as composition. When the component part of a composition is the link type, the relationship can refine to a source, a target or both. This complex definition is demanded because the IPSYS ToolBuilder kernel requires that all non­ root concepts are owned by another concept. And since the source and target concepts are the nearest neighbouring concepts, ToolBuilder forces them to hold the ownership. However, we believe that a link should be recognised as an objectified concept between two entity concepts. The ownership of a link should be shared amongst them and eventually lead back to the same fragment. In fact, we have implemented a simple fragment to illustrate this confusion. ToolBuilder have agreed that there is a problem in the link declaration, and they hope to fix it in later versions.

This linking relationship is also seen in the MethodBase product part, though they name the source linking as input relationship and target linking as output relationship. Again, MethodBase has emphasised the method representation, and relationship properties such as cardinalities and roles are omitted.

5.3.3.4 GROUPING

The second type of association in our product model is known as grouping. Similar to linking, grouping is used to relate concepts by an objectificated concept. In this relationship, the concept is called a group. A grouping is always comprised of three components: a host concept, an element concept and the group concept itself. Figure 5.12 illustrates a grouping in OMT. The nestedStateDiagram is the group concept, state is the host concept and

stateDiagram is the element concept. The small letters ‘h’ and ‘e’ are placed at the group concept end to denote the host and element roles of concepts in the association respectively.

stateDiagram ^

nestedStateDiagram state |^ -

Figure 5.12 OMT: nestedStateDiagram Grouping

Unlike composition and subtyping, all grouping relationships are optional. In other words, the host or element does not depend on the group. For instance, a dynamicModel comprises of a number of stateDiagrams and a stateDiagram comprises many state s. A state cannot stand alone without a stateDiagram. Nevertheless, nestedStateDiagram is a navigation concept that routes the host concept state to a lower level element concept stateDiagram, and either state

or stateDiagram can occur in their own right. Grouping is normally an idea or a derived relationship between method concepts so, unlike linking, it does not have a physical notation.

5. Product Model

A grouping has also two parts: the host part connects the group to the host, whereas element part connect the group to the element. Since a group must have at least one host and one element, the cardinality tuple for both host and element parts is in the form (0,1,x,y). Figure 5.13a shows the method model of OMT splittingControl and mergingControl in transition. A

splittingControl must include of one and only one host transition (1-1) and at least two element transitions (2-many). The corresponding cardinality tuples are shown in the figure. Figure 5.13b illustrates the three components in a ATM dispenser software model.

h (0,1,1,1)

splittingControl

e (0,1,2,11)

a

h (0,1,2,n)

K- e(0 ,1,1,1) mergingControl

a. method model: splittingControl and mergingControl

elements cash taken ready card taken host group Setting up

do: eject card

Ready to reset

do: dispense cash

Emitting

b. software model: emtting activity Figure 5.13 OMT: splittingControl and mergingControl Grouping

Group concept can also relate concepts in different fragments. Figure 5.14 shows two decompositions in Ptech. Both product and activity are concepts in the objectFlowDiagram

fragment. The productDecomposition grouping shows the detail of a product in an

objectSchema fragment, whereas the activityDecomposition grouping gives the detail of

activity in an eventSchema fragment. In these two examples, grouping is used for navigation paths, which provide a zooming effect from an entity concept to another type of fragment.

product ^ productDecomposition ^ objectSchem a

activity ^ activityDecomposition eventSchem a

Figure 5.14 Ptech: product and activity Decompositions

IPSYS ToolBuilder does not address grouping relationships. However, navigation of nested fragments or entity decompositions can be supported by a composition relationship. An object operation is defined in the host entity. Again, we find that this is confusing. MethodBase has also missed out this meta relationship.

5. Product Model