Download the full version of the ebook at

https://ebookultra.com

Object oriented design knowledge principles

heuristics and best practices Javier Garzã¡S

https://ebookultra.com/download/object-oriented-
design-knowledge-principles-heuristics-and-best-
practices-javier-garzas/

Explore and download more ebook at https://ebookultra.com

 Recommended digital products (PDF, EPUB, MOBI) that
you can download immediately if you are interested.

Starting Out The c3 Sicilian 1st Edition John Emms

https://ebookultra.com/download/starting-out-the-c3-sicilian-1st-
edition-john-emms/

ebookultra.com

Object Oriented Design with UML and Java 1st Edition

Kenneth Barclay

https://ebookultra.com/download/object-oriented-design-with-uml-and-
java-1st-edition-kenneth-barclay/

ebookultra.com

Java the UML way integrating object oriented design and

programming Else Lervik

https://ebookultra.com/download/java-the-uml-way-integrating-object-
oriented-design-and-programming-else-lervik/

ebookultra.com

Scientific Software Design The Object Oriented Way 1st

Edition Damian Rouson

https://ebookultra.com/download/scientific-software-design-the-object-
oriented-way-1st-edition-damian-rouson/

ebookultra.com
Design patterns explained a new perspective on object
oriented design 2. ed Edition Shalloway

https://ebookultra.com/download/design-patterns-explained-a-new-
perspective-on-object-oriented-design-2-ed-edition-shalloway/

ebookultra.com

The Anti Alapin Gambit Death to the 2 c3 Sicilian 1st

Edition Cyrus Lakdawala

https://ebookultra.com/download/the-anti-alapin-gambit-death-to-
the-2-c3-sicilian-1st-edition-cyrus-lakdawala/

ebookultra.com

Enterprise SOA Service Oriented Architecture Best

Practices 9th Edition Dirk Krafzig

https://ebookultra.com/download/enterprise-soa-service-oriented-
architecture-best-practices-9th-edition-dirk-krafzig/

ebookultra.com

Object oriented software development using Java principles

patterns and frameworks 2nd Edition Xiaoping Jia.

https://ebookultra.com/download/object-oriented-software-development-
using-java-principles-patterns-and-frameworks-2nd-edition-xiaoping-
jia/
ebookultra.com

Principles of Object Oriented Modeling and Simulation with

Modelica 2 1 1st Edition Peter Fritzson

https://ebookultra.com/download/principles-of-object-oriented-
modeling-and-simulation-with-modelica-2-1-1st-edition-peter-fritzson/

ebookultra.com
Object oriented design knowledge principles heuristics
and best practices Javier Garzã¡S Digital Instant
Download
Author(s): Javier Garzás, Javier Garzás and Mario Piattini
ISBN(s): 9781591408987, 1591408989
Edition: illustrated edition
File Details: PDF, 5.29 MB
Year: 2007
Language: english
 i

Object-Oriented
Design Knowledge:
Principles, Heuristics and
Best Practices

Javier Garzás
Oficina de Cooperación Universitaria (OCU) S.A., Spain

Mario Piattini
University of Castilla - La Mancha, Spain

IDEA GROUP PUBLISHING

Hershey • London • Melbourne • Singapore
ii

Acquisitions Editor: Michelle Potter

Development Editor: Kristin Roth
Senior Managing Editor: Jennifer Neidig
Managing Editor: Sara Reed
Copy Editor: April Schmidt
Typesetter: Marko Primorac
Cover Design: Lisa Tosheff
Printed at: Yurchak Printing Inc.

Published in the United States of America by

Idea Group Publishing (an imprint of Idea Group Inc.)
701 E. Chocolate Avenue
Hershey PA 17033
Tel: 717-533-8845
Fax: 717-533-8661
E-mail: cust@idea-group.com
Web site: http://www.idea-group.com

and in the United Kingdom by

Idea Group Publishing (an imprint of Idea Group Inc.)
3 Henrietta Street
Covent Garden
London WC2E 8LU
Tel: 44 20 7240 0856
Fax: 44 20 7379 0609
Web site: http://www.eurospanonline.com

Copyright © 2007 by Idea Group Inc. All rights reserved. No part of this book may be reproduced, stored or
distributed in any form or by any means, electronic or mechanical, including photocopying, without written
permission from the publisher.

Product or company names used in this book are for identification purposes only. Inclusion of the names of the
products or companies does not indicate a claim of ownership by IGI of the trademark or registered trademark.

Library of Congress Cataloging-in-Publication Data

Library of Congress Cataloging-in-Publication Data

Object-oriented design knowledge : principles, heuristics, and best practices / Javier Garzas and Mario Piattini,
editors.
p. cm.
Summary: "The software engineering community has advanced greatly in recent years and we currently have
numerous defined items of knowledge, such as standards, methodologies, methods, metrics, techniques, languages,
patterns, knowledge related to processes, concepts, etc.The main objective of this book is to give a unified and
global vision about Micro-Architectural Design Knowledge, analyzing the main techniques, experiences and
methods"--Provided by publisher.
ISBN 1-59140-896-2 (hardcover) -- ISBN 1-59140-897-0 (softcover) -- ISBN 1-59140-898-9 (ebook)
1. Object-oriented methods (Computer science) 2. Object-oriented programming (Computer science) I. Garzas,
Javier, 1975- II. Piattini, Mario, 1966-
QA76.9.O35.O244 2006
005.1'17--dc22
2006010089

British Cataloguing in Publication Data

A Cataloguing in Publication record for this book is available from the British Library.

All work contributed to this book is new, previously-unpublished material. The views expressed in this book are
those of the authors, but not necessarily of the publisher.
 iii

Object-Oriented
Design Knowledge:
Principles, Heuristics
and Best Practices

Table of Contents

Preface ............................................................................................................. vi

Chapter I
The Object-Oriented Design Knowledge ................................................... 1
Javier Garzás, Oficina de Cooperación Universitaria (OCU) S.A.,
Spain
Mario Piattini, University of Castilla - La Mancha, Spain

Chapter II
The Object-Oriented Design Knowledge Ontology ................................. 8
Javier Garzás, Oficina de Cooperación Universitaria (OCU) S.A.,
Spain
Mario Piattini, University of Castilla - La Mancha, Spain

Chapter III
Using Linguistic Patterns to Model Interactions .................................... 23
Isabel Díaz, Central University of Venezuela, Venezuela
Oscar Pastor, Technical University of Valencia, Spain
Lidia Moreno, Technical University of Valencia, Spain
Alfredo Matteo, Central University of Venezuela, Venezuela
iv

Chapter IV
A Framework Based on Design Patterns: Implementing UML
Association, Aggregation and Composition Relationships in
the Context of Model-Driven Code Generation ..................................... 56
Manoli Albert, Universidad Politécnica de Valencia, Spain
Marta Ruiz, Universidad Politécnica de Valencia, Spain
Javier Muñoz, Universidad Politécnica de Valencia, Spain
Vincente Pelechano, Universidad Politécnica de Valencia,
Spain

Chapter V
Design Patterns as Laws of Quality ........................................................ 105
Yann-Gaël Guéhéneuc, University of Montreal, Canada
Jean-Yves Guyomarc’h, University of Montreal, Canada
Khashayar Khosravi, University of Montreal, Canada
Houari Sahraoui, University of Montreal, Canada

Chapter VI
Automatic Verification of OOD Pattern Applications .......................... 143
Andrés Flores, University of Comahue, Argentina
Alejandra Cechich, University of Comahue, Argentina
Rodrigo Ruiz, University of Comahue, Argentina

Chapter VII
From Bad Smells to Refactoring: Metrics Smoothing the Way ......... 193
Yania Crespo, Universidad de Valladolid, Spain
Carlos López, Universidad de Burgos, Spain
María Esperanza Manso Martínez, Universidad de Valladolid,
Spain
Raúl Marticorena, Universidad de Burgos, Spain

Chapter VIII
Heuristics and Metrics for OO Refactoring: A Consolidation and
Appraisal of Current Issues ..................................................................... 250
Steve Counsell, Brunel University, UK
Youssef Hassoun, University of London, UK
Deepak Advani, University of London, UK

Chapter IX
A Survey of Object-Oriented Design Quality Improvement .............. 282
Juan José Olmedilla, Almira Lab, Spain
 v

Chapter X
A Catalog of Design Rules for OO Micro-Architecture ..................... 307
Javier Garzás, Oficina de Cooperación Universitaria (OCU) S.A.,
Spain
Mario Piattini, University of Castilla - La Mancha, Spain

About the Authors ..................................................................................... 349

Index ............................................................................................................ 356

vi

Preface

In order to establish itself as a branch of engineering, a profession must under-

stand its accumulated knowledge. In addition, software engineering as a branch
of engineering must take several basic steps in order to become an established
profession, highlighting understanding of the nature of its knowledge.
Software engineering experts always have used proven ideas. Concretely, in
the object-oriented (OO) design knowledge field, the practical experience of it
has been crucial to software engineers, and it is in the last years when these
ideas, materialized in items such as patterns or refactorings have reached their
biggest popularity and diffusion. And in this regard, the software engineering
community has advanced greatly and we currently have numerous and defined
chunks of knowledge, including standards, methodologies, methods, metrics,
techniques, languages, patterns, knowledge related to processes, concepts, and
so forth. Although these different areas of knowledge relate to the construction
of an OO system, there is a lot of work still to be done in order to systematize
and offer this knowledge to designers in such a way that it can be easily used in
practical cases.
A software architecture is a description of the subsystems and components of
a software system and relationships between then.1 Usually, the software ar-
chitecture is subdivided into macro and micro architecture. Whereas macro
architecture describes the metamodel of design, this that provides the high-
level organization, the micro architecture describes details of a design at a lower
level.
 vii

OO design is a software design technique, which is expressed in terms of ob-

jects and relationships between those; at the level of micro architecture it in-
cludes elements such as classes, its relationships, responsibilities, refactorings,
and so on.
OO micro architectural knowledge is built upon design experiences, such as
problem solving, or lessons learned. Therefore, the OO micro architectural de-
sign knowledge has grown with time and the increasing complexity of soft-
ware. This knowledge expands and accumulates when it is stored in books and
other media for the use of designers.
In addition, the major part of OO design knowledge is difficult to identify and
use. The experience has demonstrated that design often omits common prin-
ciples, heuristics, and so on, with a consequent major loss of experience. Con-
sequently, actually, serious difficulties are still encountered when we tackle the
construction of OO systems. Although designers have accumulated a body of
knowledge that they apply during these processes, this is very implicit. Fortu-
nately, it is now being specified and popularized in different forms: principles,
heuristics, patterns, and more recently, refactoring techniques. However, today,
the difference between these concepts is generally unclear and not all of them
have received the same amount of attention or have reached the same degree
of maturity. In addition, a strong knowledge does not exist on items such as
design principles, best practices, or heuristics. The problem confronting the
designer is how to articulate all this explicit knowledge and to apply it in an
orderly and efficient way in the OODA, in such a way that it is really of use to
him or her. In fact, in practice, even such advanced subjects like OO patterns
have this problem
Design knowledge and best practices are stored in individual expert minds, or
implicitly encoded and documented in local organisational processes. It has
always been true that a significant part of design knowledge resides in the
minds of the experts that make it up. However, communities and companies are
beginning to find that it is easy to lose a vital element of their intellectual prop-
erty: corporate design knowledge. Therefore, we can say that the major part of
the design knowledge today is tacit knowledge: it in the form of project experi-
ences, heuristics, or human competencies that are difficult to be captured and
externalised.
The effective management of this knowledge is today a significant challenge.
For knowledge management to be effective, this knowledge should be orga-
nized and classified. In addition, with this purpose, developing unified cata-
logues of knowledge, ontologies, empirical studies, and so on, books and studies
such as those we present here, are very important issues to improve the use of
OO design knowledge.
Therefore, in this context, we present this book whose main objective is to give
a global vision of micro-architectural design knowledge, exposing the main tech-
niques and methods, and analyzing several aspects related to it.
viii

The subject matter in this book is divided into ten chapters. The chapters seek
to provide a critical survey of the fundamental themes, problems, arguments,
theories, and methodologies in the field of OO micro architectural design knowl-
edge. Each chapter has been planned as a self-standing introduction to its sub-
ject.
Therefore, in Chapter I Javier Garzás and Mario Piattini present an introduc-
tion to “The Object-Oriented Design Knowledge,” where they show the main
issues and problems of the field. In OO micro-architectural design knowledge,
design patterns are the most popular example of accumulated knowledge, but
other elements of knowledge exist such as principles, heuristics, best practices,
bad smells, refactorings, and so forth, which are not clearly differentiated; in-
deed, many are synonymous and others are just vague concepts.
An essential issue to building an OO design knowledge discipline is organizing
this knowledge. In Chapter II, titled “The Object-Oriented Design Knowledge
Ontology,” Javier Garzás and Mario Piattini show an ontology that organize and
relation the OO knowledge. The authors propose an ontology in order to struc-
ture and unify such knowledge. The ontology includes rules (principles, heuris-
tic, bad smells, etc.), patterns, and refactorings. They divide the knowledge on
rules, patterns, and refactorings and they show the implications among these.
Moreover, they show an empirical validation of the proposed conclusions.
Chapter III, “Using Linguistic Patterns to Model Interactions,” by Isabel Díaz,
Oscar Pastor Lidia Moreno, and Alfredo Matteo, is a pivotal chapter that changes
the focus of the book to more technical information systems issues. This chap-
ter shows an elegant example of how highly relevant clinical questions can be
addressed in a scientific manner. In this chapter, heuristic-oriented techniques
and linguistics-oriented techniques proposed by several authors to model inter-
actions are analyzed. In addition, a framework to facilitate and to improve the
interaction modeling is described. This framework was conceived to be inte-
grated into automatic software production environments. It uses linguistic pat-
terns to recognize interactions from use case models. The validation process
used and the main results are also presented.
In Chapter IV, Manoli Albert, Marta Ruiz, Javier Muñoz and Vicente Pelechano
show “A Framework Based on Design Patterns: Implementing UML Associa-
tion, Aggregation and Composition Relationships in the Context of Model-Driven
Code Generation.” The chapter proposes a framework based on design pat-
terns to implement UML (Unified Modeling Language) association, aggrega-
tion, and composition relationships, and for it they propose a semantic interpre-
tation of these concepts that avoids the ambiguities introduced by UML.
Therefore, in “Design Patterns as Laws of Quality” Yann-Gaël Guéhéneuc,
Jean-Yves Guyomarc’h, Khashayar Khosravi, and Houari Sahraoui, Chapter
V, show how design patterns can be used as facts to devise a quality model and
they describe the processes of building and of applying such a quality model.
 ix

The chapter highlights the need for principles in software engineering, where
these can be laws or theories formalizing and explaining observations realized
on software.
For the sake of completeness in this book, automatic verification of design
knowledge is addressed in Chapter VI. Andres Flores, Alejandra Cechich, and
Rodrigo Ruiz present “Automatic Verification of OOD Pattern Applications.”
Chapter VII, “From Bad Smells to Refactoring: Metrics Smoothing the Way”,
is authored by Yania Crespo, Carlos López, María Esperanza Manso Martínez,
and Raúl Marticorena. This chapter discusses one of the current trends in
refactorings: when and where we must refactor. From the bad smell concept, it
is possible to discover their existence from an objective viewpoint, using metrics.
The chapter presents a study on the relation of refactorings, bad smells and
metrics, including a case study on the use of metrics in bad smells detection.
The chapter leads to the determination where refactoring is the basis of heuris-
tics and metrics, which is likely to be the single most important factor at the
moment of use refactorings in the maintenance phase.
Therefore, in Chapter VIII, “Heuristics and Metrics for OO Refactoring: A
Consolidation and Appraisal of Current Issues,” Steve Counsell, Youssef
Hassoun, and Deepak Advani cover this topic in great depth. They look at
some of the issues which determine when to refactor (i.e., the heuristics of
refactoring) and, from a metrics perspective, open issues with measuring the
refactoring process. They thus point to emerging trends in the refactoring arena,
some of the problems, controversies, and future challenges the refactoring com-
munity faces.
A key point to building a OO design knowledge field is to understand the sev-
eral contributions to it. Since several OO metrics suites have been proposed to
measure OO properties, such as encapsulation, cohesion, coupling, and abstrac-
tion, both in designs and in code, in Chapter IX, titled “A Survey of Object-
Oriented Design Quality Improvement,” Juan José Olmedilla reviews the lit-
erature to find out to which high level quality properties are mapped and if an
OO design evaluation model has been formally proposed or even is possible.
The chapter is an excellent example of how performing a systematic review of
the estate of art.
At last, in Chapter X, “A Catalog of OOD Knowledge Rules for OO Micro-
Architecture,” by Javier Garzás and Mario Piattini, several types of knowledge
such as principles, heuristics, bad smells, and so on, are unified in a rules cata-
log.
In summary, these chapters constitute an evidence of the importance of micro-
architectural design knowledge, representing important ideas in different soft-
ware design areas. These are intended to be useful to a wide audience, includ-
ing software engineers, designers, project managers, software architects, IS/IT
managers, CIOs, CTOs, consultants, and software students.
x

We hope that the practical vision, scientific evidence and experience presented
in this book will enable the reader to use the design knowledge within the field
of software engineering and to help the field of software engineering answer
how software engineers might acquire its rich and essential accumulated knowl-
edge.

Javier Garzás and Mario Piattini, Editors

Ciudad Real, Spain
January 2006

Endnote
1
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., & Stal, M. (1996).
A system of patterns: Pattern-oriented software architecture. Addison-
Wesley.
 xi

Acknowledgments

We would like to thank all the authors, because without their

contribution this book would not have been possible. We would
also like to thank Kristin Roth, our development editor, for her
help and encouragement.
 The Object-Oriented Design Knowledge 1

Chapter I

The Object-Oriented
Design Knowledge
Javier Garzás, Oficina de Cooperación Universitaria (OCU) S.A., Spain

Mario Piattini, University of Castilla - La Mancha, Spain

Abstract
In order to establish itself as a branch of engineering, a profession must understand
its accumulated knowledge. In this regard, software engineering has advanced
greatly in recent years, but it still suffers from the lack of a structured classification
of its knowledge. In this sense, in the field of object-oriented micro-architectural
design designers have accumulated a large body of knowledge and it is still have
not organized or unified. Therefore, items such as design patterns are the most
popular example of accumulated knowledge, but other elements of knowledge exist
such as principles, heuristics, best practices, bad smells, refactorings, and so on,
which are not clearly differentiated; indeed, many are synonymous and others are
just vague concepts.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
2 Garzás & Piattini

Introduction
“Chaos is order waiting to be deciphered”
~ José Saramago

Twenty years ago, Redwine (1984) commented that “an expert in a field must
know about 50,000 chunks of information, where a chunk is any cluster of
knowledge sufficiently familiar that it can be remembered rather than derived,”
adding that in mature areas it usually takes about 10 years to acquire this
knowledge. Since then, many authors (Shaw, 1990) have commented on the need
for defined chunks of knowledge in the software engineering field. In this regard,
the software engineering community has advanced greatly in recent years, and
we currently have numerous and defined chunks of knowledge, including
standards, methodologies, methods, metrics, techniques, languages, patterns,
knowledge related to processes, concepts, and so on.
Nevertheless, the field of software engineering is still beset by a lack of
structured and classified chunks of knowledge (McConnell, 2003) and not all
knowledge is transmitted, accessible or studied in the same way. For example,
what and where is the enormous amount of practical knowledge regarding
object-oriented micro-architectural design? We mean knowledge that has been
accumulated from the experience of working with the inherent properties of
software, knowledge which normally comes under what is generally accepted or
“practices which are applicable to most projects, about which there is a
widespread consensus regarding value and usefulness” (Bourque & Dupuis,
2004, p. A-10). Such knowledge may take the form of a source code, compo-
nents, frameworks, and so on, but these are no mechanisms for obtaining designs
throughout the software life cycle.
At this point, many will have already identified one of the essential items of
knowledge based on experience with object-oriented micro-architectural design:
design patterns. These are just the tip of the iceberg. Let us simplify matters and
suppose that we want to specialize as software engineers in object-oriented
design. By means of projects like SWEBOK, we can now ascertain what
“design” is, how it is subdivided, find the main bibliographical references, and so
on, and quite easily acquire a sound theoretical knowledge. If indeed we
concentrate part of our professional activity on design, we find that we need to
study the practical experience of other experts in the area, and at that moment,
the concept of pattern occurs to us. Yet, after examining the main pattern
references in object-oriented design, we still feel that something is missing.
Missing elements for the formulation of a good micro-architectural design
include principles, heuristics, best practices, bad smells, refactorings, and so on.
Table 1 gives an example of each of these.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 The Object-Oriented Design Knowledge 3

Table 1. Examples of OO design knowledge

PRINCIPLES
The Dependency Inversion Principle (DIP)
“Depend upon Abstractions. Do not depend upon concretions” (Martin, 1996).

HEURISTICS
“If two or more classes only share common interface (i.e., messages, not methods), then they
should inherit from a common base class only if they will be used polymorphically” (Riel, 1996).

BEST PRACTICES
“See objects as bundles of behavior, not bundles of data” (Venners, 2004).

BAD SMELLS
Refused bequest
Subclasses that do not use what they inherit (Fowler, Beck, Brant, Opdyke, & Roberts, 2000).

REFACTORINGS
Extract Interface
“Several clients use the same subset of a class's interface, or two classes have part of their
interfaces in common. Extract the subset into an interface. [ ]” (Fowler et al., 2000).

PATTERNS
Observer
“Intent: Define a one-to-many dependency between objects so that when one object changes
state, all its dependents are notified and updated automatically” (Gamma, Helm, Johnson, &
Vlissides, 1995).

Considerable progress has been made in the accumulation of experience-based

knowledge of OO micro-architectural design, but we have advanced consider-
ably less in its exploitation and classification. This could be seen as a case of the
“Feigenbaum Bottleneck”: “as domain complexity grows, it becomes very
difficult for human experts to formulate their knowledge as practical strategies”
(Pescio, 1997).
First, in the following section, we will analyze the maintenance and design
patterns and relationship with analyzability and changeability in more detail.
Later, we will show a measurement of the impact of the patterns used. In the last
sections, we present acknowledgments, our conclusions and future projects, and
references.

The Object-Oriented Design Knowledge

Serious difficulties are still encountered when we tackle the construction of OO

systems, especially in the transition between the analysis processes and the OO
design, an aspect which is very vague in this type of paradigm (Henderson, Seller
& Eduards, 1990). In practice, designers have accumulated a body of knowledge

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
4 Garzás & Piattini

that they apply during these processes. Up until a few years ago, this knowledge
was very implicit but fortunately, it is now being specified and popularized in
different forms: principles, heuristics, patterns and more recently, refactoring,
and so on. The difference between these concepts is generally unclear and not
all of them have received the same amount of attention or have reached the same
degree of maturity.
In fact, OO design principles are often confused and few formalized. In this
regard, there are few works about it, with the exception of the contributions of
a few (Gamma et al., 1995; Liskov & Zilles, 1974; Martin, 1995, 1996; Meyer,
1997).
Regarding OO design heuristics the main works to which we can refer are those
of Riel (1996) and Booch (1996).
Patterns, however, are without doubt one of the elements that have undergone
the greatest evolution and proof of this is the existence of numerous publications
on the theme. The application of patterns in OO began at the beginning of this
decade (Coad, 1992) and was consolidated by the work of Gamma et al. (1995),
Buschmann, Meunier, Rohnert, Sommerlad, and Stal (1996), Fowler (1996), and
Rising (1998). Amongst the different types of patterns, we can distinguish,
mainly, although other categories exist (antipatterns, specific domains, etc.):

• Architectural: These focus on the structure of the system, the definition

of subsystems, their responsibilities and rules.
• Object-oriented analysis/design (OOAD): To support the refining of
the subsystems and components as well as the relationships between them.
• Idioms: They help us to implement particular aspects of the design in a
specific programming language.

As we already know, the use of patterns means that we can avoid constant
reinvention, thus reducing costs and saving time. Gamma et al., 1995 point out
that one thing that expert designers do not do is resolve each problem from the
beginning. When they find a good solution, they use it repeatedly. This experi-
ence is what makes them experts. However, at the present time, when patterns
are used, several types of problems can occur (Schmidt, 1995; Wendorff, 2001):
difficult application, difficult learning, temptation to recast everything as a
pattern, pattern overload, ignorance, deficiencies in catalogs, and so forth.
Refactoring techniques are characterized by their immaturity, although it is true
to say that this topic is rapidly gaining acceptance, the main works in this area
are Kent Beck and Fowler’s (2000), Tokuda and Batory (2001), and Opdyke
(1992).

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 The Object-Oriented Design Knowledge 5

The problem confronting the designer is how to articulate all this explicit
knowledge and to apply it in an orderly and efficient fashion in the OODA, in such
a way that it is really of use to him or her. In fact, in practice, even such advanced
subjects like patterns have this problem. Ralph Johnson comments in this sense
that “for one thing, the large number of patterns that have been discovered so far
need to be organized. Many of them are competitors; we need to experiment and
find which are best to use. …Analyzing existing patterns, or making tools that use
patterns, or determining the effectiveness of patterns, could all be good topics”
(Johnson, 2000, personal communication). These problems could give rise to
incorrect applications of the patterns (Wendorff, 2001).
The differences between these elements are not clear. Many concern a single
concept with different names, while others on occasions do not contain knowl-
edge gained from experience, and still others are simply vague concepts. This
confusion leads to a less efficient use of knowledge, so concepts such as
principles or heuristics are still unknown to some software engineers, few of
whom understand completely their goals or relationships. This problem has been
brought up at several major congresses, for example the OOPSLA 2001
Workshop: “Beyond Design: Patterns (mis)used,” where such authors as
Schwanninger (2001) say “We got more and more aware that a good description
of the proposed solution is necessary, but useless for the reader if the problem
and the forces that drive the relationship between problem and solution are not
covered properly.”

Conclusion
Expert designers have always used proven ideas. It is in recent years when these
ideas, materialized mainly into the pattern concept, have reached their greatest
popularity and diffusion. However, more knowledge exists apart from that
related to patterns, although it would be true to say that this other knowledge is
frequently “hidden.” We should consider that OO micro architectural design
knowledge is associated with the pattern concept, but other elements exist, such
as principles, heuristics, best practices, bad smells, and so forth. These other
elements show a confused description, unification, definition, and so on.
Therefore, few studies systematize and offer the OO design knowledge to
designers in such a way that it can be easily used in practical cases. In addition,
the different studies published show the elements related to design knowledge in
a disconnected way. There has not been much effort made on empirical studies
about OO design knowledge, and the few works we have found are mainly
focused on design patterns.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
6 Garzás & Piattini

As Shaw (1990) states, a branch of engineering must take several basic steps in
order to become an established profession, highlighting understanding of the
nature of knowledge. We as a discipline must ask how software engineers might
acquire this knowledge.

References
Abran, A., Moore, J. W., Bourque, P., & Dupuis, R. (Eds.). (2004). Guide to the
software engineering body of knowledge: SWEBOK. Los Alamos, CA: IEEE
CS Press.
Booch, G. (1996). Object solutions. Managing the object-oriented project. Red-
wood City, CA: Addison-Wesley.
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., & Stal, M. (1996). A
system of patterns: Pattern-oriented software architecture. New York: John
Wiley & Sons.
Coad, P. (1992). Object-oriented patterns. Communications of the ACM, 35(9),
152-159.
Fowler, M. (1996). Analysis patterns: Reusable object models. Boston, MA:
Addison-Wesley.
Fowler, M., Beck, K., Brant, J., Opdyke, W., & Roberts, D. (2000). Refactoring:
Improving the design of existing code (1st ed.). Boston: Addison-Wesley
Professional.
Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design patterns.
Reading, MA: Addison-Wesley Professional.
Henderson Seller, B., & Eduards, J. M. (1990). The object-oriented system life
cycle. Communications of the ACM, 33(9), 142-159.
Liskov, B. H., & Zilles, S. N. (1974). Programming with abstract data types.
SIGPLAN Notices, 9(4), 50-59.
Martin, R. C. (1995). Object-oriented design quality metrics: An analysis of
dependencies. ROAD, 2(3).
Martin, R. C. (1996). The dependency inversion principle. C++ Report, 8(6), 61-66.
McConnell, S. (2003). Professional software development. Boston: Addison-
Wesley.
Meyer, B. (1997). Object-oriented software construction (2nd ed.). Upper Saddle
River, NJ: Prentice Hall.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 The Object-Oriented Design Knowledge 7

Opdyke, W. (1992). Refactoring Object Oriented Frameworks. Illinois, Urbana-

Champain.
Pescio, C. (1997). Principles versus patterns. Computer, 30(9), 130-131.
Redwine, S. T. (1984). DOD-related software technology requirements, practices,
and prospects for the future (Tech. Rep. No. P-1788). Alexandria, VA:
Institute of Defense Analyses.
Riel, A. J. (1996). Object-oriented design heuristics. Boston: Addison-
Wesley Professional.
Rising, L. (1998). The patterns handbook: Techniques, strategies, and
applications. Cambridge: Cambridge University Press.
Schmidt, D. C. (1995). Experience using design patterns to develop reusable
object-oriented communication software. Communications of the ACM,
38(10), 65-74.
Schwanninger, C. (2001). Patterns as problem indicators. Paper presented at
the Workshop on Beyond Design Patterns (mis)Used. OOPSLA, Tampa
Bay, FL.
Shaw, M. (1990). Prospects for an engineering discipline of software. IEEE
Software, 7(6), 15-24.
Tokuda, L., & Batory, D. (2001). Evolving object-oriented designs with
refactoring. Automated Software Engineering, 8(1), 89-120.
Venners, B. (2004). Interface design best practices in object-oriented API
design in Java. Retrieved March 25, 2006, from http://www.artima.com/
interfacedesign/contents.html
Wendorff, P. (2001). Assessment of design patterns during software
reengineering: Lessons learned from a large commercial project.
Paper presented at the Proceedings of the 5th European Conference on
Software Maintenance and Reeingineering (CSMR).

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
8 Garzás & Piattini

Chapter II

The Object-Oriented
Design Knowledge
Ontology
Javier Garzás, Oficina de Cooperación Universitaria (OCU) S.A., Spain

Mario Piattini, University of Castilla - La Mancha, Spain

Abstract

It has been a long time since the object-oriented (OO) paradigm appeared.
From that moment, designers have accumulated much knowledge in design
and construction of OO systems. Patterns are the most refined OO design
knowledge. However, there are many others kinds of knowledge than are
not yet classified and formalized. Therefore, we feel it necessary to define
ontology in order to structure and unify such knowledge; a good
understanding of practical experience is crucial to software engineers.
Therefore, this chapter proposes an ontology for object-oriented design
knowledge.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 The Object-Oriented Design Knowledge Ontology 9

Introduction
Since Simula 67 up until the present day, knowledge related to the construction
of object-oriented (OO) systems has evolved significantly. Nowadays, due to
experience acquired during years of investigation and development of OO
systems, numerous techniques and methods that facilitate their design are
available to us.
By the middle of the 1990s the first catalogue of patterns was published by
Gamma, Helm, Johnson, and Vlissides (1995). The application of patterns in OO
design was consolidated, among others, by the work of Coad (1992), Gamma et
al. (1995), Buschmann, Meunier, Rohnert, Sommerlad, and Stal (1996), Fowler
(1996), and Rising (1998).
However, more knowledge exists apart from that related to patterns, and this
other knowledge is frequently “hidden.” Moreover, now the exclusive use of
patterns is not sufficient to guide a design, and the designer’s experience is
necessary to avoid overload, non-application or the wrong use of patterns due to
unawareness, or any other problems that may give rise to faulty and counterac-
tive use of the patterns. In summary, when patterns are used, several types of
problems may occur (Wendorff, 2001): difficult application, difficult learning,
temptation to recast everything as a pattern, pattern overload, deficiencies in
catalogues (search and complex application, high dependence of the program-
ming language, and comparatives), and so on.
In this sense, we need others’ chunks of knowledge such as principles, heuristic,
patterns, best practices, bad smells, refactorings, and so on. Nevertheless, there
is much uncertainty with the previous elements, and these elements have never
been studied as a whole. Its compatibility has been studied nor does a method
based in this knowledge exist.
In order to improve OO designs, using all OO design knowledge in a more
systematic and effective way, we have defined an ontology, which unifies
principles, heuristics, best practices, and so on, under the term of “rule”; the
ontology show the relationship among these “rules” and patterns and refactorings.
We have also defined an improved OOD process, which takes into account this
ontology and the OOD knowledge.
Moreover, we present in this chapter an empirical evaluation of this approach.
The empirical validation is based on Prechelt, Unger, Philippsen, and Tichy
(1997); Prechelt, Unger, Tichy, Bössler, and Votta (2001); and Wohlin, Runeson,
Höst, Ohlson, Regnell, and Wesslen (2000). This controlled experiment is
ascertain if the usage of the ontology for OOD knowledge really improves the
OOD process, helping in the detection of defects (rules violated) and solutions
(patterns).

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
10 Garzás & Piattini

Ontology
An ontology describes knowledge of a domain in a generic way and provides an
agreed understanding of it.
Ontologies have a number of advantages: structuring and unifying accumulated
knowledge, benefits for communication, teaching concepts and their relation-
ships, sharing of knowledge and resolving terminological incompatibilities. It
would therefore be beneficial to define an ontology for the structuring and
unifying of OO micro-architectural design knowledge (see Figure 2).
Before describing the ontology, we shall explain its field and scope. To this end
and to avoid ambiguity, we start by referring to the SWEBOK (Abran, 2004) to
ascertain where an ontology for OO micro-architectural design knowledge could
fit in, to find that it falls under “software design” (see Figure 1). What is not so
clear, however, is which of the five sub-areas of software design it belongs to
(see Figure 1), although we do find places for two elements of knowledge:
principles within “basic concepts” (“enabling techniques” in the SWEBOK text)
and design patterns in “structure and architecture.” However, the place of such
other concepts as refactorings is not so obvious (it is only briefly touched on in
the maintenance section). As our ontology concentrates on micro-architectures,
after examining the other areas, we consider the best place to be “structure and
architecture,” as this is what the strategies of architectural design are focused
on. Our proposition (see Figure 1) is to include a more generic area within

Figure 1. Context and situation of the ontology of OO micro-architectural

design knowledge according to the SWEBOK

Software Engineering Body of Knowledge

Software Design

Structure
Basic Key Issues Quality A nalysis Strategies
and Nota tions
Concepts in Design and Evaluation Methods
Architecture

Architec tural Architectural Micro

Families and
Structures- Styles- Architec tural
Frameworks
viewpoints patter ns Knowle dge

OO Micro Function Oriented

OO Micro
architectural Design Micro architectural
architec tural Design
Knowle dge Knowle dge
Knowle dge

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 The Object-Oriented Design Knowledge Ontology 11

“structure and architecture” called “micro-architectural knowledge” and divide

it into OO and functional micro-architectural knowledge. Our ontology struc-
tures the OO part.

Entities

When we start to describe the elements of the ontology, as we mentioned before,

we find many terms related with essential knowledge gained from experience
with object-oriented micro-architectural design, together with others arousing
confusion as to whether they constitute knowledge or not. In order to clarify the
situation, we have grouped the terms in question into two initial groups:

• Declarative knowledge: Concepts describing what to do with a problem:

Heuristics, patterns, bad smells, best practices, and so forth.
• Operative knowledge: Where there is a body of accumulated knowledge
concerning operations or processes for carrying out changes in software
(i.e., parameterized transformation of a program preserving its functional-
ity (Opdyke, 1992) including such concepts as refactoring.) Here we should
stress that we mean design refactoring, not code refactoring, which is more
common. Although we consider it important to group together all knowl-
edge related to OO micro-architectural design, we are naturally aware that

Figure 2. OO Micro-architectural design knowledge ontology

OO Micro Archit ectural Design Knowledge

name
intent
also known as
motivation
applicability
consequences
known uses

is composed of

0..*

Declarative 1..* Operative

is introduced by
collaborations sample design
participants

implies the uses of

Rule implies the use of Pattern Refactoring

0..*
recomendation (pre and pos condition) structure (or solution) mechanics
0..*

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
12 Garzás & Piattini

refactoring could be placed under the maintenance category in the

SWEBOK.

We can thus establish an initial classification of essential experience-based

knowledge of software design with two parts: declarative (what) and operative
(how). The former tells us what to do and the latter how, in both cases according
to experience (see Figure 2, where a UML class diagram is used to express the
ontology).
Considering “declarative knowledge” alone without regard to design patterns,
we have observed that principles, heuristics, bad smells, and so forth, have the
same common structure, there being no substantial difference between them, as
they all have the structure and form of a rule — they posit a condition and offer
a recommendation. It should be stressed that the “recommendation” is not a
solution like that of the pattern. Patterns are more formalized than rules and
pattern descriptions are always broader. They propose solutions to problems,
while rules are recommendations which a design should fulfill. Unlike patterns,
rules are greatly based on using natural language, which can be more ambiguous
(Pescio, 1997).
Lastly, in order to complete the description of the entities, we will concentrate
on their attributes. We based our determination of these on the terms used in
Gamma et al. (1995) to describe a design pattern: name, intent, also known as
motivation, structure, applicability, participants, collaborations, consequences,
implementation, sample code, known uses, and related patterns. It will be
observed that many of these items are common to other elements of knowledge
and these common attributes are located in the top entity (see Figure 2). As to
the other attributes under consideration, the structure attribute is a synonym for
solution in a pattern, while we have created the recommendation attribute for
rules, which would be close to the solution of the pattern (Pescio, 1997) and the
mechanics attribute for refactorings, our choice of name being taken from
Fowler, Beck, Brant, Opdyke, and Roberts’ (2000) refactoring catalogue. The
attributes participants (the classes and/or objects participating in the design
pattern and their responsibilities) and collaborations (how the participants carry
out their responsibilities together) concern declarative knowledge. The sample
design attribute concerns operative knowledge. The implementation attribute is
substituted for mechanics (this is in refactoring, as we are dealing with design
refactoring, not code refactoring). The related patterns attribute has been
generalized and appears in each of the relationships between entities.
In line with our ontology we have developed a unified catalog of rules, which we
see in Chapter X, where in order to improve the detection of rules, these are
named according to their condition.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 The Object-Oriented Design Knowledge Ontology 13

Relationships

We shall now concentrate on the relationships between entities (see Figure 2):

• “To apply a rule implies the use of a pattern.” Often, when we introduce a
rule, we obtain a new design, which needs a pattern. One example of this
situation is the application of the “dependency inversion” rule, a principle
(Martin, 1996) which introduces an abstract class or an interface, which in
turn necessitates a creational pattern (Gamma et al., 1995) to create
instances and associate objects in the new situation. Observe that this does
not always happen (cardinality 0 to n), not all the rules imply the introduction
of a pattern, a clear example of this being when we apply rules which work
only inside a module, for example the “long method” rule, a bad smell
according to Fowler et al. (2000).
• “To apply a pattern implies the use of another pattern.” This relationship
is quite obvious, since it has been featured in catalogs and pattern languages
for some time. An example of this is the map of relationships between
patterns presented in (Gamma et al., 1995). Observe that in this case,
cardinality is from 0 to n (we can see in Gamma et al. (1995) how adapter,
proxy and bridge patterns are isolated).
• “The declarative knowledge is introduced by operative knowledge.” This
relationship expresses that all declarative knowledge (rules and patterns)
is introduced in the design by an element of operative knowledge (a
refactoring); note that cardinality is from 1 to n. This is quite obvious since
it does not make sense for an element of declarative knowledge to exist if
it cannot be introduced.
• The relationship between patterns and refactorings can be observed in an
implicit way by reading some of the refactoring catalogues which concen-
trate on the design level, a good example of this being the Fowler et al.
(2000) catalog. Gamma et al. (1995) state that “design patterns provide the
refactorings with objectives,” and there is a natural relationship between
patterns and refactorings, where the patterns can be the objective and the
refactorings the way of achieving them. In fact, as Fowler et al. (2000) say,
there should be catalogs of refactorings which contemplate all design
patterns. In this way, refactorings, such as “replace type code with state/
strategy” or “form template method,” concentrate on introducing patterns
within a system (again to emphasize that these are design refactorings, not
code refactorings).
• The relationship between rules and refactorings has not been studied as
much as that between patterns and refactorings. Generally, we observe

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
14 Garzás & Piattini

that rules are introduced in the design, just like patterns, by means of the
refactorings. And in the light of what has been said previously, it becomes
clearer how refactorings store knowledge about how to introduce elements
in designs in a controlled way. Continuing with the example of the
“dependency inversion” rule we see that in order to resolve the violation of
this rule we insert an abstract entity into the design, which would be carried
out with the refactorings.
• “An element of operative knowledge is composed of others.” Examples of
this composition can be found in refactoring catalogs such as Fowler et al.
(2000) where, for example, the refactoring “extract method” is not com-
posed but it is used by others (cardinality 0 to n).

Lastly, we shall explain why other relationships are not included.

• Relationship: “A pattern implies the use of a rule.” The introduction of a

pattern must not allow a rule to be violated (applying a pattern should never
reduce design quality).
• Relationship: “A rule implies the use of a rule.” In a similar way to the
previous case, the introduction of one rule must not allow another rule to be
violated (applying a rule should never reduce design quality).
• Relationship: “An operative knowledge implies a declarative knowl-
edge.” A refactoring does not know what rule or pattern it uses.

An Empirical Validation
In this section, we will present a description of the process followed to carry out
the empirical validation, which is based on Wohlin et al. (2000); Prechelt and
Unger (1998); Prechelt et al. (1997); Prechelt et al. (2001); Kitchenham,
Pfleeger, Pickard, Jones, Hoaglin, El Eman, et al. (2002); and (Kitchenham,
Dybå, and Jorgensen, 2004). The main intention of this controlled experiment
was to compare the effectiveness and efficiency of “traditional” OO design vs.
the use of OO design knowledge. Moreover, we aimed at analyzing if disposing
of a rules catalog that unifies design knowledge as principles, best practices,
heuristics, and so on, and their relations with patterns has influence on the
effectiveness and efficiency in the improving of the quality of OO micro
architectures.
Based on the GQM (goal question metrics) template, the goal definition of our
experiment can be summarized as shown in Table 1.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 The Object-Oriented Design Knowledge Ontology 15

Table 1. Definition of experiment

Analyze The improvement method based on the rules catalog
for the purpose of evaluating
with respect to effectiveness and efficiency
from the point of software engineers
view of
in the context of software companies in Spain

Planning

The experiment is specific since it is focused on one technique applied to one

domain; the ability to generalize from this specific context is further elaborated
below when discussing threats to the experiment. The experiment addresses a
real problem, which is whether the method presented is more effective and
efficient to be used in OO micro architectural quality improvement.
Eighteen professionals of two companies carried out the experiment. The
selected subjects were professionals having extensive experience in OO design.
We classified the subjects into two groups according to their professional
experience. The subjects were asked to fill a questionnaire out about their
expertise, and taking into consideration the collected responses, we formed two
groups of subjects, trying to have the same number of subjects with good marks
and bad marks in each group. Both groups had a patterns catalog (Gamma et al.,
1995), but only one of them had the rules catalog (see Chapter X). In addition to
this, in a previous 30 minutes session, we explained to this group some notions
about rules and their relationships to patterns and how to apply the rules catalog.
For each subject, we had prepared a folder with the experimental material. Each
folder contained one micro-architectural diagram and a questionnaire for an-
swers.
We had to consider what independent variables or factors were likely to have an
impact on the results. These are OO micro-architecture.
We considered two dependent variables (Thelin, Runeson, Wholin, Olsson, &
Andersson, 2004):

• Effectiveness: Number of defects found/total number of defects. This is

the percentage of the true improvements found by a designer with respect
to the total number of defects.
• Efficiency: Number of defects found/inspection time, where inspection
time is related to the time that subjects spent on inspecting the micro
architecture; it is measured in minutes.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
16 Garzás & Piattini

Hypotheses Formulation

Our purpose was to test two groups of hypotheses, one for each dependent
variable.
Effectiveness hypotheses:

• H 0,1. There is no difference regarding effectiveness of subjects in

detecting the violation of rules using a rules catalog and their relationship
with patterns as compared to subjects without using the rules catalog.
// H1,1 : ¬ H 0,1
• H0,2. There is no difference regarding effectiveness of subjects in detecting
the application of patterns implicated by rules using a rules catalog s and
their relationship with patterns as compared to subjects without using the
rules catalog. // H1,2 : ¬ H 0,2
• H0,3. There is no difference regarding effectiveness of subjects in detecting
the application of patterns not implicated by rules using a rules catalog and
their relationship with patterns as compared to subjects without using the
rules catalog. // H1,3 : ¬ H 0,3

Efficiency hypotheses:

• H0,4. There is no difference regarding efficiency of subjects in detecting the

violation of rules using a rules catalog and their relationship with patterns
as compared to subjects without using the rules catalog. // H1,4 : ¬ H0,4
• H0,5. There is no difference regarding efficiency of subjects in detecting the
application of patterns implicated by rules using a rules catalog and their
relationship with patterns as compared to subjects without using the rules
catalog. // H1,5 : ¬ H0,5
• H0,6. There is no difference regarding efficiency of subjects in detecting the
application of patterns not implicated by rules using a rules catalog and their
relationship with patterns as compared to subjects without using the rules
catalog. // H1,6 : ¬ H 0,6

Operation

In this section, we will describe the preparation, execution, and data validation
of the experiment. Before the day of the experiment execution, we gave a
seminar to the subjects of the group that would use the rules catalog. In this

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 The Object-Oriented Design Knowledge Ontology 17

seminar, we explained to the subjects how to apply the rules catalog. The
subjects had to manually fulfill their proposed solution, writing down the start and
end time of the activity. We collected the forms filled out by the subjects,
checking if they were complete.

Analysis and Interpretation

Figure 3 shows the averages obtained from the experiment. Outliers have not
been identified. In order to decide how to test the validity of the hypotheses, we
evaluated if the data followed a normal distribution. The result was normal; we
decided to perform a t-Student test. In Table 2 the results obtained by means of
t-Student are shown. The first column represents the t-stat and the second
column shows the t critical two-tail.
We have obtained the following results. Firstly, it was confirmed by the t-Student
test that the group with the rules catalog obtained better results in “efficacy and
efficiency in detection of rules” and “efficacy and efficiency in detection of
patterns implicated by rules.” In the second place, the t-Student test could not
confirm that the group with the rules catalog obtained better results in “efficiency
in detection of patterns not implicated by rules.” However, this group obtained
better averages; we have to highlight that “efficiency in detection of patterns not
implicated by rules” is not influenced by the rules catalog, since these patterns
are not in the catalog because they are not implicated by rules, and the application
of these patterns will result in the detection of design problems more than design
recommendations. Lastly, in a similar way, we could not confirm by using the t-
Student test that the group without the rules catalog obtained better results in
“efficacy in detection of patterns not implicated by rules”; however, again, this
result is not influenced by the rules catalog.

Figure 3. Averages obtained from the experiment

0,8 0,71 0,68
0,7 0,64 0,64

0,6
0,5
0,4
0,3 0,26
0,18 0,18
0,2 0,12
0,08 0,07
0,1 0,04 0,04
0
Effi cacy in Detecti on of Effi cacy i n Detecti on of Efficacy in Detection of Effi ciency in Detection of Effi ciency in Detection of Effi ciency in Detection of
Rul es. Patterns not im plicated by Patterns impl icated by Rul es. Patterns not impl icated by Patterns im pl icated by
rules. rules. rul es. rul es.

Group with catalog of rules Group w ithout catalog of rules

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
18 Garzás & Piattini

Table 2. Results obtained by means of t-Student

t stat t Critical two-tail

Efficacy in Detection of Rules. 5.38887 2.26215
Efficacy in Detection of Patterns not implicated by rules. -0.22360 2.20098
Efficacy in Detection of Patterns implicated by rules. 3.36269 2.20098
Efficiency in Detection of Rules. 7.03868 2.26215
Efficiency in Detection of Patterns not implicated by rules 0.22269 2.26215
Efficiency in Detection of Patterns implicated by rules 4.35678 2.17881

Threats to Validity

A list of issues that threatens the validity of the empirical study is identified
below.

Conclusion Validity

The results confirmed by means of the t-Student test that there was a significant
difference between the two groups, and that the new approach seems to be more
effective and efficient for carrying out the OO micro architectural quality
improvement. The statistical assumptions of each test were verified, so that the
conclusion validity was fulfilled.

Internal Validity

• Differences among subjects: We formed two groups, and the subjects

were apportioned between these two groups according to their expertise
and skills. For this reason, the subjects were asked to fill out a questionnaire
about their expertise, and taking into account the collected responses, we
formed the two groups of subjects.
• Differences among OOD diagrams: We used only one OOD diagram.
• Precision in the time values: The subjects were responsible for record-
ing the start and finish times of each test, so they could introduce some
imprecision but we think it is not very significant.
• Fatigue effects: The average time for carrying out the experiment was 20
minutes, so fatigue effects were minor.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 The Object-Oriented Design Knowledge Ontology 19

• Persistence effects: Persistence effects are not present because the

subjects had never participated in a similar experiment.
• Subject motivation: The subjects were very motivated.
• Other factors: For instance, plagiarism and influence among subjects
were controlled.

External Validity

Two threats to validity have been identified which limit the possibility of applying
any such generalization:

• Subjects: We are aware that more experiments with professionals must be

carried out in order to be able to generalize these results. However, the
subjects could be considered “common” OO designers at least in the
context of Spanish software companies.
• Material used: We believe that the documents used might not be
representative of an industrial problem, so more experiments with larger
diagrams are needed.

Works Related with Empirical Studies

About OO Knowledge
There are few empirical studies and related work about this topic. The recent
interest in empirical studies about patterns, mainly, or any other kind of
knowledge has focused on how these factors impact on the software mainte-
nance process. In this regard, the main and more important studies are Prechelt’s
works that are the best example of empirical investigation about patterns.
The Prechelt et al. (1997) empirical study affirms that depending on the
particular program, change task, and personnel, pattern documentation in a
program may considerably reduce the time required for a program change and
may also help improve the quality of the change; and recommends that design
patterns are always explicitly documented in source code.
In Prechelt and Unger (1998), the experiments showed that carefully document-
ing patterns usage is highly recommendable because it works well during
maintenance and that design patterns can be beneficial even when an alternative
solution appears to be simpler but that unsuitable application can also be harmful
in other situations. The resulting practical advice calls to apply common sense

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
20 Garzás & Piattini

when using design patterns instead of using them in a cookbook fashion. Prechelt
et al. (2001) state that it is not always useful to apply design patterns if there are
simpler alternatives; they recommend using common sense to find the exceptions
where a simpler solution should be preferred and even where this common sense
suggests that using a patterns might not be a good idea.
On the other hand, there are very few works related to empirical studies about
design knowledge different to patterns. In this sense, we can highlight (Deligiannis,
Shepperd, Roumeliotis, & Stamelos, 2003) work, which investigated the effects
of a single design heuristics (god class) on system design documents (with
respect to understanding and maintainability), where the results showed that
design heuristics can affect maintainability, where designs with heuristics are
easier to understand and modify. According to this study, a design initially
structured under heuristics has a higher probability of continuing to evolve in a
resilient and flexible manner; if heuristics are violated, the probability of
maintenance changes leading to poorer designs increases.

Acknowledgments
This research is partially supported by the ENIGMAS (Entorno Inteligente
para la Gestión del Mantenimiento Avanzado del Software) project, sup-
ported by the Department of Education and Science of the Junta de Comunidades
de Castilla - La Mancha (Regional Government of Castile - La Mancha) (PBI-
05-058).

Conclusion
The motivation of the authors of the first catalog of patterns and of the
community that investigates patterns has been to transfer the OODK accumu-
lated during years of experience. Since then, designers have been reading and
using patterns, reaping benefit from this experience. Nevertheless, more knowl-
edge exits apart from patterns. We need to characterize the OO design
knowledge, and we created an OODK ontology for it. An ontology describes
domain knowledge in a generic way and provides agreed understanding of a
domain. As Gruber (1991) said, “I use the term ontology to mean a specification
of a conceptualization. That is, an ontology is a description of the concepts and
relationships that can exist”.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 The Object-Oriented Design Knowledge Ontology 21

On the other hand, there are few empirical studies related to OO design
knowledge. We presented a description of the process followed to carry out an
empirical validation, which is based on the use of OO design knowledge. The
main objective of this controlled experiment was to compare the effectiveness
and efficiency of a “traditional” OOD process with the new OOD approach.
Eighteen professionals (selected for convenience) of four Spanish companies
(divided in two groups) carried out the experiment. In a previous session of 30
minutes we trained one group in the using of the new approach. For each
participant, we had prepared a folder with one OO class diagram and one
questionnaire, and for the members of the “new approach” group we included the
OOD ontology with the main OOD “knowledge” (rules, patterns, etc.). The
results confirmed by means of t-Student test that there was a significant
difference between the two groups, and that the new approach seems to be more
effective and efficient for carry out the OOD Process.

References
Abran, A. (Ed.). (2004). Guide to the software engineering body of knowl-
edge: SWEBOK. Los Alamos, CA: IEEE CS Press.
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., & Stal, M. (1996). A
system of patterns: Pattern-oriented software architecture. Addison-
Wesley.
Coad, P. (1992). Object-oriented patterns. Communications of the ACM,
35(9), 152-159.
Deligiannis, I., Shepperd, M., Roumeliotis, M., & Stamelos, I. (2003). An
empirical investigation of an object-oriented design heuristic for maintain-
ability. Journal of Systems and Software, 65(2), 127-139.
Fowler, M. (1996). Analysis patterns: Reusable object models. Boston:
Addison-Wesley.
Fowler, M., Beck, K., Brant, J., Opdyke, W., & Roberts, D. (2000). Refactoring:
Improving the design of existing code. Boston: Addison-Wesley Profes-
sional.
Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design patterns.
Reading, MA: Addison-Wesley Professional.
Gruber, T. (1991). The role of a common ontology in achieving sharable,
reusable knowledge bases. Paper presented at the Second International
Conference on Principles of Knowledge Representation and Reasoning,
Cambridge.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
22 Garzás & Piattini

Jurisica, I., Mylopoulos, J., & Yu, E. (1999, October). Using ontologies for
knowledge management: An information systems perspective knowl-
edge: Creation, organization and use. Paper presented at the 62 nd
Annual Meeting of the American Society for Information Science (ASIS
99), Washington, DC.
Kitchenham, B. A., Dybå, T., & Jorgensen, M. (2004). Evidence-based
software engineering. Paper presented at the International Conference
on Software Engineering (ICSE), Edinburgh, Scotland, UK.
Kitchenham, B. A., Pfleeger, S. L., Pickard, L., Jones, P., Hoaglin, D., El Eman, K.,
et al. (2002). Preliminary guidelines for empirical research in software
engineering. IEEE Transactions on Software Engineering, 28(8), 721-734.
Martin, R. C. (1996). The dependency inversion principle. C++ Report, 8(6),
61-66.
Opdyke, W. (1992). Refactoring object-oriented frameworks. Thesis, Com-
puter Science, Urbana-Champain, IL.
Pescio, C. (1997). Principles versus patterns. Computer, 30(9), 130-131.
Prechelt, L., & Unger, B. (1998). A series of controlled experiments on
design patterns: Methodology and results. Paper presented at the
Softwaretechnik 1998 GI Conference (Softwaretechnik-Trends), Paderborn.
Prechelt, L., Unger, B., Philippsen, M., & Tichy, W. (1997). Two controlled
experiments assessing the usefulness of design pattern information during
program maintenance. IEEE Transactions on Software Engineering,
28(6), 595-606.
Prechelt, L., Unger, B., Tichy, W., Bössler, P., & Votta, G. (2001). A controlled
experiment in maintenance comparing design patterns to simpler solutions.
IEEE Transactions on Software Engineering, 27(12), 1134-1144.
Rising, L. (1998). The patterns handbook: Techniques, strategies, and
applications. Cambridge: Cambridge University Press.
Thelin, T., Runeson, P., Wholin, C., Olsson, T., & Andersson, C. (2004).
Evaluation of usage based reading conclusions after three experiments.
Empirical Software Engineering, 9(1-2), 77-110.
Wendorff, P. (2001). Assessment of design patterns during software
reengineering: Lessons learned from a large commercial project.
Paper presented at the Proceedings of the 5th European Conference on
Software Maintenance and Reeingineering (CSMR), Lisbon, Portugal.
Wohlin, C., Runeson, P., Höst, M., Ohlson, M., Regnell, B., & Wesslen, A.
(2000). Experimentation in software engineering: An introduction.
Kluwer Academic Publishers.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Using Linguistic Patterns to Model Interactions 23

Chapter III

Using Linguistic
Patterns to Model
Interactions
Isabel Díaz, Central University of Venezuela, Venezuela

Oscar Pastor, Technical University of Valencia, Spain

Lidia Moreno, Technical University of Valencia, Spain

Alfredo Matteo, Central University of Venezuela, Venezuela

Abstract

The dynamic behavior of a system is elicited, specified, and analyzed by

means of interaction modelling. This activity is important for object-
oriented software development because it provides the information that is
required to construct the system conceptual model. Several interaction
modelling techniques have been proposed. However, this activity continues
to be a complex and tedious task for the modellers. These problems arise
from the intrinsic difficulties of interaction modelling and the lack of
effective techniques and tools to support to the modellers. In this chapter,
heuristic-oriented techniques and linguistics-oriented techniques proposed
by several authors to model interactions are analyzed. In addition, a

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
24 Díaz, Pastor, Moreno, & Matteo

framework to facilitate and to improve the interaction modelling is described.

This framework was conceived to be integrated into automatic software
production environments. It uses linguistic patterns to recognize interactions
from use case models. The patterns were validated with expert modellers.
The validation process carried out and the main results are also presented.

Introduction
Dynamic models fulfil an important role in the development of object-oriented
software systems. These describe the behavior of a system in terms of: (1) the
state change of an object, which is due to an event or the execution of an
operation (intraobject dynamic perspective); and (2) how the objects should
interact to provide the system with a determined behavior (inter-object dynamic
perspective). This chapter is based on the study of the interobject dynamic
perspective and, in particular, on the construction process of the object interac-
tion models in order to describe the behavior of a system.
The modelling of interactions is one of the most frequently overlooked practices
in software development. While the structural model is considered to be
fundamental for the analysis and design of the systems, the dynamic model is
considered to be optional (Larman, 2004; Rosenberg & Scott, 1999). Neverthe-
less, both models contribute two complementary views of the system design that,
taken separately, would be insufficient. Our experience, which coincides with
that reported by other authors, has led us to believe that this problem may have
originated in the high level of difficulty of interaction modelling, especially for
inexperienced modellers (Larman, 2004; Rosenberg & Scott, 1999; Song, 2001).
On the one hand, modelling is an inherently complex activity that, in any case,
depends on the experience and the domain knowledge of the modeller. On the
other hand, the difficulty of constructing interaction models is also determined by
other circumstances that are explained below.
The result of a thorough review of the literature has indicated that software
development approaches that describe a technique for interaction modelling are
scarce. The aids offered to the modeller to facilitate the task of identifying and
specifying interactions are very few when compared to the extensive descrip-
tions that are made of the modelling language. The nature of the diagrams that
are used to graphically represent the interaction models, generally sequence
diagrams (SDs) or message sequence charts (MSCs), also constitutes an
obstacle for modelling (ITU, 2000; OMG, 2003). The amount of time that must
be spent on elaborating and troubleshooting these diagrams makes them tedious
activities, which many modellers attempt to avoid. Model editing tools available

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Using Linguistic Patterns to Model Interactions 25

on the market, such as Rational or Visio, are not very flexible and do not offer
mechanisms that adapt to specific graphical needs. The complexity of interaction
modelling is even greater when the difficulty of maintaining consistency between
this model and other structural and dynamic models of the system is added.
The purpose of this chapter is to establish the basis that a generic framework
created to facilitate interaction modelling and to promote this activity during
system development must have. The strengths and weaknesses of the interaction
modelling techniques that are commonly applied are analyzed in order to
determine the requirements that this framework must fulfil. Thus, the framework
is defined in the context of the contributions that other approaches have made
to interaction modelling.
The goal of this framework (hereafter called metamorphosis) is to provide
support to modellers in the interaction model construction during the first stages
of the development of a system. However, its use can be extended to the
complete life cycle of the software (OMG, 2003; Van Lamsweer, 2000).
Metamorphosis assumes that the system behavior specification is expressed
through use case models (Nuseibeh & Easterbrook, 2000; OMG, 2003). A use
case is a document written in natural language that describes part of the system
functionality from the perspective of its users (Jacobson, Christerson, Jonsson,
& Övergaard, 1992). The analysis or interpretation of the use cases shows
how the system components exchange information so that the system has the
behavior specified by the analysts (OMG, 2003; Van Lamsweer, 2000). The
result of this analysis is represented using interaction models.
In metamorphosis, the analysis process lies in the automatic generation of the
interaction diagrams from the use cases in order to guarantee the following: (1)
consistency of the interaction model itself, as well as its consistency with the
corresponding use case model; (2) ease of use promoting the automatic
generation of the interaction diagrams, so that the modeller can spend more time
on more important tasks such as the resolution of conflicts originated by the
ambiguity inherent in the use of natural language, the incorporation of supple-
mentary information into the interaction diagrams (restrictions, comments, etc.),
or the validation of the model obtained; (3) traceability to establish links that can
be documented, controlled, and maintained, so that the modeller can determine
the part of the use case text from which an interaction was generated and vice-
versa; and (4) representation richness to incorporate relevant semantic
information beyond the basic elements of an interaction (i.e., synchronous/
asynchronous messages, concurrence specification, repetition, or conditioning of
interactions, parameter identification, consultations/updating, etc.).
The metamorphosis framework must reconcile contributions from both compu-
tational linguistics and software engineering to be able to fulfil the requirements
described above. Computational linguistics provides metamorphosis with the

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
26 Díaz, Pastor, Moreno, & Matteo

natural language processing techniques and tools to recognize the elements

participating in an interaction model from the use case text. Software engineer-
ing provides metamorphosis with a system development orientation that is
focused on the construction and the successive transformation of these models.
Thus, text analysis of the use cases is defined at a high level of abstraction,
making it independent from the domain of the system under development and
from specific implementation considerations. In addition, it is convenient to use
patterns to describe the analysis solutions. A pattern can specify the generic
solution to a recurrent problem of use case analysis. The patterns are suitable
resources for storing the knowledge about these solutions so that it can be reused,
shared and communicated whenever this knowledge is necessary (Gamma,
Helm, Johnson, & Vlissides, 1992).
This chapter has been structured in five sections. The next section presents an
overall view of the most representative approaches about interaction modelling
as well as their advantages and disadvantages. The second section explains how
metamorphosis interprets the interaction concept and describes the properties of
the interaction model. The third section explains the process of extracting
information from the use cases, and the strategy followed to transform them into
interactions. It also presents an example of the application of the transformation
framework. The fourth section describes an experiment performed to validate
the transformation patterns as well as some of the results obtained. The last
section presents the lessons learned and future directions.

Interaction Modelling Techniques:

An Overview
In general, approaches that propose interaction modelling as a resource to develop
systems emphasize the description of the syntax and semantics of its elements;
however, they barely explain how this model can be constructed. Some approaches
have attempted to answer this question by formulating procedures to aid modellers
in their work. In this study, the procedures set forth by these approaches will be
referred to by the generic name of interaction modelling techniques regardless of
the scope, formality or level of complexity (Rumbaugh, 1995; Wieringa, 1998).
Interaction modelling techniques can be characterized as being based on: (1) a
heuristic application, using a step-by-step guide in the construction of interaction
models (heuristic-oriented techniques); or (2) the use of linguistic information, as
a way to identify and to specify interactions (linguistics-oriented techniques). The
purpose of this type of classification is to simplify the analysis and to determine the
strengths and weaknesses of these techniques.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Using Linguistic Patterns to Model Interactions 27

Heuristic-Oriented Techniques

One of the pioneers in the use of interaction models to describe the behavior of
a system was Jacobson, whose object-oriented software engineering (OOSE)
method introduces object interaction diagrams (Jacobson et al., 1992). These
diagrams are prepared for each use case after preparing their robustness
diagrams. A robustness diagram shows the entity classes, interface (or bound-
ary) classes, and control classes of each use case, and the possible dynamic
relations between these object classes, including the participation of the actors.
To construct the object interaction diagrams, the OOSE method suggests going
through the following steps: (1) partitioning the use case text, and placing these
fragments on the left side of the diagram; (2) placing the use case actors; (3)
adding the interface and control objects identified in the robustness diagram; (4)
adding the entity objects of the use case identified in the robustness diagram; and,
(5) identifying the messages exchanged by the classes for each piece of text of
the use case (each piece of text is located on the left side of the diagram, near
the identified messages). The OOSE method transfers the complexity of
elaborating interaction diagrams to the robustness diagrams. However, the
method does not offer further help to construct the robustness and interaction
diagrams; therefore, the identification of the interactions (step 5) remains
unresolved. Furthermore, the interaction diagrams are troublesome to prepare
due to the use of different types of classes and the incorporation of the pieces
of text of the use cases.
Rosenberg and Scott basically follow the same procedure described by the
OOSE method for modelling interactions (Rosenberg & Scott, 1999). In an
attempt to facilitate the recognition of messages, they suggest the use of class-
responsibility-collaboration (CRC) cards (Wirfs-Brock, Wilkerson, & Wiener,
1990). This strategy helps in determining the operations of a class, but it is not
performed in the context of message exchange. Thus, the CRC cards cannot
guarantee the identification of all the necessary operations for the system to
adopt certain behavior.
Another process that proposes the construction of SD as part of the analysis and
design activity of the system use cases is the rational unified process (RUP)
(Jacobson, Booch, & Rumbaugh, 1999). The procedure set forth in the RUP
offers no substantial differences with respect to the techniques described
previously. The Ambler technique formulated to facilitate SD construction is
similar to the RUP technique (Ambler, 2004).
A similar process is carried out during the requirements analysis phase of the OO
method (object-oriented method) (Insfrán, Pastor & Wieringa, 2002; Pastor,
Gómez, Insfrán, & Pelechano, 2001). The main activity of this phase is the
elaboration of SD, which is based on a characterization of the information

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
28 Díaz, Pastor, Moreno, & Matteo

contained in the system use cases. The paths of the use cases describe actor/
system communication actions (actions performed by the actor or the system to
exchange information) or system response actions (system actions that are
potentially capable of changing the system state). The SD of the OO method uses
the Unified Modelling Language (UML) and distinguishes the types of object
classes introduced by Jacobson: entity, boundary and control classes (Jacobson
et al., 1992; Rosenberg & Scott, 1999). The steps that the modeller must perform
are the following: (1) to prepare a SD for each of the use case paths (one for the
basic path and one for each alternate path); (2) the use case actors participate
as classes in the SD; (3) each actor/system communication action of the use case
is represented through one or more messages between an actor class and a
boundary class (which is usually called system); (4) each use case action of the
system response type is represented in the SD by one or more messages between
the boundary class and the entity classes, or by one or more messages between
entity classes. As in the above-mentioned approaches, the OO method provides
no further help to recognize the entity classes or the messages that they
exchange.
The technique proposed by Larman uses system sequence diagrams to
represent the use case scenarios (Larman, 2004). These diagrams show the
interaction between the actor and a generic entity called system. This entity acts
as a black box that hides the system internal structure. Each identified interaction
must later be analyzed using patterns. A pattern explains in detail how this
interaction can be broken down into one or more messages between system
objects. The SD uses the UML and does not distinguish the types of objects in
an explicit way. Larman’s idea based on patterns is novel and seems effective.
Nevertheless, it lacks both a systematic process to be able to apply conveniently
these patterns and a catalog containing the patterns corresponding to the most
representative interactions.
Song sets forth the application of the ten-step heuristic on sequence diagram
development (Song, 2001). The application of this technique requires the prior
preparation of the system object model and the use case model (diagrams and
textual specification). It uses the UML to represent the SD in which the types
of objects (entity, control, and boundary) are distinguished. The steps of this
technique can be summarized as follows: (1) the message initiating the flow of
events is sent by the actor to the system; (2) a primary boundary object and a
primary control object are defined for each use case; if needed, secondary
objects (boundary or control) are created; (3) a secondary control object is
defined for each use case that is included or extended; (4) the problem-solving
operations (creation/destruction, association forming, or attribute modification)
are identified in the use case; and (5) each message is named and supplied with
optional parameters. To identify the types of problem-solving operations, Song
suggests highlighting the verbs in the use case text and selecting those that

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Using Linguistic Patterns to Model Interactions 29

indicate actions that were formulated to solve the problem. These verbs can be
considered as names of potential problem-solving operations. This technique can
be considered a step forward with respect to other techniques, because it is more
thorough in identifying instances and in recognizing messages (through the
problem-solving operations). However, Song’s technique leaves two questions
unresolved: how to identify the sending and receiving classes of these messages
and how to deduce an interaction composed by more than one message from a
single verb.
Hilsbos and Song have improved their initial proposal with the tabular analysis
method (TAM) (Hilsbos & Song, 2004). The introduction of this method attempts
to answer the two preceding questions. The TAM lies in applying heuristics to
complete a seven-column table before constructing the SD of each use case.
Each column respectively indicates the number of each step of the use case, the
action described in that step, the name of the message, its parameters, its
restrictions, its sender, and its receiver. Initially, messages that are always sent
and received by the actor or the system are obtained from the table. Then, this
information is refined by breaking down each of the messages in terms of other
messages that have been established between the primary control object and
entity objects, or between two or more entity objects. To support the task of
identifying these messages, the guidelines that recognise the problem-solving
operations presented in Song should be followed (Song, 2001). The TAM
facilitates the organization of the information obtained from the use cases.
However, it supplies no further help for the modeller to recognize this informa-
tion. The graphic representation of the SD can be carried out with the information
contained in the table.

Linguistics-Oriented Techniques
In recent decades, many approaches have relied on natural language processing
techniques to facilitate the development of software systems (Boyd, 1999; Chen,
1976; Métais, 2002; Rumbaugh, Blaha, Premerlani, Eddy, & Lorensen, 1991). In
this section, we refer to those approaches that are based on the linguistic
properties of a text to obtain information and that allow the automatic construc-
tion of models (Burg & van de Riet, 1996; Juristo, Moreno, & López, 2000;
Overmyer, Lavoie & Rambow, 2001). More specifically, we study the ap-
proaches that allow dynamic models to be obtained from system behavioral
specifications written in unrestricted natural language (Burg & van de Riet,
1995; Flield, Kop, Mayerthaler, Mayr, & Winkler, 2000). To facilitate this
review, we distinguish two groups. The first group includes first-generation
proposals that do not set forth a procedure to directly derive the system interaction

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
30 Díaz, Pastor, Moreno, & Matteo

model. The proposals representing this group are: Color-X (Burg & van de Riet,
1995; Dehne, Steuten, & van de Riet, 2001), NIBA (Kop & Mayr, 2002), and the
behavior model presented in Juristo et al. (2000). These works are very interesting
from the perspective of natural language processing; however, they are not studied
in this chapter, as these approaches do not allow the direct deduction of complete
interaction models. They use intermediate models to give information to the
modellers so that they can later obtain the interaction models.
The second group of linguistic-oriented techniques includes second-generation
proposals. They have been especially created to deduce interactions from use cases,
such as the works of Feijs and Li, which can be considered referential for our
research (Feijs, 2000; Li, 2000). Feijs establishes correspondences between some
types of sentences written in natural language and MSC (ITU, 2000). A use case
is considered as a sequence of sentences, each of which is associated to a
semantically equivalent type of MSC. A sentence has a specific syntactic structure
that contributes information about active and passive objects, values, instance
identities, properties (attributes), methods, and events. This information has a
counterpart in its corresponding MSC.
Sentences are classified as information, action, or state. They describe information
exchange, object handling, or state, respectively. A context-free grammar is
defined, and a set of correspondence rules is proposed between the syntactic
components of each sentence and the elements of an MSC. It assumes the
preexistence of a domain object model to ensure the terminological consistency of
the use cases. The proposal does not address the identification of message
arguments, nor does it study conditional sentences, iterations, or relationships
between use cases (extension and inclusion) and their respective equivalents in an
MSC.
Li also sets forth a semiautomatic process for deriving SD from the textual
descriptions of the use cases. The text of the use case is normalized. The description
can only use sentences with a single subject and a single predicate or action. The
translation partially generates a set of instances and some of the messages that are
exchanged. The SD must then be completed manually by the analyst. This proposal
takes into account conditional sentences and iterations, but it does not address the
relationships between use cases (extension and inclusion).

An Outline of Interaction
Modelling Techniques
Each of the techniques studied reveals the trends followed in areas such as software
engineering, which serves as the framework for heuristic-oriented techniques.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Using Linguistic Patterns to Model Interactions 31

Therefore, the predominant aspect of the heuristic-oriented techniques is the use

of models that are especially created to both specify and analyze system dynamic
behavior. The information used to generate the interaction diagrams is obtained
from an initial model that describes the system domain. The semantic richness
of the modelling language acquires importance. Thus, most heuristic-oriented
techniques coincide in the following:

1. To differentiate the instances that participate in these diagrams, using

Jacobson’s classification on control, boundary, and entity objects (Jacobson
et al., 1992).
2. To establish close semantic relationships between some of the model
abstractions from which information is extracted and the abstractions of the
obtained model (i.e., the actor in the use case model is an element in the
interaction model having the same meaning).
3. To derive the interactions using information from the use case model. A use
case is considered as an analysis unit to derive interaction diagrams.
4. To use the object model to facilitate the identification of the instances that
participate in a SD and to ensure the consistency of the models.
5. To establish structural correspondences between the elements that de-
scribe both the use case model and the interaction model (i.e., a control
object is created for each use case included or extended).
6. To set up heuristics or rules to obtain the interaction model. The application
of these rules depends exclusively on the modeller’s criterion, personal
experience, and domain knowledge.
7. To facilitate the graphical representation of the interaction models with the
aid of tools. The tools do not support the automatic generation of these
representations or the handling of the model consistency.

Computational linguistics has served as the basis for linguistics-oriented tech-

niques. In particular, the second-generation outline of these techniques has been
adjusted to the most important characteristics of the heuristic-oriented tech-
niques. Thus, second-generation linguistics-oriented techniques synthesize the
properties of all the other techniques, overcoming many of their weaknesses.
They have adopted a model-oriented approach, both to describe the information
extraction source and the interaction representation. Syntactic analysis has been
considered as a fundamental resource for generating the interaction model. The
main characteristics of second-generation linguistics-oriented techniques are
the following:

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
32 Díaz, Pastor, Moreno, & Matteo

1. The use case model is used to extract information. This model is widely
known and has been developed to specify system behaviors.
2. The dynamic model generated is based on the basic primitives for interac-
tion representation (instances, messages, and parameters).
3. In addition to the information provided by the syntactic analysis of the use
case sentences, the interaction deduction process uses the system struc-
tural information.
4. The second-generation linguistics-oriented techniques presume the support
of a tool that allows the (semi)automatic generation of the interaction
diagrams. The modeller’s participation is then limited to completing the
generated diagrams and validating them.

New Alternatives
In spite of the contributions of the interaction modelling techniques, they have some
weaknesses that should be eliminated in order to improve this activity. The creation
of the metamorphosis framework attempts to fulfil this goal. Therefore, the
metamorphosis definition must: (1) overcome the limitations of the interaction
modelling techniques that have been proposed until now; (2) take into account the
strengths that these techniques have demonstrated; and (3) utilize the current
proposals in software engineering and computational linguistics to enrich the
interaction modelling techniques. These three factors have contributed to determi-
nate an outline for the metamorphosis framework. This outline has the following
characteristics.
Model-centered transformation architecture. Until now, use case information
extraction and interaction diagram generation have been described through a set of
rules that apply the techniques. The information source and the form that it takes
later on are not treated as models when specifying the deduction process. This
produces some inconveniences that affect the efficiency of the systems that
provide support to these techniques; this not only makes maintenance difficult, but
it also makes the code evolution and generation tasks more complex. Great interest
in model-driven approaches that are based on the automatic transformation of
models has recently emerged. In this software development paradigm, the models
and their transformations are specified at a high abstraction level, separating the
system structure and behavior from its implementation and supporting evolution,
refinement, and code generation (Kleppe, Warmer, & Bast, 2003). Following this
approach, metamorphosis proposes the automatic generation of a target model (the
interaction model) from a source model (the use case model). The model definition
is abstract at the metamodel level so that the transformation does not depend on the
technological aspects nor on a specific domain.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Using Linguistic Patterns to Model Interactions 33

Linguistic orientation. Metamorphosis uses natural language processing to

support information extraction from the text of a use case (Boyd, 1999).
Currently, natural language processing is a mature area of computer science that
provides techniques and tools to perform this task efficiently (Métais, 2002;
Mich, Franch, & Inverardi, 2004).
Based on patterns. Metamorphosis attempts to capture the transformation
knowledge by means of patterns (Gamma et al., 1992). These patterns are going
to describe how each sentence of a use case is transformed into interactions. In
metamorphosis, a pattern is a reusable and generic specification that can be
implemented using any programming language and integrated into several
automatic software production environments.
Role-driven. Metamorphosis provides special meaning to the modelling ele-
ments by means of role definition. The roles contribute to the recognition of these
elements at model-time and facilitate the understanding of the patterns (France,
Kim, Ghosh, & Song, 2004; Gildea & Jurafsky, 2002).
Flexible normalization. The normalization process requires use cases to be
written using only a previously known set of syntactic structures. Imposing such
a restriction facilitates the information extraction process and allows the
elimination of the potential ambiguities generated by the use of natural language
(Ben-Achour, Rolland, Maiden, & Souveyet, 1999; Berry & Kamsties, 2004;
Rolland & Ben-Achour, 1998). Nevertheless, the advantages achieved by
imposing this normalization on the language reduce the expressive capability of
the system specification. Therefore, establishing restrictions could only be
justified as a means to ensure the quality of the use cases, in terms of their
completeness and correctness. Furthermore, this quality could be ensured
through using other resources without overloading the modeller with this
responsibility. Metamorphosis proposes to make the normalization process of
use cases flexible by means of: (a) a tool guiding the modeller in the use case
editing process; or (b) automatically identifying text ambiguities (structural or
semantic) and resolving them (i.e., transforming it; marking it with information
to clarify its semantics; classifying doubtful text; etc.).
UML compliant. Metamorphosis uses UML because this language allows us to
specify models and transformations that can be comprehended and applied by
many modellers and tools. The UML semantics and syntax is currently a de-facto
standard due to its widespread use (OMG, 2003). Furthermore, the UML 2.0
version thoroughly describes the interaction concept taking into account the
necessary semantics and notation to represent both the SD and the MSC.
Interactions in the UML 2.0 version can be represented graphically using:
sequence diagrams (that synthesize the properties of the MSCs), communica-
tion diagrams, or interaction overview diagrams (OMG, 2003). For simplicity,
in this chapter, we use the generic terms sequence or interaction diagram to
refer to the graphic representation of the interactions.

Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
Exploring the Variety of Random
Documents with Different Content
 CHAPTER LV
When they were alone Bret explained his decision and the
heartbreaking time he had had arriving at it. He would not debate it
again. He permitted Sheila the consolation of feeling herself an
outcast, and she reveled in misery. But the first rehearsal was like a
bugle-call to a cavalry horse hitched to a milk-wagon.
She entered the Odeon Theater again by the back door and
bowed to the same old man, who smiled her in with bleary welcome.
And Pennock was at her post looking as untheatrical as ever. She
embraced Sheila and said, “It’s good to see you workin’ again.”
The next person she met was Mrs. Vining, looking as time-proof
as ever.
“What on earth are you doing here?” Sheila cried.
And Mrs. Vining sighed. “Oh, there’s an old catty mother-in-law in
the play, and Reben dragged me out of the Old Ladies’ Home to play
it.”
Sheila’s presence at the Odeon was due to the fact that when
Eldon asked Reben to release him so that he might play in “Clipped
Wings,” with Sheila as star and Bret Winfield as the angel, Reben
declined with violence.
When Eldon told him of the play he demanded the privilege of
producing it. He ridiculed Bret as a theatrical manager and easily
persuaded him to retire to his weighing-machines. Reben dug out
the yellowed contract with Sheila, had it freshly typed, and sent it to
her, and she signed it with all the woman’s terror at putting her
signature to a mortgage.
One matinée day, as Sheila left the stage door, she met Dulcie
coming in to make ready for the afternoon’s performance.
Dulcie clutched her with overacted enthusiasm and said: “Oh, my
dear, it’s so nice that you’re coming back on the stage, after all these
years. Too bad you can’t have your old theater, isn’t it? We’re
doomed to stay here forever, it seems. But—oh, my dear!—you
mustn’t work so hard. You look all worn out. Are you ill?”
 Sheila retreated in as good order as possible, breathing
resolutions to oust Dulcie from the star dressing-room and quench
her name in the electric lights. That vow sustained her through
many a weak hour.
But at times she was not sure of even that success. At times she
was sure of failure and the odious humiliation of returning to
Blithevale like a prodigal wife fed on husks of criticism.
Bret was called back to his factory by his business and by his
request. He did not want to impede Sheila in any way. He had gone
through rehearsals and try-outs with her once, and, as he said, once
was plenty.
Sheila wept at his desertion and called herself names. She wept
for her children and called herself worse names. She wept on Mrs.
Vining at various opportunities when she was not rehearsing.
At length the old lady’s patience gave out and she stormed, “I
warned you not to marry.”
“You warned me not to marry in the profession, and I didn’t.”
“Well,” sniffed Mrs. Vining, “I supposed you had sense enough of
your own not to marry outside of it.”
“But—”
“And now that you did, take your medicine. You’re crying because
you want to be with your man and your children. But when you had
them you cried just the same. All the women I know on the stage
and off, married and single, childless or not, are always crying about
something. Good Lord! it’s time women learned to get along without
tears. Men used to cry and faint, and they outgrew it. Women don’t
faint any more. Why can’t they quit crying? The whole kit and
caboodle of you make me sick.”
“Thank you!” said Sheila, and walked away. But she was mad
enough to rehearse her big scene more vigorously than ever.
Without a slip of memory she delivered her long tirade so fiercely
that the company and Vickery and Batterson broke into applause.
From the auditorium Reben shouted, “Bully!”
As Sheila walked aside, Mrs. Vining threw her arms around her
and called her an angel and proved that even she had not lost the
gift of tears.
 Bret was not without his own torments. The village people drove
him frantic with their questions and their rapturous horror and the
gossip they bandied about.
His mother, who hurried to the “rescue” of his home and his
“abandoned children,” strengthened him more by her bitterness
against Sheila than she could have done by any praise of her. A man
always discounts a woman’s criticism of another woman. It always
outrages his male sense of fairness and good sportsmanship.
Besides, Bret was driven by every reason of loyalty to defend his
wife. He told his mother and his neighbors that he would see her
oftener than a soldier or a sailor sees his wife. He would keep close
to her. His business would permit him to make occasional journeys
to her. Their summers would be honeymoons together.
He made good use of the argumentum ad feminam by telling his
mother how well the children would profit by their grandmother’s
wisdom, and he promised them the fascinating privilege of traveling
with their mother at times.
But it was not easy for Bret. He knew that many people would
laugh at him for a milksop; others would despise him for a
complacent assistant in his wife’s dishonor. At times the dread of this
gossip drove him almost mad.
He had his dark hours of jealous distrust, too, and the very
thought of Eldon filled him with dread. Eldon was gifted and
handsome, and congenial to Sheila, and a fellow-artist as well. And
his other self, the Iago self that every Othello has, whispered that
hateful word “propinquity” in his ear with vicious insinuation.
He gnashed his teeth against himself and groaned, “You fool,
you’ve thrown her into Eldon’s arms.”
His better self answered: “No, you have given her to the arms of
the world. Propinquity breeds hatred and jealousy and boredom and
emulation as often as it breeds love.”
He would have felt reassured if he had seen Sheila fighting Eldon
for points, for positions, and for lines.
There was one line in Eldon’s part that Sheila called the most
beautiful line in the play, a line about the husband’s dead mother.
Sheila first admired then coveted the line.
At last she openly asked for it. Eldon was furious and Vickery was
aghast.
“But, my dear Sheila,” he explained, “you couldn’t use that line.
Your mother is present in the cast.”
“Couldn’t we kill her off?” said Sheila.
“I like that!” cried Mrs. Vining, who was playing the part.
Sheila gave up the line, but with reluctance. But it was some time
before Eldon and Vickery regained their illusions concerning her.
And yet it was something more than selfish greed that made her
grasp at everything for the betterment of her rôle. It was like a
portrait she was painting and she wished for it every enhancement.
An architect who plans a cathedral is not blamed for wishing to raze
whole acres so that his building may command the scene. The
actor’s often berated avarice is no more ignoble, really. And the actor
who is indifferent or over-generous is like the careless artist in other
fields. He builds neither himself nor his work.
Mrs. Vining fought half a day against the loss of a line that
emphasized the meanness of her character. She wanted to be hated.
She played hateful rôles with such exquisite art that audiences loved
her while they loathed her.
So Sheila spared nothing and nobody to make the part she
played the greatest part was ever played. Least of all she spared
herself, her strength, her mind, her time. But she battened on work,
she was a glutton for punishment. She had her stage-manager
begging for a rest, and that is rare achievement.
And all the while she grew stronger, haler, heartier; she grew so
beautiful from needing to be beautiful that even Dulcie Ormerod,
passing her once more at the mail-box, gasped:
“My Gawd! but that hat is becoming. Tell me quick what’s the
address of your milliner.”
That was approbation indeed from Dulcie.
At length the dreadful dress-rehearsal was reached. The usual
unheard-of mishaps happened. Everybody was hopeless. The actors
parroted the old saying that “a bad dress-rehearsal means a good
first performance,” knowing that it proves true about half the time.
 The piece was tried first in Plainfield. The local audience was not
demonstrative. Eldon tried to comfort himself by saying that the play
was too big, too stunning, for them to understand.
The next night they played in Red Bank and were stunned with
applause in the first scene and increasing enthusiasm throughout.
But that proved nothing, and Jaffer, who was with the company,
remembered a famous failure that had been a triumph in Red Bank
and a disaster on Broadway.
The fear of that merciless Broadway gauntlet settled over the
company. Success meant everything to every member. It meant the
paying of bills, a warm home for the winter, a step upward for the
future. Even one of the stage-hands had a romance that required a
New York run.
 CHAPTER LVI
Some of the provincial cities said the play was disgustingly
immoral and the police ought to stop it. The accusation hurt. Was it
immoral? A certain clergy man said the play was a sermon; a certain
critic said it was vile. Which was true? It is not pleasant to be called
vile even though the epithet has been hurled at many of the noblest.
The bitter discussion it aroused wounded Vickery mortally. Eldon
told him that nothing was better for success than to arouse
discussion, and that the final proof of great art is its ability to make
a lot of people ferociously angry.
But Vickery would not be cheered up. He said that the bumps
were killing him.
“You see, I’m so lean and weak, I’ve got no shock-absorbers. I
can’t do anything but cough like a damned he-Camille.”
Sheila and Batterson and even Reben begged him to leave the
company and go back to town. But he was in a frenzy for perfection.
He was relentless with his own lines and scenes. He denounced
them rabidly. He tore out pages of manuscript from the prompt-copy,
and sat at the table writing new scenes while the rehearsals went
on. Between the acts he wrote new lines. He wrote in a terrible
hurry. He was in a terrible hurry.
But he was in a frenzy for perfection. He was relentless with the
actors. Every word, every silence, was important to him as a link in
his chain of gold.
Batterson and Reben and Sheila questioned many of his words,
phrases, and even whole scenes. Everybody had a more or less
respectful criticism, a more or less brilliant contribution, but Vickery
had had enough of this piecemeal microscopy.
“A play succeeds or falls by its big idea,” he said, “by its big
sweep, and nothing else matters. The greatest play in the world is
‘Hamlet,’ and it’s so full of faults that a whole library has been
written about it. But you can’t kill its big points. What difference
does it make how the shore-line runs if your ocean is an ocean? Let
me alone, I tell you. Do my play the best you can, then we’ll soon
know if the public wants it.
“You ruined one play for me, Mr. Reben, but you can’t monkey
with this one. I thought of all the objections you’ve made and a
hundred others when I was writing it. I liked it this way then, and I
knew as much then as I do now—only I was red-hot at the time, and
I’m not going to fool with it in cold blood.”
There were arguments and instances enough against him, and
Reben and Batterson showered him with stories of plays that had
been saved from disaster by collaboration. He answered with stories
of plays that had succeeded without it and plays that had crashed in
spite of it.
“It’s all a gamble,” he cried. “Let’s throw our coin on one number
and either make or lose. Anyway, my contract says you can’t alter a
line without my consent, and you’ll never get that. It’s my last play,
and it’s my own play, and they’ve got to take it or leave it just as I
write it.”
They yielded more in deference to his feelings than to his art.
At last the company turned to charge down upon New York. They
arrived at three o’clock on a Sunday morning.
As Sheila and Mrs. Vining rode through the streets to their hotel
they saw on all sides the work of the advertising men. On bill-boards
were big “stands” with Sheila’s name in letters as big as herself. On
smaller boards her full-length portrait smiled at her from “three
sheets.” In the windows were “half-sheets.” Even the garbage-cans
proclaimed her name.
Fame was a terrifying thing.
Sunday was given over to a prolonged dress-rehearsal beginning
at noon and lasting till four the next morning. At about three o’clock
in the afternoon Eugene Vickery in the midst of a wrangle over a
scene was overcome with his illness.
A doctor who was brought in haste picked him up and carried
him to a taxicab and sped with him to a hospital. The troupe was
staggered like a line of infantry in which the first shell drops. Then it
closed together and went on.
 The next day Sheila visited Eugene and never found a rôle so
hard to play as the character of Hope at the bedside of Despair.
The nurse would not let her stay long and forbade Vickery to
talk, but he managed to whisper, brokenly:
“Don’t worry about me. Don’t think about me. Work for yourself
and the play. That will be working for me. If it succeeds, it’s a kind
of a little immortality for me; if it fails—well, don’t worry, I won’t
mind—then. Go and rest now. I’ve no strength to give you, or I’d
make you as strong as a giant—you poor, brave, beautiful little
woman! God bless you! Good luck!”
 CHAPTER LVII
Eight o’clock and a section of Broadway is a throng of throngs, as
if all the world were prowling for pleasure. At this theater or that,
parts of the crowd turn in. Where many go there is success; but
there are sad doorways where few cabs draw up and few people
march to the lonely window; and that is a home of failure, though as
much work has been done and as much money deserved. Only, the
whim of the public is not for that place.
Eight o’clock and Sheila sits in her dressing-room in an ague of
dread, painting her face and wondering why she is here, a lone
woman fighting a mob for the sake of a dying man’s useless glory,
and for the ruin of a living man’s schedule of life. Why is she not
where Bret Winfield said a woman’s place was—at home?
She wonders about Bret. If she fails, if she succeeds, what does
it mean to him and her? She understands that he has left her alone
till now because he could not help her. But no flowers, no telegram,
nothing? She looks over the heap of telegrams—no, there is nothing
from him.
Then a note comes. He is there. Can he see her? Her heart leaps
with rapture, but she dares not see him before the play. She would
cry and mess her make-up, and she must enter with gaiety. She
sends Pennock with word begging him to come after the play is over
—“if he still wants to—if he’s not ashamed of me; tell him that.”
She thinks of him wincing as he is turned away from the stage
door. Then she banishes the thought of him, herself, everybody but
the character she is to play.
Outside the curtain is a throng eager to be entertained, willing to
pay a fortune for entertainment, but merciless to those who fail.
There is no active hostility in the audience—just the passive inertia
of a dull, dreary, anxious mob afraid of being bored and cheated of
an evening.
“Here are our hearts,” it says; “we are sick of our own lives. We
do not care what your troubles are or your good intentions. We have
left our homes to be made happy, or to be thrilled to that luxurious
sorrow for some one else that is the highest happiness. We have
come here at some expense and some inconvenience. We have a
hard day ahead of us to-morrow. It is too late to go elsewhere. You
have said you have a good show. Show us!”
Back of that glum curtain the actors, powdered, caparisoned,
painted, wait in the wings like clowns for the crack of the whip—and
yet also like soldiers about to receive the command to charge on
trenches where unknown forces lie hidden. No one can tell whether
they are to be hurled back in shame and confusion, or to sweep on
in uproarious triumph. Their courage, their art, will be the same. The
result will be history or oblivion, homage or ridicule.

It is an old story, an incessantly recurring story, a tragi-farce so

commonplace that authors and actors and managers and critics
make jokes of their failures and successes—afterward. But they are
not jokes at the time.
It was no joke for the husband who had intrusted Sheila to the
mercy of the public and the press, and who made one of the
audience, though he quivered with an anguish of fear as each line
was delivered, and an anguish of joy or woe as it scored or lapsed.
It was no joke to Eugene Vickery, lying in the quiet white room
with the light low and one stolid stranger in white to sentinel him. It
was hard not to be there where the lights were high, where the
throngs heard his pen and ink made flesh and blood. It was hard not
to know what the words he had put on paper sounded like to New
York—the Big Town of his people. He wanted to see and hear and
his soul would have run there if it could have lifted his body. But that
it could not do.
It could lift thousands of hands to applause and lift a thousand
voices to cry his name, but it could not lift his own hands or his own
voice.
The nurse, who did not understand playwrights, tried to keep
him quiet. She kept taking the sheet from his hands where they kept
tugging at its edge. She forbade him to talk. She refused to tell him
what time it was.
 But he would say, “Now the overture’s beginning,” and then,
later, “Now the curtain’s going up.” He tried to rise with it, but she
pressed him back. Later he reckoned that the first act was over, and
then that the second act was begun.
Then a telephoned message was brought to him that Mr. Reben
telephoned to say, “the first act got over great.”
That almost lifted him to his feet, but he fell back, sighing, “He’d
say it anyway, just to cheer me up.”
The same message or better came after the other acts. But he
would not believe, he dared not believe, till suddenly Sheila was
there in her costume of the last act. The divine light of good news
poured from her eyes. She had not waited to meet the people who
crowded back to congratulate her—“and they never crowd after a
failure,” she said.
She had not waited to change her costume lest she be too late
with her music. She had waited only for Bret to run to her and tell
her how wonderful she was, and to crush him as hard as she could
in her arms. Then she had haled him to the cab that was held in
readiness, and they had dashed for Vickery’s bed—his “throne,” she
called it.
Perhaps she exaggerated the excitement of the audience;
perhaps she drew a little on prophecy in quoting what the critics had
been overheard to say in praise of the drama—“epoch-making” was
the least word she quoted.
But she brought in with her a very blast of beauty and of rapture,
and she carried flowers that she would have flung across his bed if
she had not suddenly feared the look of them there.
As for Vickery, he felt the beauty and fragrance of the triumphal
red roses on the towering stems.
But he closed the great eyelids over the great eyes and inhaled
the sweeter, the ineffable aroma of success. It was so sweet that he
turned his face to the wall and sobbed.
Sheila tried to console him—console him for his triumph! She
said: “Why, ’Gene, ’Gene, the play is a sensation! The royalties will
be enormous. The notices will be glorious. You mustn’t be unhappy.”
 He put out a hand that tried to be soft, he made a sound that
tried to be a laugh, and he spoke in a sad rustle that tried to be a
voice:
“I’m not unhappy. I never was happy till now. The royalties won’t
be necessary where I’m going—just a penny to pay the ferryman.
The notices I’ll read over there—I suppose they get the papers over
there so that the obituary notices can be read—the first kind words
some of us ever get from this world.
“I owe it to you two that my play got on and succeeded.
Success! to write your heart’s religion and have it succeed with the
people—that’s worth living for—that’s worth dying for—”
His speech was frail, and broken with long pauses and with
paroxysms:
“I hope I haven’t ruined your lives for you two. But you weren’t
very happy when I came along, were you? Sheila was breaking your
heart, Bret, just because she couldn’t keep her own from breaking.
You were like a man chained to a dead woman. If you had gone on,
maybe you would have been less happy than you will be now. Look
at poor Dorothy. How long will she stand her unhappiness? My
royalties will go to her! They will make her independent of that—But
I’ve got no time to be bitter against anybody now.
“I hope you’ll be happy, you two. But happiness isn’t the thing to
work for. The thing to work for is work—to do all you can with what
you have. I’m a poor, weak, ramshackle sack of bones, but I’ve done
what I could—and a little more. J’ai fait mon possible. That’s all God
or man can ask. Go on and do your possible, Bret—you in your
factory—and Sheila in her factory. I can’t see why your chance for
happiness isn’t as good as anybody’s, if you’ll be patient with each
other and run home to each other when you can—and—and—now
I’ve got to run home, too.”
Then a deep peace soothed him, and them.
CURTAIN

THE END
 TRANSCRIBER NOTES
Mis-spelled words and printer errors have been fixed.
Inconsistency in hyphenation has been retained.
*** END OF THE PROJECT GUTENBERG EBOOK CLIPPED WINGS
***

Updated editions will replace the previous one—the old editions

will be renamed.

Creating the works from print editions not protected by U.S.

copyright law means that no one owns a United States
copyright in these works, so the Foundation (and you!) can copy
and distribute it in the United States without permission and
without paying copyright royalties. Special rules, set forth in the
General Terms of Use part of this license, apply to copying and
distributing Project Gutenberg™ electronic works to protect the
PROJECT GUTENBERG™ concept and trademark. Project
Gutenberg is a registered trademark, and may not be used if
you charge for an eBook, except by following the terms of the
trademark license, including paying royalties for use of the
Project Gutenberg trademark. If you do not charge anything for
copies of this eBook, complying with the trademark license is
very easy. You may use this eBook for nearly any purpose such
as creation of derivative works, reports, performances and
research. Project Gutenberg eBooks may be modified and
printed and given away—you may do practically ANYTHING in
the United States with eBooks not protected by U.S. copyright
law. Redistribution is subject to the trademark license, especially
commercial redistribution.

START: FULL LICENSE

THE FULL PROJECT GUTENBERG LICENSE
 PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK

To protect the Project Gutenberg™ mission of promoting the

free distribution of electronic works, by using or distributing this
work (or any other work associated in any way with the phrase
“Project Gutenberg”), you agree to comply with all the terms of
the Full Project Gutenberg™ License available with this file or
online at www.gutenberg.org/license.

Section 1. General Terms of Use and

Redistributing Project Gutenberg™
electronic works
1.A. By reading or using any part of this Project Gutenberg™
electronic work, you indicate that you have read, understand,
agree to and accept all the terms of this license and intellectual
property (trademark/copyright) agreement. If you do not agree
to abide by all the terms of this agreement, you must cease
using and return or destroy all copies of Project Gutenberg™
electronic works in your possession. If you paid a fee for
obtaining a copy of or access to a Project Gutenberg™
electronic work and you do not agree to be bound by the terms
of this agreement, you may obtain a refund from the person or
entity to whom you paid the fee as set forth in paragraph 1.E.8.

1.B. “Project Gutenberg” is a registered trademark. It may only

be used on or associated in any way with an electronic work by
people who agree to be bound by the terms of this agreement.
There are a few things that you can do with most Project
Gutenberg™ electronic works even without complying with the
full terms of this agreement. See paragraph 1.C below. There
are a lot of things you can do with Project Gutenberg™
electronic works if you follow the terms of this agreement and
help preserve free future access to Project Gutenberg™
electronic works. See paragraph 1.E below.
1.C. The Project Gutenberg Literary Archive Foundation (“the
Foundation” or PGLAF), owns a compilation copyright in the
collection of Project Gutenberg™ electronic works. Nearly all the
individual works in the collection are in the public domain in the
United States. If an individual work is unprotected by copyright
law in the United States and you are located in the United
States, we do not claim a right to prevent you from copying,
distributing, performing, displaying or creating derivative works
based on the work as long as all references to Project
Gutenberg are removed. Of course, we hope that you will
support the Project Gutenberg™ mission of promoting free
access to electronic works by freely sharing Project Gutenberg™
works in compliance with the terms of this agreement for
keeping the Project Gutenberg™ name associated with the
work. You can easily comply with the terms of this agreement
by keeping this work in the same format with its attached full
Project Gutenberg™ License when you share it without charge
with others.

1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside
the United States, check the laws of your country in addition to
the terms of this agreement before downloading, copying,
displaying, performing, distributing or creating derivative works
based on this work or any other Project Gutenberg™ work. The
Foundation makes no representations concerning the copyright
status of any work in any country other than the United States.

1.E. Unless you have removed all references to Project

Gutenberg:

1.E.1. The following sentence, with active links to, or other

immediate access to, the full Project Gutenberg™ License must
appear prominently whenever any copy of a Project
Gutenberg™ work (any work on which the phrase “Project
Gutenberg” appears, or with which the phrase “Project
Gutenberg” is associated) is accessed, displayed, performed,
viewed, copied or distributed:

This eBook is for the use of anyone anywhere in the United

States and most other parts of the world at no cost and
with almost no restrictions whatsoever. You may copy it,
give it away or re-use it under the terms of the Project
Gutenberg License included with this eBook or online at
www.gutenberg.org. If you are not located in the United
States, you will have to check the laws of the country
where you are located before using this eBook.

1.E.2. If an individual Project Gutenberg™ electronic work is

derived from texts not protected by U.S. copyright law (does not
contain a notice indicating that it is posted with permission of
the copyright holder), the work can be copied and distributed to
anyone in the United States without paying any fees or charges.
If you are redistributing or providing access to a work with the
phrase “Project Gutenberg” associated with or appearing on the
work, you must comply either with the requirements of
paragraphs 1.E.1 through 1.E.7 or obtain permission for the use
of the work and the Project Gutenberg™ trademark as set forth
in paragraphs 1.E.8 or 1.E.9.

1.E.3. If an individual Project Gutenberg™ electronic work is

posted with the permission of the copyright holder, your use and
distribution must comply with both paragraphs 1.E.1 through
1.E.7 and any additional terms imposed by the copyright holder.
Additional terms will be linked to the Project Gutenberg™
License for all works posted with the permission of the copyright
holder found at the beginning of this work.

1.E.4. Do not unlink or detach or remove the full Project

Gutenberg™ License terms from this work, or any files
 containing a part of this work or any other work associated with
Project Gutenberg™.

1.E.5. Do not copy, display, perform, distribute or redistribute

this electronic work, or any part of this electronic work, without
prominently displaying the sentence set forth in paragraph 1.E.1
with active links or immediate access to the full terms of the
Project Gutenberg™ License.

1.E.6. You may convert to and distribute this work in any binary,
compressed, marked up, nonproprietary or proprietary form,
including any word processing or hypertext form. However, if
you provide access to or distribute copies of a Project
Gutenberg™ work in a format other than “Plain Vanilla ASCII” or
other format used in the official version posted on the official
Project Gutenberg™ website (www.gutenberg.org), you must,
at no additional cost, fee or expense to the user, provide a copy,
a means of exporting a copy, or a means of obtaining a copy
upon request, of the work in its original “Plain Vanilla ASCII” or
other form. Any alternate format must include the full Project
Gutenberg™ License as specified in paragraph 1.E.1.

1.E.7. Do not charge a fee for access to, viewing, displaying,

performing, copying or distributing any Project Gutenberg™
works unless you comply with paragraph 1.E.8 or 1.E.9.

1.E.8. You may charge a reasonable fee for copies of or

providing access to or distributing Project Gutenberg™
electronic works provided that:

• You pay a royalty fee of 20% of the gross profits you derive
from the use of Project Gutenberg™ works calculated using the
method you already use to calculate your applicable taxes. The
fee is owed to the owner of the Project Gutenberg™ trademark,
but he has agreed to donate royalties under this paragraph to
the Project Gutenberg Literary Archive Foundation. Royalty
 payments must be paid within 60 days following each date on
which you prepare (or are legally required to prepare) your
periodic tax returns. Royalty payments should be clearly marked
as such and sent to the Project Gutenberg Literary Archive
Foundation at the address specified in Section 4, “Information
about donations to the Project Gutenberg Literary Archive
Foundation.”

• You provide a full refund of any money paid by a user who

notifies you in writing (or by e-mail) within 30 days of receipt
that s/he does not agree to the terms of the full Project
Gutenberg™ License. You must require such a user to return or
destroy all copies of the works possessed in a physical medium
and discontinue all use of and all access to other copies of
Project Gutenberg™ works.

• You provide, in accordance with paragraph 1.F.3, a full refund of

any money paid for a work or a replacement copy, if a defect in
the electronic work is discovered and reported to you within 90
days of receipt of the work.

• You comply with all other terms of this agreement for free
distribution of Project Gutenberg™ works.

1.E.9. If you wish to charge a fee or distribute a Project

Gutenberg™ electronic work or group of works on different
terms than are set forth in this agreement, you must obtain
permission in writing from the Project Gutenberg Literary
Archive Foundation, the manager of the Project Gutenberg™
trademark. Contact the Foundation as set forth in Section 3
below.

1.F.

1.F.1. Project Gutenberg volunteers and employees expend

considerable effort to identify, do copyright research on,
transcribe and proofread works not protected by U.S. copyright
law in creating the Project Gutenberg™ collection. Despite these
efforts, Project Gutenberg™ electronic works, and the medium
on which they may be stored, may contain “Defects,” such as,
but not limited to, incomplete, inaccurate or corrupt data,
transcription errors, a copyright or other intellectual property
infringement, a defective or damaged disk or other medium, a
computer virus, or computer codes that damage or cannot be
read by your equipment.

1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except

for the “Right of Replacement or Refund” described in
paragraph 1.F.3, the Project Gutenberg Literary Archive
Foundation, the owner of the Project Gutenberg™ trademark,
and any other party distributing a Project Gutenberg™ electronic
work under this agreement, disclaim all liability to you for
damages, costs and expenses, including legal fees. YOU AGREE
THAT YOU HAVE NO REMEDIES FOR NEGLIGENCE, STRICT
LIABILITY, BREACH OF WARRANTY OR BREACH OF CONTRACT
EXCEPT THOSE PROVIDED IN PARAGRAPH 1.F.3. YOU AGREE
THAT THE FOUNDATION, THE TRADEMARK OWNER, AND ANY
DISTRIBUTOR UNDER THIS AGREEMENT WILL NOT BE LIABLE
TO YOU FOR ACTUAL, DIRECT, INDIRECT, CONSEQUENTIAL,
PUNITIVE OR INCIDENTAL DAMAGES EVEN IF YOU GIVE
NOTICE OF THE POSSIBILITY OF SUCH DAMAGE.

1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you

discover a defect in this electronic work within 90 days of
receiving it, you can receive a refund of the money (if any) you
paid for it by sending a written explanation to the person you
received the work from. If you received the work on a physical
medium, you must return the medium with your written
explanation. The person or entity that provided you with the
defective work may elect to provide a replacement copy in lieu
of a refund. If you received the work electronically, the person
or entity providing it to you may choose to give you a second
opportunity to receive the work electronically in lieu of a refund.
If the second copy is also defective, you may demand a refund
in writing without further opportunities to fix the problem.

1.F.4. Except for the limited right of replacement or refund set

forth in paragraph 1.F.3, this work is provided to you ‘AS-IS’,
WITH NO OTHER WARRANTIES OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR ANY PURPOSE.

1.F.5. Some states do not allow disclaimers of certain implied

warranties or the exclusion or limitation of certain types of
damages. If any disclaimer or limitation set forth in this
agreement violates the law of the state applicable to this
agreement, the agreement shall be interpreted to make the
maximum disclaimer or limitation permitted by the applicable
state law. The invalidity or unenforceability of any provision of
this agreement shall not void the remaining provisions.

1.F.6. INDEMNITY - You agree to indemnify and hold the

Foundation, the trademark owner, any agent or employee of the
Foundation, anyone providing copies of Project Gutenberg™
electronic works in accordance with this agreement, and any
volunteers associated with the production, promotion and
distribution of Project Gutenberg™ electronic works, harmless
from all liability, costs and expenses, including legal fees, that
arise directly or indirectly from any of the following which you
do or cause to occur: (a) distribution of this or any Project
Gutenberg™ work, (b) alteration, modification, or additions or
deletions to any Project Gutenberg™ work, and (c) any Defect
you cause.

Section 2. Information about the Mission

of Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new
computers. It exists because of the efforts of hundreds of
volunteers and donations from people in all walks of life.

Volunteers and financial support to provide volunteers with the

assistance they need are critical to reaching Project
Gutenberg™’s goals and ensuring that the Project Gutenberg™
collection will remain freely available for generations to come. In
2001, the Project Gutenberg Literary Archive Foundation was
created to provide a secure and permanent future for Project
Gutenberg™ and future generations. To learn more about the
Project Gutenberg Literary Archive Foundation and how your
efforts and donations can help, see Sections 3 and 4 and the
Foundation information page at www.gutenberg.org.

Section 3. Information about the Project

Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-
profit 501(c)(3) educational corporation organized under the
laws of the state of Mississippi and granted tax exempt status
by the Internal Revenue Service. The Foundation’s EIN or
federal tax identification number is 64-6221541. Contributions
to the Project Gutenberg Literary Archive Foundation are tax
deductible to the full extent permitted by U.S. federal laws and
your state’s laws.

The Foundation’s business office is located at 809 North 1500

West, Salt Lake City, UT 84116, (801) 596-1887. Email contact
links and up to date contact information can be found at the
Foundation’s website and official page at
www.gutenberg.org/contact
 Section 4. Information about Donations to
the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission
of increasing the number of public domain and licensed works
that can be freely distributed in machine-readable form
accessible by the widest array of equipment including outdated
equipment. Many small donations ($1 to $5,000) are particularly
important to maintaining tax exempt status with the IRS.

The Foundation is committed to complying with the laws

regulating charities and charitable donations in all 50 states of
the United States. Compliance requirements are not uniform
and it takes a considerable effort, much paperwork and many
fees to meet and keep up with these requirements. We do not
solicit donations in locations where we have not received written
confirmation of compliance. To SEND DONATIONS or determine
the status of compliance for any particular state visit
www.gutenberg.org/donate.

While we cannot and do not solicit contributions from states

where we have not met the solicitation requirements, we know
of no prohibition against accepting unsolicited donations from
donors in such states who approach us with offers to donate.

International donations are gratefully accepted, but we cannot

make any statements concerning tax treatment of donations
received from outside the United States. U.S. laws alone swamp
our small staff.

Please check the Project Gutenberg web pages for current

donation methods and addresses. Donations are accepted in a
number of other ways including checks, online payments and
credit card donations. To donate, please visit:
www.gutenberg.org/donate.

Section 5. General Information About

Project Gutenberg™ electronic works
Professor Michael S. Hart was the originator of the Project
Gutenberg™ concept of a library of electronic works that could
be freely shared with anyone. For forty years, he produced and
distributed Project Gutenberg™ eBooks with only a loose
network of volunteer support.

Project Gutenberg™ eBooks are often created from several

printed editions, all of which are confirmed as not protected by
copyright in the U.S. unless a copyright notice is included. Thus,
we do not necessarily keep eBooks in compliance with any
particular paper edition.

Most people start at our website which has the main PG search
facility: www.gutenberg.org.

This website includes information about Project Gutenberg™,

including how to make donations to the Project Gutenberg
Literary Archive Foundation, how to help produce our new
eBooks, and how to subscribe to our email newsletter to hear
about new eBooks.