ISO/IEC 24744:2007
(Main)Software Engineering — Metamodel for Development Methodologies
Software Engineering — Metamodel for Development Methodologies
Development methodologies may be described in the context of an underpinning metamodel, but the precise mechanisms that permit them to be defined in terms of their metamodels are usually difficult to explain and do not cover all needs. For example, it is difficult to devise a practice that allows the definition of properties of the elements that compose the methodology and, at the same time, of the entities (such as work products) created when the methodology is applied. ISO/IEC 24744:2007 introduces the Software Engineering Metamodel for Development Methodologies (SEMDM), a comprehensive metamodel that makes use of a new approach to defining methodologies based on the concept of powertype. The aim of SEMDM is to define methodologies in information-based domains, i.e. areas characterized by their intensive reliance on information management and processing, such as software, business or systems engineering. The SEMDM combines key advantages of other metamodelling approaches with none of their known drawbacks, allowing the seamless integration of process, modelling and people aspects of methodologies. Examples are given where other metamodels are mapped to SEMDM and a brief synopsis of problems is provided. Various methodologies are defined, used, or implied by a growing number of standards, and it is desirable that the concepts used by each methodology be harmonized. A vehicle for harmonization is the SEMDM. Conformance to this metamodel will ensure a consistent approach to defining each methodology with consistent concepts and terminology.
Ingénierie du logiciel — Métamodèle pour les méthodologies de développement
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 24744
First edition
2007-02-15
Software Engineering — Metamodel for
Development Methodologies
Ingénierie du logiciel — Métamodèle pour les méthodologies de
développement
Reference number
ISO/IEC 24744:2007(E)
©
ISO/IEC 2007
---------------------- Page: 1 ----------------------
ISO/IEC 24744:2007(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 2007
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2007 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 24744:2007(E)
Contents Page
1 Scope. 1
1.1 Purpose. 1
1.2 Audience. 1
2 Conformance. 2
3 Terms and definitions. 2
4 Naming, diagramming and definition conventions, and abbreviated terms . 4
4.1 Naming, diagramming and definition conventions. 4
4.2 Abbreviations. 5
5 Basic Concepts. 5
5.1 Method Engineering. 6
5.2 Dual-Layer Modelling . 6
5.3 Powertypes and Clabjects. 6
5.4 Uniting Process and Product. 7
5.5 Process Assessment. 7
6 Introduction to the SEMDM . 8
6.1 Highly Abstract View. 8
6.2 Abstract View and Core Classes. 8
6.3 Process Classes. 9
6.4 Producer Classes. 11
6.5 Product Classes . 12
6.6 Connection between Process and Product. 13
6.7 Support Classes. 14
7 Metamodel Elements. 15
7.1 Classes . 15
7.2 Enumerated Types. 63
8 Using the Metamodel. 64
8.1 Usage Rules. 64
8.2 Usage Guidelines. 65
9 Extending the Metamodel. 66
9.1 Extension Rules. 66
9.2 Extension Guidelines. 67
Annex A (informative) Worked Example . 68
Annex B (informative) Mappings to Other Metamodelling Approaches. 74
Bibliography . 78
iii
© ISO/IEC 2007 – All rights reserved
---------------------- Page: 3 ----------------------
ISO/IEC 24744:2007(E)
Table of Figures
Figure 1 – The three areas of expertise, or domains, which act as a context for SEMDM . 5
Figure 2 – Highly abstract view of the SEMDM. 8
Figure 3 – Abstract view of the SEMDM, showing the core classes in the metamodel. 9
Figure 4 – Work units .10
Figure 5 – Stages .11
Figure 6 – Producers .12
Figure 7 – Work product and modelling classes .13
Figure 8 – Actions and constraints .14
Figure 9 – Support classes .14
iv © ISO/IEC 2007 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC 24744:2007(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 24744 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering.
© ISO/IEC 2007 – All rights reserved v
---------------------- Page: 5 ----------------------
ISO/IEC 24744:2007(E)
Introduction
Development methodologies may be described in the context of an underpinning metamodel, but the precise
mechanisms that permit them to be defined in terms of their metamodels are usually difficult to explain and do
not cover all needs. For example, it is difficult to devise a practice that allows the definition of properties of the
elements that compose the methodology and, at the same time, of the entities (such as work products)
created when the methodology is applied. This International Standard introduces the Software
Engineering Metamodel for Development Methodologies SEMDM, a comprehensive metamodel that makes
use of a new approach to defining methodologies based on the concept of powertype. The SEMDM is aimed at
the definition of methodologies in information-based domains, i.e. areas characterized by their intensive reliance
on information management and processing, such as software, business or systems engineering. The
SEMDM combines key advantages of other metamodelling approaches with none of their known drawbacks,
allowing the seamless integration of process, modelling and people aspects of methodologies. Refer to
Annex B where other metamodels are mapped to SEMDM and a brief synopsis of problems is provided.
Various methodologies are defined, used or implied by a growing number of standards and it is desirable that
the concepts used by each methodology be harmonized. A vehicle for harmonization is the SEMDM.
Conformance to this metamodel will ensure a consistent approach to defining each methodology with
consistent concepts and terminology.
vi
© ISO/IEC 2007 – All rights reserved
---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO/IEC 24744:2007(E)
Software Engineering — Metamodel for Development
Methodologies
1 Scope
This International Standard defines the Software Engineering Metamodel for Development Methodologies
(SEMDM), which establishes a formal framework for the definition and extension of development
methodologies for information-based domains (IBD), such as software, business or systems, including three
major aspects: the process to follow, the work products to use and generate, and the people and tools involved.
This metamodel can serve as a formal basis for the definition and extension of any IBD development
methodology and of any associated metamodel, and will be typically used by method engineers while
undertaking such definition and extension tasks.
The metamodel does not rely upon nor dictate any particular approach to IBD development and is, in fact,
sufficiently generic to accommodate any specific approach such as object-orientation, agent-orientation,
component-based development, etc.
1.1 Purpose
This International Standard follows an approach that is minimalist in depth but very rich in width
(encompassing domains that are seldom addressed by a single approach). It therefore includes only those
higher-level concepts truly generic across a wide range of application areas and at a higher level of
abstraction than other extant metamodels. The major aim of the SEMDM is to deliver a highly generic
metamodel that does not unnecessarily constrain the resulting methodologies, while providing for the creation
of rich and expressive instances.
In order to achieve this objective, the SEMDM incorporates ideas from several metamodel approaches plus
some results of recent research (see [1-7] for details). This will facilitate:
• The communication between method engineers, and between method engineers and users of
methodology (i.e. developers);
• The assembly of methodologies from pre-existing repositories of method fragments;
• The creation of methodology metamodels by extending the standard metamodel via the extension
mechanisms provided to this effect;
• The comparison and integration of methodologies and associated metamodels; and
• The interoperability of modelling and methodology support tools.
The relation of SEMDM to some existing methodologies and metamodels is illustrated in Annex B.
1.2 Audience
Since many classes in the SEMDM represent the endeavour domain (as opposed to the methodology domain),
it might look like developers enacting the methodology would be direct users of the metamodel. This is not
true. Classes in the SEMDM that model endeavour-level elements serve for the method engineer to establish
the structure and behaviour of the endeavour domain, and are not used directly during enactment. Only
© ISO/IEC 2007 – All rights reserved 1
---------------------- Page: 7 ----------------------
ISO/IEC 24744:2007(E)
methodology elements, i.e. classes and objects created by the method engineer from the metamodel, are
used by developers at the endeavour level, thus supporting both the creation of “packaged” methodologies as
well as tailored, project-specific methodologies.
Here the term “method engineer” refers collectively to either a person constructing a methodology on site for a
particular purpose or a person creating a "packaged" methodology as a "shrink-wrapped" process product.
2 Conformance
A metamodel is defined in accordance with this International Standard if it:
describes the scope of the concepts in the metamodel in relation to the scope of the elements defined
•
in Clause 7; and
defines the mapping between the concepts that are addressed in the metamodel, and that are within
•
the scope of this International Standard, and the corresponding elements of this International Standard
(i.e. its elements cannot be substituted by others of identical intent but different construction).
A development methodology is defined in accordance with this International Standard if it is generated from a
conformant metamodel as defined in the first paragraph of this clause (2 Conformance).
A development or engineering tool is developed in accordance with this International Standard if it implements
a conformant metamodel as defined in the first paragraph of this clause (2 Conformance). If the purpose of the
tool involves the creation of methodologies, then it is developed in accordance with this International Standard
if it also implements the necessary features so as to make the mechanisms described in 8.1 available to
the tool’s users. If the purpose of the tool involves the extension of the metamodel, then it is developed in
accordance with this International Standard if it also implements the necessary features so as to make the
mechanisms described in 9.1 available to the tool’s users.
NOTE 1 The metamodel thus defined does not necessarily have to include all the elements defined in
Clause 7 – only those that are relevant to the purpose of the said metamodel are required.
NOTE 2 Conformance for methodologies or conformance for tools can be established without any necessity of
explicitly including the detailed metamodel for any relevant work product kind or model unit kind. It is adequate
to define the mappings of any such work products to the WorkProductKind and ModelUnitKind classes of the
SEMDM.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply. Unless otherwise noted, the definitions
are specific to this International Standard.
The following concepts are defined only for their usage throughout this International Standard.
NOTE – This International Standard uses a self-consistent set of core concepts that is as compatible as possible
with other International Standards (such as ISO/IEC 12207, ISO/IEC 15504, etc.).
3.1
information-based domain
IBD
realm of activity for which information is the most valuable asset
NOTE This means that information creation, manipulation and dissemination are the most important
activities within information-based domains. Typical information-based domains are software and
systems engineering, business process reengineering and knowledge management.
2 © ISO/IEC 2007 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC 24744:2007(E)
3.2
methodology
specification of the process to follow together with the work products to be used and generated, plus the
consideration of the people and tools involved, during an IBD development effort
NOTE A methodology specifies the process to be executed, usually as a set of related activities, tasks and/or
techniques, together with the work products that must be manipulated (created, used or changed) at each moment and by
whom, possibly including models, documents and other inputs and outputs. In turn, specifying the models that must be
dealt with implies defining the basic building blocks that should be used to construct.
3.3
method
synonym of methodology
NOTE The term “methodology” is used throughout this International Standard, reserving the term “method” for
conventional phrases such as “method engineer” or “method fragment”.
3.4
metamodel
specification of the concepts, relationships and rules that are used to define a methodology
3.5
endeavour
IBD development effort aimed at the delivery of some product or service through the application of a
methodology
EXAMPLES Projects, programmes and infrastructural duties are examples of endeavours.
3.6
methodology element
simple component of a methodology
NOTE Usually, methodology elements include the specification of what tasks, activities, techniques, models,
documents, languages and/or notations can or must be used when applying the methodology. Methodology elements are
related to each other, comprising a network of abstract concepts. Typical methodology elements are Capture
Requirements, Write Code for Methods (kinds of tasks), Requirements Engineering, High-Level Modelling (kinds of
activities), Pseudo-code, Dependency Graphs (notations), Class, Attribute (kinds of model building blocks), Class Model,
Class Diagram, Requirements Specification (kind of work products), etc.
3.7
endeavour element
simple component of an endeavour
NOTE During the execution of an endeavour, developers create a number of endeavour elements, such as tasks,
models, classes, documents, etc. Some examples of endeavour elements are Customer, Invoice (classes), Name, Age
(attributes), High-Level Class Model number 17 (a model), System Requirements Description (a document), Coding Cycle
number 2, Coding Cycle number 3 (tasks), etc.
3.8
generation
act of defining and describing a methodology from a particular metamodel. Generating a methodology
includes explaining the structural position and semantics of each methodology element using the selected
metamodel. Thus, what methodology elements are possible, and how they relate to each other, are
constrained by such a metamodel. Usually, method engineers perform generation, yielding a complete and
usable methodology.
3.9
enactment
act of applying a methodology for some particular purpose, typically an endeavour
NOTE Enacting a methodology includes using the existing generated methodology to create endeavour elements
and, eventually, obtain the targeted IBD system. Thus, what kinds of endeavour elements can be created, and how they
relate to each other, is governed by the methodology being used. Usually, technical managers, together with other
developers, perform enactment.
© ISO/IEC 2007 – All rights reserved 3
---------------------- Page: 9 ----------------------
ISO/IEC 24744:2007(E)
3.10
method engineer
person who designs, builds, extends and maintains methodologies
NOTE Method engineers create methodologies from metamodels via generation.
3.11
developer
person who applies a methodology for some specific job, usually an endeavour
NOTE Developers apply methodologies via enactment.
3.12
powertype
A powertype of another type, called the partitioned type, is a type the instance of which are subtypes of the
partitioned type. This definition is interpreted in the context of the object-oriented paradigm. For example, the
class TreeSpecies is a powertype of the class Tree, since each instance of TreeSpecies is also a subclass of
Tree.
3.13
clabject
dual entity that is a class and an object at the same time
NOTE This definition is interpreted in the context of the object-oriented paradigm. Because of their dual nature,
clabjects exhibit a class facet and an object facet, and can work as either at any time. Instances of powertypes are usually
viewed as clabjects, since they are objects (because they are instances of a type, the powertype) and also classes
(subtypes of the partitioned type).
4 Naming, diagramming and definition conventions, and abbreviated terms
4.1 Naming, diagramming and definition conventions
The SEMDM is defined using different kinds of instruments that complement each other. These instruments
are:
• Definitions. Each concept in the SEMDM is defined using natural language. Also, a description is
given, including the context in which the concept occurs and its most distinctive properties. Examples
are also given for each concept.
• Class diagrams. Concepts of interest to the SEMDM are formalized as classes. Consequently, class
diagrams are used to show these classes together with their attributes and relationships. UML 1.4.2
(i.e. ISO/IEC 19501) is used throughout with some noticeable exceptions. First, a special notation is
used to depict powertype patterns, consisting of a dashed line between the powertype and the
partitioned type with a black dot on the side of the powertype. Secondly, “white diamonds” are used to
depict whole/part relationships without making any reference to their secondary characteristics (see
[8] for more details).
• Text tables. Text tables are included to provide additional descriptions of attributes and relationships.
• Mappings to other approaches. Each concept in the SEMDM is related to equivalent or similar
concepts in other metamodelling approaches, so that translation between approaches is easier.
These instruments are used simultaneously.
Two different types of class diagrams are provided. Clause 6 presents some diagrams that aim to give an
overall picture of the structure of SEMDM. These diagrams are designed to give an idea of the main classes
and relationships within the metamodel, and are not comprehensive, i.e. do not display every single detail of
the metamodel. Clause 7, on the other hand, includes a class diagram for each class in the metamodel. The
class under discussion is shown in the centre, and is surrounded by its closest neighbours. Each of these
diagrams, together with the accompanying attribute and relationship tables, do contain all the details for the
particular class being discussed.
4
© ISO/IEC 2007 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC 24744:2007(E)
The philosophy of the SEMDM is to offer broad coverage for all the issues often found in methodology
definition avoiding, at the same time, unnecessary structural constraints on the resultant methodologies.
Therefore, only a minimal set of attributes and associations is provided by the metamodel. Using powertype
pattern instantiation (see sub-clause 8.1.2), and thanks to the usage of powertypes in the metamodel,
additional attributes and associations can be easily added at the methodology domain.
4.2 Abbreviations
information-based domain
IBD
SEMDM software engineering metamodel for development methodologies
5 Basic Concepts
Metamodels are useful for specifying the concepts, rules and relationships used to define methodologies.
Although it is possible to describe a methodology without an explicit metamodel, formalizing the underpinning
ideas of the methodology in question is valuable when checking its consistency or when planning extensions
or modifications. A good metamodel must address all of the different aspects of methodologies, i.e. the
process to follow, the work products to be generated and those responsible for making all this happen. In turn,
specifying the work products that must be developed implies defining the basic modelling building blocks from
which they are built.
Metamodels are often used by method engineers to construct or modify methodologies. In turn,
methodologies are used by developers to construct products or deliver services in the context of endeavours.
Metamodel, methodology and endeavour constitute, in this approach, three different areas of expertise that, at
the same time, correspond to three different levels of abstraction and three different sets of fundamental
concepts. As the work performed by developers at the endeavour level is constrained and directed by the
methodology in use, the work performed by the method engineer at the methodology level is constrained and
directed by the chosen metamodel. Traditionally, these relationships between “modelling layers”, here called
“domains”, are seen as instance-of relationships, in which elements in one layer or domain are instances of
some element in the layer or domain below (Figure 1).
Endeavour Domain
Methodology Domain
Metamodel Domain
Figure 1 – The three areas of expertise, or domains, which act as a context for SEMDM
Regarding the methodology domain, it must be noted that more than one “methodology” may exist at this level,
interlinked by refinement relationships. For example, it is common that organizations create organization-wide,
generic methodologies from a metamodel, and then adjust and customize said methodologies for each
particular endeavour. In cases like this, both kinds of methodologies (organization-wide and endeavour-
specific) belong in the methodology domain and are connected via a refinement relationship (as opposed to
instance-of). Cases with more than two steps of refinement are also possible.
5
© ISO/IEC 2007 – All rights reserved S
---------------------- Page: 11 ----------------------
ISO/IEC 24744:2007(E)
5.1 Method Engineering
In accordance with most of the above-mentioned approaches to metamodelling, the SEMDM accepts the idea
of method engineering (see [9, 10] for an introduction), defining the metamodel as a set of classes from which
“methodology chunks” can be generated and then composed into a usable methodology [11]. However, the
method engineering approach has been used primarily in the process realm (and hence the often-used name
of “process engineering”), whereas the SEMDM extends it to the modelling domain as well (see 5.2).
5.2 Dual-Layer Modelling
Most metamodelling approaches define a metamodel as a model of a modelling language, process or
methodology that developers may employ. Following this conventional approach, classes in the metamodel
are used by the method engineer to create instances (i.e. objects) in the methodology domain and thus
generate a methodology. However, these objects in the methodology domain are often used as classes by
developers to create elements in the endeavour domain during methodology enactment. This apparent
contradiction, not solved by any of the existing metamodelling approaches, is addressed by the SEMDM and
solved by conceiving a metamodel as a model of both the methodology and the endeavour domains. While
offering a strict model of the endeavour domain in the metamodel, the SEMDM maintains a high degree of
flexibility, allowing the method engineer to configure the development process an
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.