6.8 CLASSES IN ISO/IEC 24744

In the sections above, we have described groups of xxx/*Kind classes in the ISO/IEC 24744 metamodel. This international standard provides many more details about every one of these classes and subclasses. The format used for each class is not only to describe the class in detail (including its definition and attributes) but also the relationships with its “nearest neighbours” both in terms of associative relationships and also the generalization to its supertype. Thus each class is documented graphically, with natural language and in tabular form. We have extracted two such class definitions from the standard as a sample: those for Action and for ModelKind.

6.8.1 Action Class Definition

An action is defined in ISO/IEC 24744 as a usage event performed by a task upon a work product. Actions represent the fact that specific tasks use specific work products. Action, an abstract subclass of EndeavourElement, is classified by ActionKind (Figure 6.16) and associated to both WorkProduct and task. This is, therefore, a process- and product-related class.

Figure 6.16: Action class and its neighbours (after [16])

Source: ISO/IEC, 2007, copyright International Organization for standardization, Geneva. Reproduced with permission

For example, as part of a software development project, developer Juan is responsible for a programming task (a task) that involves making modifications to the source code file “Invoice.cs” (a work product). What Juan does in undertaking this programming task and changing the work product is formally called an action in SEMDM.

6.8.2 ModelKind Class Definition

A model kind is a specific kind of model, characterized by its focus, purpose and level of abstraction. It is a product-related subclass of WorkProductKind (Figure 6.17). It provides a classification mechanism for Model and is linked both to ModelUnits (via the ModelUnitUsageKind) and to Language. Its usage can be exemplified as follows.

In a particular software development methodology, it is necessary to describe both the structure and behaviour of the software system to be built. Whenever the methodology is enacted (i.e. utilized on a specific project), the structure of the system will be represented by a structural model, whereas the behaviour of the system will be represented by a dynamic model. This means that the developer creates both a structural model and a dynamic model, which are the Endeavour-domain realization of the two model kinds, “Structural Model” and “Dynamic Model”, that were created by the method engineer.

Figure 6.17: ModelKind and its neighbours (after [16])

Source: ISO/IEC, 2007, copyright International Organization for standerdization, Geneva. Reproduced with permission