artefact(orientation:(concepts(and(terms -...
TRANSCRIPT
-‐ 1
Artefact Orientation: Concepts and Terms
Daniel Mendez, Manfred Broy The paper at hand discusses concepts and terms for artefact orientation. The purpose of the paper is to lay a brief foundation on the basic concepts of artefact orientation and to define the terminology as used at the research group on Software & Systems Engineering at the Technische Universität München. Artefact orientation has become an indispensible support in different areas of application in order to support flexibility in the lifecycle process, precision in the results, and a standardised terminology, e.g., among different project participants. The basic idea of artefact orientation consists of concentrating on the required results rather than on the activities to produce the results. A typical scenario of applying artefact orientation can be found in requirements engineering (RE) where we would establish a blueprint of the created RE results (and their contents), thus, abstracting from the processes for creating the results by the use of particular methods and modelling notations. As such an artefact model abstracts from complex RE processes while capturing the various (modelling) concepts of the application domain, they provide a basis for a flexible process in which team participants agree on the content and the structure of the artefacts to be created while leaving open the way of creating the results. However, while the benefits of artefact orientation are recognised, yet missing is a common agreement on the basic concepts and terms used in artefact orientation. One major reason is that artefact orientation itself is, like quality, a multi-‐facetted concept with different areas of application and, thus, various interpretations. Artefacts are seen as, for example, documents or data sets, while artefact models are often set equal to, for example, ontologies, meta models or concept models, or document models. Therefore, we describe in the following what artefacts are before discussing the notion of artefact orientation.
Artefacts and Artefact Models To clarify the notion of artefact orientation, we first need to understand what artefacts are. An artefact is any form of representation of significant (in the sense of required by a process) intermediate or final work product (result) of the development process. An artefact has structure, content, and it is formulated in some syntactic language. During project planning, it has then to be defined as part of artefact models:
• What the structure of the artefact shall be (including the relations to other artefacts and their contents) • What the contents of an artefact shall be • With which language (including description techniques) artefacts shall be described
When creating and managing an artefact, it is captured in different forms: 1. Text documents (on paper or in files) 2. Data objects and models persisted in data bases or in tools
For each of the created artefacts, we opt (independently of the forms of materialisation) for particular modelling techniques used to represent the artefacts in a structured way. In summary and as depicted in Fig. 1, we distinguish between the content of the artefacts, the way of representing the contents and the structure of an artefact used to create (structured) artefacts in different ways of materialisation.
Figure 1 Different Views on Artefact Models during Artefact Creation
The following table shows the exemplary (and simplified) differentiation between the three previously introduced concepts of artefacts’ contents, their allocation to a particular artefact, and exemplary techniques for their representation.
Met
a M
odel
RE
Ref
eren
ce M
odel
Structure Content
Proj
ect-s
peci
fic
Exem
plar
s
inst
ance
of
inst
ance
of
!
PRODUKT.PROJEKTBEZEICHNUNG - PRODUKT.NAME
Zuletzt geändert: 27.10.2010 13:28 3/20
Content
1! Introduction .......................................................................................................................... 6!
1.1! Overview ....................................................................................................................... 6!
1.2! Purpose .......................................................................................................................... 6!
1.3! References ..................................................................................................................... 7!
1.4! Scope ............................................................................................................................. 8!
2! System Vision ...................................................................................................................... 8!
2.1! Summary of Business Specification.............................................................................. 8!
2.2! Scope of Information System under Consideration ...................................................... 8!
2.2.1! System Overview ................................................................................................... 8!
2.2.2! External Systems .................................................................................................. 10!
2.2.3! Use Case Overview .............................................................................................. 10!
2.2.4! Information System Service Overview ................................................................ 10!
3! Information System Requirements..................................................................................... 11!
3.1! Actors .......................................................................................................................... 11!
3.2! Generic Scenarios........................................................................................................ 11!
3.3! Domain-specific Application Capabilities .................................................................. 12!
3.3.1! <<Business Domain>> <Name>.......................................................................... 12!
3.4! Information System Objects........................................................................................ 14!
3.5! System Quality Requirements..................................................................................... 16!
3.6! Architectural Constraints............................................................................................. 16!
3.6.1! Logical Restrictions.............................................................................................. 17!
3.6.2! Technical Restrictions .......................................................................................... 17!
4! Integrational Requirements ................................................................................................ 18!
4.1! Deployment Requirements.......................................................................................... 18!
4.2! Migration Requirements.............................................................................................. 18!
5! Organisational Requirements ............................................................................................. 19!
5.1! Project Requirements .................................................................................................. 19!
5.2! Obligations .................................................................................................................. 19!
5.3! Glossary....................................................................................................................... 19!
6! Abbreviations ..................................................................................................................... 20!
7! References .......................................................................................................................... 20!
Travel Ordering System
Requirements Specification
Version: 0.1
Project Name <Name>
Project Lead <Name>
Responsible <Name>
Created on <Date>
Last changed
X In process
Submitted
State
Completed
Document File
V-Modell XT Version VMRELEASE 1.3with BISA Extension
illustrative
Met
a M
odel
RE
Ref
eren
ce M
odel
Structure Content
Proj
ect-s
peci
fic
Exem
plar
s
inst
ance
of
inst
ance
of
!
PRODUKT.PROJEKTBEZEICHNUNG - PRODUKT.NAME
Zuletzt geändert: 27.10.2010 13:28 3/20
Content
1! Introduction .......................................................................................................................... 6!
1.1! Overview ....................................................................................................................... 6!
1.2! Purpose .......................................................................................................................... 6!
1.3! References ..................................................................................................................... 7!
1.4! Scope ............................................................................................................................. 8!
2! System Vision ...................................................................................................................... 8!
2.1! Summary of Business Specification.............................................................................. 8!
2.2! Scope of Information System under Consideration ...................................................... 8!
2.2.1! System Overview ................................................................................................... 8!
2.2.2! External Systems .................................................................................................. 10!
2.2.3! Use Case Overview .............................................................................................. 10!
2.2.4! Information System Service Overview ................................................................ 10!
3! Information System Requirements..................................................................................... 11!
3.1! Actors .......................................................................................................................... 11!
3.2! Generic Scenarios........................................................................................................ 11!
3.3! Domain-specific Application Capabilities .................................................................. 12!
3.3.1! <<Business Domain>> <Name>.......................................................................... 12!
3.4! Information System Objects........................................................................................ 14!
3.5! System Quality Requirements..................................................................................... 16!
3.6! Architectural Constraints............................................................................................. 16!
3.6.1! Logical Restrictions.............................................................................................. 17!
3.6.2! Technical Restrictions .......................................................................................... 17!
4! Integrational Requirements ................................................................................................ 18!
4.1! Deployment Requirements.......................................................................................... 18!
4.2! Migration Requirements.............................................................................................. 18!
5! Organisational Requirements ............................................................................................. 19!
5.1! Project Requirements .................................................................................................. 19!
5.2! Obligations .................................................................................................................. 19!
5.3! Glossary....................................................................................................................... 19!
6! Abbreviations ..................................................................................................................... 20!
7! References .......................................................................................................................... 20!
Travel Ordering System
Requirements Specification
Version: 0.1
Project Name <Name>
Project Lead <Name>
Responsible <Name>
Created on <Date>
Last changed
X In process
Submitted
State
Completed
Document File
V-Modell XT Version VMRELEASE 1.3with BISA Extension
illustrative
Met
a M
odel
RE
Ref
eren
ce M
odel
Structure Content
Proj
ect-s
peci
fic
Exem
plar
s
inst
ance
of
inst
ance
of
!
PRODUKT.PROJEKTBEZEICHNUNG - PRODUKT.NAME
Zuletzt geändert: 27.10.2010 13:28 3/20
Content
1! Introduction .......................................................................................................................... 6!
1.1! Overview ....................................................................................................................... 6!
1.2! Purpose .......................................................................................................................... 6!
1.3! References ..................................................................................................................... 7!
1.4! Scope ............................................................................................................................. 8!
2! System Vision ...................................................................................................................... 8!
2.1! Summary of Business Specification.............................................................................. 8!
2.2! Scope of Information System under Consideration ...................................................... 8!
2.2.1! System Overview ................................................................................................... 8!
2.2.2! External Systems .................................................................................................. 10!
2.2.3! Use Case Overview .............................................................................................. 10!
2.2.4! Information System Service Overview ................................................................ 10!
3! Information System Requirements..................................................................................... 11!
3.1! Actors .......................................................................................................................... 11!
3.2! Generic Scenarios........................................................................................................ 11!
3.3! Domain-specific Application Capabilities .................................................................. 12!
3.3.1! <<Business Domain>> <Name>.......................................................................... 12!
3.4! Information System Objects........................................................................................ 14!
3.5! System Quality Requirements..................................................................................... 16!
3.6! Architectural Constraints............................................................................................. 16!
3.6.1! Logical Restrictions.............................................................................................. 17!
3.6.2! Technical Restrictions .......................................................................................... 17!
4! Integrational Requirements ................................................................................................ 18!
4.1! Deployment Requirements.......................................................................................... 18!
4.2! Migration Requirements.............................................................................................. 18!
5! Organisational Requirements ............................................................................................. 19!
5.1! Project Requirements .................................................................................................. 19!
5.2! Obligations .................................................................................................................. 19!
5.3! Glossary....................................................................................................................... 19!
6! Abbreviations ..................................................................................................................... 20!
7! References .......................................................................................................................... 20!
Travel Ordering System
Requirements Specification
Version: 0.1
Project Name <Name>
Project Lead <Name>
Responsible <Name>
Created on <Date>
Last changed
X In process
Submitted
State
Completed
Document File
V-Modell XT Version VMRELEASE 1.3with BISA Extension
illustrative
Content Representation of Content (Structured) Artefacts
(Ontologies, Meta Models, Checklists, ...)
(Diagrams, Models, Natural Text) (Documents, Data Models)
(Pac
kage
/ Do
cum
ent
Hier
arch
yl)
-‐ 2
Content Description Technique (Representation)
Artefact
Requirement definition Structured text / tables Requirements specification
Logical architecture model Component diagram System specification
… … … Please note that the notion of structure comprehends all three concepts, e.g., the definition of the content of an artefact with a content model always implies a notion of structure. Same holds for the representation of an artefact that contains a notion of structure and, finally, the materialisation of the created artefact, e.g., organised according to a predefined package structure. Artefact models capture all artefacts to be considered in a development project, whereas the dependencies between the artefacts in an artefact model arise from the input/output-‐relations given in the methods used to create and modify the artefacts. An artefact model thus defines a description of the set of required artefacts, their structure, and the relations between the artefacts.
Artefacts and artefact models can be specified by different means; for example, via ontologies, meta models or concept models, or via modelling theories that define, mostly via mathematical models, a semantic foundation of given description techniques. Each of the description techniques has a different degree of formalisation and level of precision. For example, a concept model could define the content of an artefact by capturing the modelling concepts given in available description techniques. However, since concept models are often pragmatically defined as a specific-‐purpose solution and, thus, do potentially not capture all facets of a system, we could instead define the artefacts via a modelling theory that puts emphasis on the semantics of concepts that capture all facets of systems and development activities in a particular domain. (In fact, we can establish a concept model based on a theory, but not necessarily vice-‐versa.) The definition of an artefact model and the understanding of the term artefact always depend on the intended purpose of the model and the desired degree of precision. Also, the definition of the content of an artefact with a content model always implies a notion of structure. Still, different objectives justify the use of a self-‐contained representation of the structure and the content of an artefact model and also the combination of different representations.
Artefact Orientation and Fields of Application So far, we have introduced the notion of artefacts and artefact models. Artefacts and artefact models are used in different areas, for example, in the area of development process models or in the area of model-‐based design and development. In the model-‐based design philosophy, for example, an artefact abstracts from modelling elements used in one particular application domain; for instance, the elements and relations needed to define a use case model. Such artefact models can be found under the term “meta models” and, in specific cases, also under the term “concept model”. In the area of development process models, however, an artefact (also named “product”) is seen more generically as an intermediate result of a set of interconnected methods; for example, an abstraction of a specification document, the data representation of code or of the system under consideration. We now set the concept of artefacts into context of further development process models and explain the previously introduced terms and concepts in context of further elements as roles or activities. We already showed that an artefact is an intermediate result of a process serving a specific purpose. When applying artefacts as part of reference models in projects, an artefact is additionally subject to version control and configuration management as it underlies a certain (project) life cycle. During project planning, it is then defined (1) what the content of an artefact is (explicitly done via a content model), (2) what the structure of the artefact is (including the relations to other artefacts and their contents), and (3) with which languages and description techniques artefacts can be represented. The set of all artefacts to be considered in a development project, including the dependencies between the artefacts, is defined as part of an artefact model. To define an artefact model or an artefact-‐based approach, respectively, we have different concepts:
1. We use meta models as a language to describe a syntactic set of artefact models. 2. We then define a particular artefact model for a particular application domain via different means:
1. With content models, we define which contents we explicitly expect in the artefacts. 2. The expected contents in the artefacts are organised via structure models, e.g., via a table of contents. 3. Both models can be defined as data models for persisting the artefacts or for making the contents
available for computation in general.
Further Reading At the research group on Software and Systems Engineering, we have contributed foundational, conceptual, and empirical work in the area of artefact orientation of which some contributions are listed below. [1] D. Mendez Fernandez. Requirements Engineering: Artefact-‐based Customisation. PhD Thesis, TUM, 2011. [2] D. Mendez Fernandez, B. Penzenstadler, M. Kuhrmann, M. Broy. A Meta Model for Artefact-‐Orientation:
Fundamentals and Lessons Learned in Requirements Engineering. In Proceedings of the 13th International Conference on Model Driven Engineering Languages and Systems, pages 183-‐197, Springer, 2010.
[3] D. Mendez Fernandez, K. Lochmann, B. Penzenstadler, S. Wagner. A Case Study on the Application of an Artefact-‐Based Requirements Engineering Approach. In Proceedings of the 15th Annual Conference on Evaluation and Assessment in Software Engineering, pages 104-‐113, Institution of Engineering and Technology, 2011.