Metamodelling for Software Engineering - Hardcover

Cesar Gonzalez-Perez; Brian Henderson-Sellers

Hardcover

ISBN 10: 0470030364 ISBN 13: 9780470030363

Publisher: Wiley, 2008

Synopsis

This book focuses on metamodelling as a discipline, exploring its foundations, techniques and results. It presents a comprehensive metamodel that covers process, product and quality issues under a common framework.

Issues covered include:

• An explanation of what metamodelling is and why it is necessary in the context of software engineering.
• Basic concepts and principles of traditional metamodelling, and some existing results of this approach.
• Problems associated with traditional approaches to Metamodelling are discussed, alongside an exploration of possible solutions and alternative approaches.
• Advanced topics such as the extension of the object-oriented paradigm for metamodelling purposes or the foundations of powertype-based tool development will be studied.
• Finally, a comprehensive case study is introduced and developed, showing how to use many of the concepts explained in the previous chapters.

This book provides a comprehensive conceptual framework for metamodelling and includes case studies and exercises which will demonstrate practical uses of metamodelling. For lecturers and educators, the book provides a layered repository of contents, starting from the basics of metamodelling in the first chapters, through specific issues such as trans-layer control or non-strict approaches, up to advanced topics such as universal powertyping or extensions to the object-oriented paradigm. The book also serves as an in-depth reference guide to features and technologies to consider when developing in-house software development methods or customising and adopting off-the-shelf ones. Software tool developers and vendors can benefit from the book by finding in it a comprehensive guide to the implementation of frameworks and toolsets for computer-aided software modelling and development.

About this title

About the Author

Cesar Gonzalez-Perez is a senior researcher in the application of information technologies in the management of cultural heritage at the Spanish National Research Council and was previously a researcher in the Department of Software Engineering at the University of Technology, Sydney.

Brian Henderson-Sellers is Director of the Centre for Object Technology Applications and Research and a professor at the University of Technology, Sydney. He is the author of more than a dozen books on object and agent technologies.

From the Back Cover

Metamodelling for Software Engineering is a comprehensive and practical guide to a subject that is growing in interest and importance and is becoming the standard way of defining software development methodologies, including both processes and languages such as UML. The ISO/IEC 24744 standard metamodel is adopted throughout the book as a background reference.

Metamodelling is often regarded as a complex discipline, much removed from daily practice. This book seeks to demystify metamodelling and explains why it is necessary in the context of software engineering. It covers:

• Basic concepts and principles of metamodelling.
• Problems associated with traditional metamodelling, alongside an exploration of possible solutions and alternative approaches.
• Advanced topics such as the extension of the object-oriented paradigm for metamodelling purposes, or the foundations of powertype-based tool development.
• A comprehensive case study, which shows how to use the concepts explained in the previous chapters.

This thorough and practical guide bridges the gap between the academic realm, where most of the innovation happens, and industry, where the real needs exist. This book will show academics how to approach metamodelling in such a fashion that their research outcomes are useful to industry; lecturers and educators how to teach metamodelling to students so it is well understood and assimilated; industry methodologists how to utilize valuable metamodelling ideas in their daily work and software tool developers how to incorporate the most innovative research outcomes into their products.

Focusing on metamodelling as a discipline, exploring its foundations, techniques and results and covering process, product and quality issues under a common framework, this is a unique and timely publication for all software engineering practitioners, academics and students interested in metamodelling.

From the Inside Flap

Metamodelling for Software Engineering is a comprehensive and practical guide to a subject which is growing in interest and importance and is becoming the standard way of defining a language, such as UML. The process seeks to provide an explicit specification of the constructs and rules of how a domain-specific model (or language) is built.

Metamodelling is often regarded as a complex discipline, much removed from daily practice. This book seeks to demystify Metamodelling and explain why it is necessary in the context of software engineering. It covers:

• Basic concepts and principles of Metamodelling.
• Problems associated with traditional Metamodelling, alongside an exploration of possible solutions and alternative approaches.
• Advanced topics such as the extension of the object-oriented paradigm for Metamodelling purposes, or the foundations of powertype-based tool development.
• A comprehensive case study, which shows how to use the concepts explained in the previous chapters.

This thorough and practical guide bridges the gap between the academic realm, where most of the innovation happens, and industry, where the real needs exist. This book will show academics how to approach Metamodelling in such a fashion that their research outcomes are useful to industry; lecturers and educators how to teach Metamodelling to students so it is well understood and assimilated, industry methodologists how to utilize valuable Metamodelling ideas in their daily work and software tool developers how to incorporate the most innovative research outcomes into their products.

Focusing on Metamodelling as a discipline, exploring its foundations, techniques and results and covering process, product and quality issues under a common framework, this is a unique and timely publication for all software engineering practitioners, academics and students interested in Metamodelling.

Excerpt. © Reprinted by permission. All rights reserved.

Metamodelling for Software Engineering

By Cesar Gonzalez-Perez Brian Henderson-Sellers

John Wiley & Sons

Copyright © 2008 Cesar Gonzalez-Perez
All right reserved.
ISBN: 978-0-470-03036-3

Chapter One

Software Development Methodologies and Metamodelling

A major area of interest within the computing discipline of software engineering is that of software development methodologies. A methodology has several constituent parts including a full lifecycle process, a comprehensive set of concepts, a set of rules, heuristics and guidelines underpinning appropriate development techniques, a set of metrics, information on quality assurance, a set of coding and other organizational standards, and advice on reuse and project management. In order to describe all these parts in a consistent and useful manner, we need some kind of formalism. The formalism chosen here is that of metamodelling.

We begin this book with an examination of what is meant by a methodology and how metamodelling can be useful in creating robust and effective methodology models. Later we describe how the basic metamodelling ideas can be used in various domains, such as for modelling work products and processes. We evaluate the current state-of-the-art in these and other application areas before introducing some advanced ideas and how they have led to the creation of international standards that support the development of industry-strength methodologies for use in professional, commercial software development endeavours.

1.1 WHAT IS A METHODOLOGY?

Dictionaries often provide two basic meanings for the word "methodology". On the one hand, a methodology is an approach to doing something; on the other hand, methodology is the study of methods. According to WordNet, a methodology is "the system of methods followed in a particular discipline", a method being "a way of doing something, esp. a systematic one". Also according to WordNet, methodology means "the branch of philosophy that analyzes the principles and procedures of inquiry in a particular discipline". Therefore, the two possible meanings of "methodology" are:

The collection of methods followed in a particular discipline.

The study of methods followed in a particular discipline.

These two accepted meanings are closely related but are clearly different. The first one refers to a piece of information that describes how things are done within a given discipline. The second one refers to the activity of studying how things are done within a given discipline. The first usage is common and widely accepted, although the second one is closer to the etymological origin of the word "methodology" since the -ology suffix means "study of", in Greek.

It is also worth emphasizing that the first accepted meaning, denoting a thing (a piece of information), corresponds to a countable noun: it is possible to speak about one methodology or multiple methodologies, and the article is always used in the singular (e.g. "this methodology is flawed"). The second accepted meaning, in contrast, corresponds to an uncountable noun, very much like "biology" or "archaeology": we usually omit the definite article ("biology is exciting" rather than "the biology is exciting"). Most uses of the word "methodology" in the realm of engineering pertain to the first meaning; it is very common to hear people speaking about this or that methodology, but extremely uncommon to hear people saying things like "methodology is an exciting area to work in" (this would sound much better with any other "-ology" noun). This is a grammatical reason that supports the first meaning of "methodology" better than the second.

Also, the first meaning relates the terms "methodology" and "method" by a whole-part relationship (i.e. a methodology is a system or collection of methods), whereas the relationship implicit in the second meaning is much more complex (methods are studied by methodology). Interestingly, most uses of "method" and "methodology" in engineering tend to blur the semantic differences between them: a method is a systematic way of doing something and a methodology is a collection of methods, which, appealing to common sense, also defines a way of doing something. This fits well with the first meaning of "methodology" and is a semantic reason that supports the first meaning of "methodology" better than the second.

Finally, the second meaning of "methodology" pertains to philosophy and is rarely used without a connection to this field. Although modelling and metamodelling have strong connections to cognitive science and psychology, we believe that the three reasons here outlined are important enough as to encourage the adoption of the first meaning of "methodology" as far as engineering disciplines are concerned. Therefore, we can say that:

A methodology is a systematic way of doing things in a particular discipline.

This definition places the concept of "methodology" very close to that of "method"; as we said above, a collection of ways to do things ("methods", according to the dictionary) is also, using common sense, a way to do things. This means that, for practical purposes, and as far as this book is concerned:

A method is a methodology: the two terms are synonymous.

1.1.1 Further Characterization

Let us dig deeper into the definition of what a methodology is. We will do this by analyzing the phrase "a systematic way of doing things in a particular discipline".

To start with, and central to the definition, a methodology is a way. In other words, it is a manner, a means, a course of conduct. This means that no methodology is an end in itself but is a means to an end. It also means that, being a manner, it is arguable that other alternative manners also exist.

In addition, a methodology is systematic, i.e. orderly, planned and, at least to a certain extent, predictable. If we assume that methodologies are often shared by multiple individuals, this means that subjectivity must be reduced to a minimum in methodologies; otherwise, they wouldn't be systematic in an objective way.

Furthermore, a methodology is a way of doing things. This means that methodologies can be applied to change the state of the world that surrounds us (i.e. to do things), becoming the cause of effects that should be observable. If this were not so, the methodology wouldn't be doing things. Also, the things done by use of a methodology are the persistent outcomes of its application; the methodology is applied in order to obtain these outcomes. In other words, the things done by a methodology encompass the purpose of the methodology as a whole. The methodology is used because some community pursues that purpose.

Finally, any given methodology pertains to a particular discipline. In other words, it is focussed on a particular domain of knowledge and, consequently, works within a particular conceptual environment. In this book, our focus is the discipline of software engineering i.e. building a software application that meets the user's stated requirements.

As a summary, we can say that methodologies are used by communities that work in well-defined fields in order to produce persistent outcomes in their environment in an orderly and predictable fashion. For example, a team of software developers (the community) may use Extreme Programming (a methodology) in the field of information systems development in order to produce a working system (the persistent outcome) by following some techniques, such as "pair programming" and "test first", that are known to render good results (orderliness and predictability).

Since this book is about software development methodologies, we assume throughout that the well-defined field where methodologies will work is software engineering. It can be argued that most of the methodological knowledge in this area is also valid in related areas, such as systems engineering or even business-process engineering; we believe so but, in this book, we assume from now on that the methodologies we are discussing occur in the realm of software engineering. As a consequence, the community that uses a methodology is always assumed to be a team of software engineers or developers, and the persistent outcome that is pursued by the application of a methodology is assumed to be a software system, either a new one or a modification of a pre-existing one. Again, it can be argued that most of the knowledge related to the development of software systems can also be applied to the development and delivery of related services and even hardware.

There is one last issue to be considered before we can claim to have a complete characterization of software development methodologies. We have agreed that methodologies are used by software engineers in order to produce working systems; this means that methodologies must be usable by software engineers, with regard to both their content and form. This is the topic of the next section.

1.1.2 One Size Does Not Fit All

We believe that software development methodologies must be useful. If they are not, they will not be used and we will be wasting our time. Too often methodology books spend most of their life gathering dust on a shelf rather than being read, studied and annotated. For methodologies to be useful, we need to determine who their users are and focus on their needs. As we explained in the previous section, software engineers use methodologies in order to obtain software systems; these systems, however, can be of many kinds: embedded systems, database-oriented information systems, web applications, thick-client desktop applications, etc. Also, the teams and their context may be of very different sizes, hierarchical organizations, geographical distributions, skill sets and cultures. Other project parameters, such as calendar or budget latitude, requirements volatility and customer availability must also be considered. Given the large number of variables, it is clear that no well-defined set of needs can be clearly defined, at a useful level of detail, for the whole of the user community. The three major aspects (organization, project and product) can vary so much that the well-known adage "one size fits all" has often been reversed to convey that no single methodology can be devised so that it provides a useful systematic way of doing things in all software engineering endeavours.

Therefore, methodologies must be purpose-fit, i.e. adapted to the particular characteristics of the anticipated scenarios of usage. Of course, some compromises can be made; for example, it is easier to devise a methodology for the development of dynamic websites by co-located teams, regardless of the team size, than a methodology for the development of web sites, regardless of team distribution and size. As usual in engineering, the more specific the tool is, the more effective it can be - at the expense of constraining the range of its applicability.

There are two major ways of obtaining purpose-fit methodologies. The first is usually called tailoring, and is based on the adaptation of a pre-existing generic methodology to the particular needs of a user. "Tailoring" means adaptation or customization; this implies that some generic, template-like product must exist a priori, from which the final, purpose-fit product is obtained, e.g. Tailoring assumes that the fixed parts of a methodology can be clearly separated from the variable parts, because the template methodology that serves as input to the tailoring process must be defined without any specific knowledge of the properties of its future users. Often, this means abstracting out template elements and compromising on solutions that are either too abstract or, if concrete, out of scope. If a template element is very abstract, the tailoring process will have to make it more concrete by taking into account the needs of the user; if, on the contrary, a template element is not abstract but directly usable, it may well fall out of scope, since it will certainly respond to the needs of some users but not of others. As a result, the final methodology will, in both cases, be less than optimal. Also, there is a tension between the need to maximize tailorability, which pushes in the direction of abstracting out and making most aspects variable rather than fixed, and the need to provide a readily usable product, which pushes in the direction of making it concrete enough to be useful without modification and making most aspects fixed rather than variable. Tailoring is considered a viable approach to methodology development by many authors, being used by well-known approaches such as RUP. However, each approach that uses tailoring as a purpose-fit mechanism must commit to a fixed compromise between abstraction and utility, which, once again, defines a supposedly universally applicable solution that should fit all.

The second possible approach to obtaining a purpose-fit methodology is called method engineering and is based on the idea that methodologies can be dynamically assembled from pre-existing components according to the user's needs. With this approach, no templates exist; the only universals that are considered are fine-grained, self-contained method components that have been demonstrated to work well in different situations. A method component, therefore, is a small, reusable piece of information about a very specific aspect of a methodology (such as a particular task to be performed or a particular product to be used) that can be stored in a database to be selected and incorporated into a methodology as necessary. This approach benefits from a large degree of reuse, since method components are reused each time they are selected for a particular methodology and are evaluated when the methodology is used, thus establishing a feedback loop that can be used to alter the specification of a method component from the data obtained during its real-world usage (Figure 1.1). At the same time, this approach benefits from the fact that no pre-existing overall fixed parts exist, and therefore the assumptions that need to be made about the users of the methodologies are minimal.

An architectural simile is useful to understand the differences between these two approaches. The tailoring approach is akin to buying a house and refurbishing it by knocking down some walls and building a few extensions; the resulting house will be better suited to its owners than the original one but will always be constrained by the original assumptions and overall design. The method engineering approach, on the other hand, is analogous to defining what kind of house you would like to have, drafting some blueprints, obtaining the components (such as doors, windows, bricks and tiles) and building the house yourself. Although this is likely to be a more time-consuming task, the outcome will be optimally adjusted to your needs.

In this book, we adopt a method engineering approach because of its evident advantages. This approach, however, emphasizes an additional aspect of methodologies that must be considered carefully: if methodologies are to be created as complex assemblies of components, how is this done? Who should do it? What tools and techniques are available to do it? Following our previous example, an average citizen would not build a house herself, but would hire an architect; similarly, the role of method engineers, as the community that creates and maintain methodologies as first-order artefacts, must be introduced and its relation with the community of methodology users must be described.

1.1.3 Communities and Uses

There are two contrasting communities of people that interact with and utilize software development methodologies. Firstly, and most obviously, software engineers use methodologies in order to create software systems. Secondly, method engineers create and maintain methodologies according to the needs of software engineers. Notice that the concept of a method engineer, i.e. a person who designs and build methodologies according to some well-known needs, is not peculiar to the software engineering discipline; any other discipline that uses methodologies may utilize this concept as well.

Some vocabulary must be introduced. Method engineers are said to construct methodologies from method components. Software engineers are said to enact methodologies on endeavours. Enacting a methodology means, basically, applying it to solve a problem of the kind that it has been designed to solve. An endeavour is the organizational and psychological scenario where the methodology is applied. Typically, endeavours are visible as projects, where a project has as its purpose the development of a software system. However, non-project endeavours, such as infrastructure management or organizational support activities, are also common. These are endeavours but not, strictly speaking, projects, so we will use the broader term "endeavour" rather than "project".

(Continues...)

Excerpted from Metamodelling for Software Engineeringby Cesar Gonzalez-Perez Brian Henderson-Sellers Copyright © 2008 by Cesar Gonzalez-Perez. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Edition details

• Publisher: Wiley
• Publication date: 2008
• Language: English
• ISBN 10: 0470030364
• ISBN 13: 9780470030363
• Binding: Hardcover
• Edition number: 1
• Number of pages: 240