Advances In Uml And Xmlbased Software Evolution Illustrated Edition Hongji Yang

Advances In Uml And Xmlbased Software Evolution
Illustrated Edition Hongji Yang download
https://ebookbell.com/product/advances-in-uml-and-xmlbased-
software-evolution-illustrated-edition-hongji-yang-984440
Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.
Advances In Conceptual Modeling Theory And Practice Er 2006 Workshops
Bpuml Comogis Coss Ecdm Ois Qois Semwat Tucson Az Usa November 69 2006
Proceedings 1st Edition Dirk Draheim
https://ebookbell.com/product/advances-in-conceptual-modeling-theory-
and-practice-er-2006-workshops-bpuml-comogis-coss-ecdm-ois-qois-
semwat-tucson-az-usa-november-69-2006-proceedings-1st-edition-dirk-
draheim-4239750
Advances In Conceptual Modeling Foundations And Applications Er 2007
Workshops Cmlsa Fpuml Onisw Qois Rigimsecogis Auckland New Zealand
November 59 2007 Proceedings 1st Edition Yiping Phoebe Chen
https://ebookbell.com/product/advances-in-conceptual-modeling-
foundations-and-applications-er-2007-workshops-cmlsa-fpuml-onisw-qois-
rigimsecogis-auckland-new-zealand-november-59-2007-proceedings-1st-
edition-yiping-phoebe-chen-4268394
Advances In Conceptual Modeling Challenges And Opportunities Er 2008
Workshops Cmlsa Ecdm Fpuml M2as Rigim Secogis Wism Barcelona Spain
October 2023 2008 Proceedings 1st Edition Yiping Phoebe Chen
challenges-and-opportunities-er-2008-workshops-cmlsa-ecdm-fpuml-m2as-
rigim-secogis-wism-barcelona-spain-october-2023-2008-proceedings-1st-
edition-yiping-phoebe-chen-2039226
Advances In Conceptual Modeling Applications And Challenges Er 2010
Workshops Acml Cmlsa Cms Deer Fpuml Secogis Wism Vancouver Bc
Applications Incl Internet Web And Hci 1st Edition Juan Trujillo
applications-and-challenges-er-2010-workshops-acml-cmlsa-cms-deer-
fpuml-secogis-wism-vancouver-bc-applications-incl-internet-web-and-
hci-1st-edition-juan-trujillo-2537320

Advances In Conceptual Modeling Recent Developments And New Directions
Er 2011 Workshops Fpuml Morebi Ontocom Secogis Variabilityer Wism
Brussels Belgium October 31 November 3 2011 Proceedings 1st Edition
Flavius Frasincar
https://ebookbell.com/product/advances-in-conceptual-modeling-recent-
developments-and-new-directions-er-2011-workshops-fpuml-morebi-
ontocom-secogis-variabilityer-wism-brussels-belgium-
october-31-november-3-2011-proceedings-1st-edition-flavius-
frasincar-2455750
Real Time Uml Advances In The Uml For Realtime Systems 2nd Edition
Douglass
https://ebookbell.com/product/real-time-uml-advances-in-the-uml-for-
realtime-systems-2nd-edition-douglass-22122990
Advances In Conceptual Modeling Challenging Perspectives Er 2009
Workshops Comol Ethecom Fpuml Mostonisw Qois Rigim Secogis Gramado
Brazil November 912 2009 Proceedings 1st Edition Stefan Jablonski
challenging-perspectives-er-2009-workshops-comol-ethecom-fpuml-
mostonisw-qois-rigim-secogis-gramado-brazil-
november-912-2009-proceedings-1st-edition-stefan-jablonski-2534662
Advances In Conceptual Modeling Challenging Perspectives Er 2009
Workshops Comol Ethecom Fpuml Mostonisw Qois Rigim Secogis Gramado
Brazil November 912 2009 Proceedings 1st Edition Stefan Jablonski
challenging-perspectives-er-2009-workshops-comol-ethecom-fpuml-
mostonisw-qois-rigim-secogis-gramado-brazil-
november-912-2009-proceedings-1st-edition-stefan-jablonski-4140248
Advances In Geology And Resources Exploration Ahmad Safuan Bin A
Rashid
https://ebookbell.com/product/advances-in-geology-and-resources-
exploration-ahmad-safuan-bin-a-rashid-44888202

Advances in
UML and XML-Based
Software Evolution
HongjiYang
DeMontfortUniversity,UK
Hershey • London • Melbourne • Singapore
IDEA GROUP PUBLISHING
TEAM LinG

Acquisitions Editor: Renée Davies
Development Editor: Kristin Roth
Senior Managing Editor: Amanda Appicello
Managing Editor: Jennifer Neidig
Copy Editor: Amanda O’Brien
Typesetter: Cindy Consonery
Cover Design: Lisa Tosheff
Printed at: Integrated Book Technology
Published in the United States of America by
Idea Group Publishing (an imprint of Idea Group Inc.)
701 E. Chocolate Avenue, Suite 200
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 3313
Web site: http://www.eurospan.co.uk
Copyright © 2005 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
Advances in UML and XML-based software evolution / Hongji Yang, editor.
p. cm.
Summary: "Reports on the recent advances in UML and XML based software evolution in terms of a
wider range of techniques and applications"--Provided by publisher.
Includes bibliographical references and index.
ISBN 1-59140-621-8 (hardcover) -- ISBN 1-59140-622-6 (softcover) -- ISBN 1-59140-623-4
(ebook)
1. Computer software--Development--History. 2. UML (Computer science) 3. XML (Document
markup language) I. Yang, Hongji.
QA76.76.D47A378 2005
006.7'4--dc22
2005005919
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.
TEAM LinG

Advances in UML
and XML-Based
Software Evolution
Table of Contents
Preface .......................................................................................................................... vi
Hongji Yang, De Montfort University, England
ChapterI.
DesignRecoveryofWebApplicationTransactions ......................................................1
Scott Tilley, Florida Institute of Technology, USA
Damiano Distante, University of Lecce, Italy
Shihong Huang, Florida Atlantic University, USA
ChapterII.
UsingaGraphTransformationSystemtoImprovetheQualityCharacteristicsof
UML-RTSpecifications............................................................................................... 20
Lars Grunske, University of Potsdam, Germany
ChapterIII.
VersionControlofSoftwareModels........................................................................... 47
Marcus Alanen, Åbo Akademi University, Finland
Ivan Porres, Åbo Akademi University, Finland
ChapterIV.
SupportforCollaborativeComponent-BasedSoftwareEngineering ......................... 71
Cornelia Boldyreff, University of Lincoln, UK
David Nutter, University of Lincoln, UK
Stephen Rank, University of Lincoln, UK
Phyo Kyaw, University of Durham, UK
Janet Lavery, University of Durham, UK
ChapterV.
MigrationofPersistentObjectModelsUsingXMI .................................................... 92
Rainer Frömming, 4Soft GmbH, Germany
Andreas Rausch, Technische Universität Kaiserslautern, Germany
TEAM LinG

ChapterVI.
PRAISE:ASoftwareDevelopmentEnvironmenttoSupportSoftwareEvolution ..... 105
William C. Chu, Tunghai University, Taiwan
Chih-Hung Chang, Hsiuping Institute of Technology, Taiwan
Chih-Wei Lu, Hsiuping Institute of Technology, Taiwan
YI-Chun Peng, Tunghai University, Taiwan
Don-Lin Yang, Feng Chia University, Taiwan
ChapterVII.
DevelopingRequirementsUsingUseCaseModelingandtheVolereTemplate:
EstablishingaBaselineforEvolution ....................................................................... 141
Paul Crowther, Sheffield Hallam University, UK
ChapterVIII.
FormalizingandAnalyzingUMLUseCaseViewUsingHierarchicalPredicate
TransitionNets ......................................................................................................... 154
Xudong He, Florida International University, USA
ChapterIX.
FormalSpecificationofSoftwareModelEvolutionUsingContracts ........................ 184
Claudia Pons, Universidad Nacional de La Plata, Argentina
Gabriel Baum, Universidad Nacional de La Plata, Argentina
ChapterX.
VisualisingCOBOLLegacySystemswithUML:AnExperimentalReport ............ 209
Steve McRobb, De Montfort University, UK
Rich Millham, De Montfort University, UK
Jianjun Pu, De Montfort University, UK
Hongji Yang, De Montfort University, UK
ChapterXI.
XML-BasedAnalysisofUMLModelsforCriticalSystemsDevelopment ............... 257
Jan Jürjens, TU München, Germany
Pasha Shabalin, TU München, Germany
ChapterXII.
AugmentingUMLtoSupporttheDesignandEvolutionofUserInterfaces ............. 275
Chris Scogings, Massey University, New Zealand
Chris Phillips, Massey University, New Zealand
ChapterXIII.
AReuseDefinition,Assessment,andAnalysisFrameworkforUML ..................... 286
Donald Needham, United States Naval Academy, USA
Rodrigo Caballero, United Technologies Research Center, USA
Steven Demurjian, The University of Connecticut, USA
Felix Eickhoff, The University of Connecticut, USA
Yi Zhang, The University of Connecticut, USA
TEAM LinG

ChapterXIV.
Complexity-BasedEvaluationoftheEvolutionofXMLandUMLSystems............... 308
Ana Isabel Cardoso, University of Madeira, DME, Portugal
Peter Kokol, University of Maribor, FERI, Slovenia
Mitja Lenic, University of Maribor, FERI, Slovenia
Rui Gustavo Crespo, Technical University of Lisbon, DEEC, Portugal
ChapterXV.
VariabilityExpressionwithintheContextofUML:IssuesandComparisons ......... 322
Patrick Tessier, CEA/List Saclay, France
Sébastien Gérard, CEA/List Saclay, France
François Terrier, CEA/List Saclay, France
Jean-Marc Geib, Université des Sciences et Technologies de Lille, France
AbouttheAuthors ..................................................................................................... 350
Index ........................................................................................................................ 360
TEAM LinG

Preface
vi
This book continues to provide a forum, which a recent book, Software Evolution with
UML and XML, started, where expert insights are presented on the subject.
In that book, initial efforts were made to link together three current phenomena: soft-
ware evolution, UML, and XML. In this book, focus will be on the practical side of
linking them, that is, how UML and XML and their related methods/tools can assist
software evolution in practice.
Considering that nowadays software starts evolving before it is delivered, an apparent
feature for software evolution is that it happens over all stages and over all aspects.
Therefore, all possible techniques should be explored. This book explores techniques
based on UML/XML and a combination of them with other techniques (i.e., over all
techniques from theory to tools).
Software evolution happens at all stages. Chapters in this book describe that software
evolution issues present at stages of software architecturing, modeling/specifying,
assessing, coding, validating, design recovering, program understanding, and reusing.
Software evolution happens in all aspects. Chapters in this book illustrate that soft-
ware evolution issues are involved in Web application, embedded system, software
repository, component-based development, object model, development environment,
software metrics, UML use case diagram, system model, Legacy system, safety critical
system, user interface, software reuse, evolution management, and variability model-
ing.
Software evolution needs to be facilitated with all possible techniques. Chapters in
this book demonstrate techniques, such as formal methods, program transformation,
empirical study, tool development, standardisation, visualisation, to control system
changes to meet organisational and business objectives in a cost-effective way.
On the journey of the grand challenge posed by software evolution, the journey that
we have to make, the contributory authors of this book have already made further
advances.
TEAM LinG

Organisation of the Book
The book is organised into 15 chapters and a brief description of each chapter is as
follows.
Chapter I, Design Recovery of Web Application Transactions, is by Scott Tilley, Damiano
Distante, and Shihong Huang. Modern Web sites provide applications that are increas-
ingly built to support the execution of business processes. In such a transaction-
oriented Web site, poor transaction design may result in a system with unpredictable
workflow and a lower-quality user experience. This chapter presents an example of the
recovery of the “as-is” design model of a Web application transaction. The recovered
design is modeled using extensions to the transaction design portion of the UML-
based Ubiquitous Web Applications (UWA) framework. Recovery facilitates future
evolution of the Web site.
Chapter II, Using a Graph Transformation System to Improve the Quality Characteris-
tics of UML-RT Specifications, is by Lars Grunske. Architectural transformations are an
appropriate technique for the development and improvement of architectural specifica-
tions. This chapter presents the concept of graph-based architecture evolution and
how this concept can be applied to improve the quality characteristics of a software
system, where the UML-RT used as an architectural specification language is mapped
to a hypergraph-based datastructure, so that transformation operators can be specified
as hypergraph transformation rules.
Chapter III, Version Control of Software Models, is by Marcus Alanen and Ivan Porres.
Through reviewing main concepts and algorithms behind a software repository with
version control capabilities for UML and other MOF-based models, this chapter dis-
cusses why source code- and XML-based repositories cannot be used to manage
models and present alternative solutions that take into account specific details of MOF
languages.
Chapter IV, Support for Collaborative Component-Based Software Engineering, is by
Cornelia Boldyreff, David Nutter, Stephen Rank, Phyo Kyaw, and Janet Lavery. Col-
laborative system composition during design has been poorly supported by traditional
CASE tools and almost exclusively focused on static composition. This chapter dis-
cusses the collaborative determination, elaboration, and evolution of design spaces
that describe both static and dynamic compositions of software components from
sources such as component libraries, software service directories, and reuse reposito-
ries. It also discusses the provision of cross-project global views of large software
collections and historical views of individual artefacts within a collection.
Chapter V, Migration of Persistent Object Models Using XMI, is by Rainer Frömming
and Andreas Rausch. Change is a constant reality of software development. With ever-
changing customer requirements, modifications to the object model are required during
software development as well as after product distribution. This chapter presents the
conceptualisation and implementation of a tool for the automated migration of persis-
tent object models. The migration is controlled by an XMI-based description of the
difference between the old and the new object model.
Chapter VI, PRAISE: A Software Development Environment to Support Software Evo-
lution, is by Chih-Hung Chang, William C. Chu, Chih-Wei Lu, YI-Chun Peng, and Don-
vii
TEAM LinG

Lin Yang. This chapter first reviews current activities and studies in software stan-
dards, processes, CASE toolsets, and environments, and then proposes a process and
an environment for evolution-oriented software development, known as PRocess and
Agent-based Integrated Software development Environment (PRAISE). PRAISE uses
an XML-based mechanism to unify various software paradigms, aiming to integrate
processes, roles, toolsets, and work products to make software development more
efficient.
Chapter VII, Developing Requirements Using Use Case Modeling and the Volere Tem-
plate: Establishing a Baseline for Evolution, is by Paul Crowther. The development of
a quality software product depends on a complete, consistent, and detailed require-
ment specification but the specification will evolve as the requirements and the envi-
ronment change. This chapter provides a method of establishing the baseline in terms
of the requirements of a system from which evolution metrics can be effectively ap-
plied. UML provides a series of models that can be used to develop a specification
which will provide the basis of the baseline system.
Chapter VIII, Formalizing and Analyzing UML Use Case View Using Hierarchical
Predicate Transition Nets, is by Xudong He. UML use case diagrams are used during
requirements analysis to define a use case view that constitutes a system’s functional
model. Each use case describes a system’s functionality from a user’s perspective, but
these use case descriptions are often informal, which are error-prone and cannot be
formally analysed to detect problems in user requirements or errors introduced in sys-
tem functional model. This chapter presents an approach to formally translate a use
case view into a formal model in hierarchical predicate transition nets that support
formal analysis.
Chapter IX, Formal Specification of Software Model Evolution Using Contracts, is by
Claudia Pons and Gabriel Baum. During the object-oriented software development pro-
cess, a variety of models of the system is built, but these models may semantically
overlap. This chapter presents a classification of relationships between models along
three different dimensions, proposing a formal description of them in terms of math-
ematical contracts.
Chapter X, Visualising COBOL Legacy Systems with UML: An Experimental Report, is
by Steve McRobb, Richard Millham, Jianjun Pu, and Hongji Yang. This chapter pre-
sents a report of an experimental approach that uses WSL as an intermediate language
for the visualisation of COBOL legacy systems in UML. Visualisation will help a soft-
ware maintainer who must be able to understand the business processes being mod-
eled by the system along with the system’s functionality, structure, events, and inter-
actions with external entities. Key UML techniques are identified that can be used for
visualisation. The chapter concludes by demonstrating how this approach can be used
to build a software tool that automates the visualisation task.
Chapter XI, XML-Based Analysis of UML Models for Critical Systems Development, is
by Jan Jürjens and Pasha Shabalin. High quality development of critical systems poses
serious challenges. Formal methods have not yet been used in industry as they were
originally hoped. This chapter proposes to use the Unified Modeling Language (UML)
as a notation together with a formally based tool-support for critical systems develop-
ment. The chapter extends the UML notation with new constructs for describing criti-
viii
TEAM LinG

cality requirements and relevant system properties, and introduces their formalisation
in the context of the UML executable semantics.
Chapter XII, Augmenting UML to Support the Design and Evolution of User Inter-
faces, is by Chris Scogings and Chris Phillips. The primary focus in UML has been on
support for the design and implementation of the software comprising the underlying
system. Very little support is provided for the design or evolution of the user interface.
This chapter first reviews UML and its support for user interface modeling, then de-
scribes Lean Cuisine+, a notation capable of modeling both dialogue structure and
high-level user tasks. A case study shows that Lean Cuisine+ can be used to augment
UML and provide the user interface support.
Chapter XIII, A Reuse Definition, Assessment, and Analysis Framework for UML, is by
Donald Needham, Rodrigo Caballero, Steven Demurjian, Felix Eickhoff, and Yi Zhang.
This chapter examines a formal framework for reusability assessment of development-
time components and classes via metrics, refactoring guidelines, and algorithms. It
argues that software engineers seeking to improve design reusability stand to benefit
from tools that precisely measure the potential and actual reuse of software artefacts to
achieve domain-specific reuse for an organisation’s current and future products. The
authors consider the reuse definition, assessment, and analysis of a UML design prior
to the existence of source code, and include dependency tracking for use case and
class diagrams in support of reusability analysis and refactoring for UML.
Chapter XIV, Complexity-Based Evaluation of the Evolution of XML and UML Sys-
tems, is by Ana Isabel Cardoso, Peter Kokol, Mitja Lenic, and Rui Gustavo Crespo. This
chapter analyses current problems in the management of software evolution and ar-
gues the need to use the Chaos Theory to model software systems. Several correlation
metrics are described, and the authors conclude the long-range correlation can be the
most promising metrics. An industrial test case is used to illustrate that the behaviours
of software evolution are represented in the Verhulst model.
Chapter XV, Variability Expression within the Context of UML: Issues and Compari-
sons, is by Patrick Tessier, Sébastien Gérard, François Terrier, and Jean-Marc Geib.
Time-to-market is one severe constraint imposed on today’s software engineers. This
chapter presents a product line paradigm as an effective solution for managing both the
variability of products and their evolutions. The product line approach calls for design-
ing a generic and parameterised model that specifies a family of products. It is then
possible to instantiate a member of that family by specialising the “parent” model or
“framework,” where designers explicitly model variability and commonality points among
applications.
ix
TEAM LinG

x
Acknowledgments
Sincerely, I would like to thank all the people who have helped with the publication of
this book.
First, I would like to acknowledge the authors for their academic insights and the
patience to go through the whole proposing-writing-revising-finalising process to get
their chapters ready, and also for serving as reviewers to provide constructive and
comprehensive reviews for chapters written by other authors.
Special thanks go to the publishing team at Idea Group Inc.; in particular, to Mehdi
Khosrow-Pour whose support encouraged me to finish this continuation book in the
area of software evolution with UML and XML which provides me a wonderful oppor-
tunity to work with more leading scholars in the world; to Jan Travers for her continu-
ous support in logistics of the project; to Michele Rossi and Amanda Appicello for
copyediting and typesetting the book; and to Megan Kurtz for designing the one-page
promotion brochure.
Finally, I would like to thank my wife, Xiaodong, and my son, Tianxiu, for their support
throughout this project.
Hongji Yang, PhD
Loughborough, UK
January 2005
TEAM LinG

Design Recovery of Web Application Transactions 1
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
Chapter I
Design Recovery of
WebApplication
Transactions
Scott Tilley, Florida Institute of Technology, USA
Damiano Distante, University of Lecce, Italy
Shihong Huang, Florida Atlantic University, USA
Abstract
Modern Web sites provide applications that are increasingly built to support the
execution of business processes. In such a transaction-oriented Web site, the user
executes a series of activities in order to carry out a specific task (e.g., purchase an
airplane ticket). The manner in which the activities can be executed is a consequence
of the transaction design. Unfortunately, many Web sites are constructed without
proper attention to transaction design. The result is a system with unpredictable
workflow and a lower quality user experience. This chapter presents an example of the
recovery of the “as-is” design model of a Web application transaction. The recovery
procedure is prescriptive, suitable for implementation by a human subject-matter
expert, possibly aided by reverse engineering technology. The recovered design is
modeled using extensions to the transaction design portion of the UML-based Ubiquitous
Web Applications (UWA) framework. Recovery facilitates future evolution of the Web
site by making the transaction design explicit, which in turn enables engineers to make
informed decisions about possible changes to the application. Design recovery of a
commercial airline’s Web site is used to illustrate the process.
TEAM LinG

2 Tilley, Distante and Huang
Introduction
As with other kinds of software systems, Web sites undergo maintenance and evolve
over time in response to changing circumstances. For complex Web sites supporting the
execution of business processes, evolution can be particularly challenging. The hidden
nature of the transaction model in the overall design of most Web sites further
exacerbates the situation.
Business processes are realized as transactions that are triggered as the user executes
a series of activities in order to carry out a specific task (e.g., purchase an airplane ticket).
The manner in which the activities can be executed is a consequence of the transaction
design. Therefore, the quality of the transaction design can have a direct influence on
the quality of the user experience.
Unfortunately, many Web sites are constructed without proper attention to transaction
design. It is quite common to incorrectly treat a transaction as a sequence of navigational
steps through pages of the Web application (Rossi, Schmid, & Lyardet, 2003; Schmid &
Rossi, 2004). The result is a system without an explicit transaction design, which leads
to unpredictable workflow, maintenance difficulties, and a potentially frustrating session
for the user.
This chapter presents an example of the recovery of the “as-is” design model of a Web
application transaction. The recovery procedure is prescriptive, suitable for implemen-
tation by a human subject-matter expert, possibly aided by reverse engineering technol-
ogy (Tilley, 2000; Müller et al., 2003). The recovered design is modeled using extensions
to the transaction design portion of the Ubiquitous Web Applications (UWA) framework
(UWA, 2001f). Recovery facilitates future evolution of the Web site by making the
transaction design explicit, which in turn enables engineers to make informed decisions
about possible changes to the application. Design recovery of a commercial airline’s Web
site is used to illustrate the process.
The next section outlines UWAT+, which is a refinement of the UWA transaction design
model. The section “The Design Recovery Procedure” describes the design recovery
procedure, including a formalization of the transactions, the creation of the Execution
Model, and the construction of the Organization Model. The section “An Illustrative
Example” demonstrates the use of the procedure on a representative Web site from the
travel industry. Finally, “Summary” goes over the main points of the chapter and outlines
possible avenues for future work.
UWAT+
The Web provides a distributed information system infrastructure as the base platform
for application deployment. Indeed, one of the reasons for the success of e-commerce
business today is the transactional behavior that the Web offers. However, for many
Web sites that are already in use and in need of maintenance, this widely used behavior
is often too complex, consisting of several ill-defined sub-transactions which can hinder
TEAM LinG

systematic evolution. The transaction design for such applications needs to be more
explicit, flexible, and take users’ goals into account.
The UWA framework provides a complete design methodology for ubiquitous Web
applications that are multi-channel, multi-user, and generally context-aware. As illus-
trated in Figure 1, the UWA design framework organizes the process of designing a Web
application into four main activities (UWA, 2001a): (1) requirements elicitation (UWA,
2001b); (2) hypermedia design and operation design (UWA, 2001c); (3) transaction
design (UWA, 2001d); and (4) customization design (UWA, 2001e). Each design activity
results in a unique design model, which can iteratively affect the creation of other designs
elsewhere in the process.
The UWA framework represents an excellent platform on which to build the conceptual
modeling portion of the design recovery procedure. This section outlines a refined and
extended version of the UWA framework, called UWAT+, which focuses specifically on
extensions to the transaction design model. In the UWA vernacular, “transactions”
represent the way business processes are addressed and implemented in Web-based
applications. The extensions to the UWA transaction model include simplifications and
extensions related to the definition of Activity and enhancements to several aspects of
the Organization and Execution models, which are (according to the UWA) the main
models on which the design of a Web transaction is based. Extensive details of UWAT+
are provided in Distante (2004); this section provides an overview of the salient features
used for design recovery.
Changes to the Definition of Activity
Activities taken into account by the Organization and Execution model of a transaction
implementing a business process should only be those that are meaningful for the user
of the Web-based application; system-related activities and data-centered operations
Figure 1. An overview of the UWA application design process
TEAM LinG

can be de-emphasized. This implies that in UWAT+, the OperationSet of an activity is
no longer considered, mainly because it is primarily related to data-level details and to
the implementation of a transaction, whereas user-centered design recovery is more
concerned with conceptual models.
An Activity’s PropertySet is redefined to be more user-oriented, through the introduc-
tion of a new property (Suspendability), and the tuning of the semantics associated with
the previously existing properties. The extended PropertySet set is now Atomicity,
Consistency, Isolation, Durability, and Suspendability (ACIDS).
Changes to the Organization Model
The Organization model describes a transaction from a static point of view, modeling the
hierarchical organization in terms of Activities and sub-Activities in which the Activity
can be conceptually decomposed. It also describes the relations among these activities
and the PropertySet of each of them. The Organization model is a particular type of
Unified Modeling Language (UML) class diagram (Booch, Rumbaugh, & Jacobson,
1998), in which activities are arranged to form a tree; the main activity is represented by
the root of the tree and corresponds to the entire transaction, while Activities and sub-
activities are intermediate nodes and its leaves.
In UWAT+, significant changes have been made to the Organization model by dividing
the possible relations between an activity A1
and its sub-activities A1.1
.... A1.n
into two
categories: the Hierarchical Relations and the Semantic Relations. As shown in Figure
2 and Figure 3, the two categories are defined as follows:
• Hierarchical Relations: The set of “part-of” relations from the Organization
model. It is composed of relations such as Requires, RequiresOne, and Optional.
• Semantic Relations: The set of relationships that are not a “part-of” type.
Relations among sub-activities of different activities are normally part of this kind
of relation. The list semantic relations currently consists of the Visible, Compen-
sates, and Can Use.
The changes to the Organization model provide a better modeling instrument with which
design recovery can be accomplished. In particular, the distinction between hierarchical
and semantic relations permit the designer to reason about transactions in a manner that
is not possible with the unadorned UWA model. This in turn can lead to improvements
in support for the business processes realized by the Web application.
Changes to the Execution Model
The Execution model of a transaction defines the possible execution flow among its
Activities and sub-Activities. It is a customized version of the UML Activity Diagram
(Bellows, 2000), usually adopted by the software engineering community to describe
TEAM LinG

behavioral aspects of a system. In the execution model, the sequence of activities is
described by UML Finite State Machines, Activities and sub-Activities are represented
by states (ovals), and execution flow between them is represented by state transition
(arcs).
The original Execution model includes both user- and system-design directions for the
developer team. Since our focus is more on the former than the latter, several changes
have been introduced into UWAT+.
• Commit and Rollback Pseudo-State: These two pseudo-states that exist in the
original UWA execution model have been removed. Positive conclusion of an
Activity is directly derived by the execution flow in the model, while the failure or
the voluntary abort of it is modeled by the unique pseudo-state of “Process
Aborted” in an Execution model.
Figure 3. An example of the Organization model highlighting the semantic relationships
Figure 2. An example of the Organization model highlighting the hierarchical
relationships
<<Activity>>
<<Sub_Activity>>
Sub Activity Ai,m
XOR with Ai,m
<<Requires>>
<<Sub_Activity>>
<<Optional>>
<<Sub_Activity>>
Sub Activity Ai,n
Is optional
Activity Ai
Sub Activity Ai,j
Must be executed
<<Sub_Activity>>
Sub Activity Ai,l
XOR with Ai,m
<<Requires One >>
<<Activity>>
<<Activity>>
<<Sub_Activity>>
Sub Activity Ai,m
<<Sub_Activity>>
Sub Activity Ai,m
<<Sub_Activity>>
<<Sub_Activity>>
Activity Ai
Sub Activity Ai,j
Support Activity Ai,l,m
<<Sub_Activity>>
Sub Activity Ai,l
<<Compensation>>
<<Compensation>>
~Compensation Cj,m
Compensate the Activity Ai,m
<<Compensate>>
<<Activity>>
<<Activity>>
<<Sub_Activity>>
Sub Activity Aj,m
Activity Aj
<<Sub_Activity>>
Sub Activity Aj,l
Support Activity Ai,m
<<Can_Use>>
<<Can_Use>>
<<Sub_Activity>>
Sub Activity Ai,l,m
<<Sub_Activity>>
Sub Activity Ai,l,n
TEAM LinG

• Transition Between Activities: Each possible user-permissible transition between
activities must be explicitly represented in the model with a transition line between
them. The actions that trigger the transition should be specified on the transition
line with a transition label. Compensation activities (activities which rewind the
results of others) needed to allow a transition between two activities are implicit
and controlled by the system. No transition of the Execution model can be
associated with the action of the user selecting the “Back” navigation button in
the browser, which should be disabled in order to avoid client-side to server-side
data inconsistencies.
• Transition Labels: A classification of the possible labels that can be associated
with the transition lines of an Execution model has been introduced, with a simple
labeling mechanism being used to indicate the category of the transition:
• A: Action invoked by the user;
• C: Condition(s) required for Activity execution;
• R: Result of activity execution; and
• S: State associated with system due to Activity.
• Failure Causes and Actions Table: A list of causes of Activity failure and possible
actions the user or the system can take is maintained. The list also explains why
an Activity fails and how the user or the system can react.
• Adoption of Swimlanes: It is suggested that swimlane diagrams (OMG, 2003) be
adopted when it is useful to describe how two or more user-types of the application
collaborate in the execution and completion of a transaction.
The changes to the Execution model provide better visibility into the dynamic execution
paths the user will experience while completing a specific transaction. By making such
paths explicit, improvements in the transaction design can be more easily accomplished.
However, for such paths to be modeled properly for existing Web sites, they must first
be recovered.
The Design Recovery Procedure
Given an existing Web site, the goal is to populate an instance of the UWAT+ model
described in the previous section with data from the site’s content and structure. The
resultant model can then be used to guide restructuring decisions based on objective
information concerning the quality attributes of the business process’ implementation
by the Web-based application. The model can be recreated using a three-step prescrip-
tive design recovery procedure: (1) formalization of the transactions; (2) creation of the
Execution model; and (3) construction of the Organization model for each of the identified
transactions.
TEAM LinG

A human subject-matter expert can accomplish this design recovery procedure without
any tool support. However, as described in the subsection “Future Work” at the end of
this chapter, the use of automated reverse engineering technology (Chikofsky & Cross,
1990) may improve the efficacy of the process. Extensive details of the design recovery
procedure using reverse engineering are provided in (Distante, Parveen, & Tilley, 2004);
this section provides an overview of these three steps.
Formalization of the Transactions
In the first step of the process, the user-types of the application and their main goals/
tasks are formalized. Only goals/tasks that can be defined as “operative” are considered
and a transaction is associated with each of them. Overlapping tasks of two or more user-
types suggests UML swimlanes in the corresponding transaction’s Execution model. At
the end of this step the list of transactions implemented by the application is obtained.
Creation of the Execution Model
For each of the transactions found in the first step, the Execution model is created by first
performing a high-level analysis of the transaction in order to gain a basic understanding
of its component Activities and Execution Flow. The transaction is then characterized
as “simple” (linear) or “composite” (with two or more alternative execution paths). If the
transaction is composite, then it should be further decomposed into sub-transactions
until only simple transactions remain. Each simple transaction can be investigated
separately. To each transaction (simple and composite) an Activity of the Execution
model (and later of the Organization model) is associated.
A first draft of the Execution model is created for each simple transaction identified by
executing it in a straightforward manner. Failure events are not yet taken into account
in the model. The draft Execution model is then refined with deeper analysis of the
transaction. All the operations available to the user during the execution of the
transaction are invoked. Erroneous or incomplete data are provided in order to model
failure states and possible actions the user can undertake. In this analysis phase, new
secondary execution flows of the transaction can be found, and the reverse modeling
technique could be invoked recursively as needed.
Finally, the table that describes the possible failure causes and the corresponding user
actions or system invocations is investigated for each of the sub-activities that have
been found.
Construction of the Organization Model
Once the Execution model has been obtained for a transaction, the Organization model
can be constructed, which will model the transaction from a static point of view. The
Execution model is used to determine the set of Activities and sub-Activities of a
TEAM LinG

transaction. In the case of a simple transaction, the set is determined by all the Activities
and sub-Activities encountered in the single flow of execution available to the user. In
the case of a composite transaction, the set is composed of the union of the Activities
and sub-Activities of the single transaction that have been found for the composite
transaction.
The tree structure of the Organization model is constructed by aggregating sub-
Activities that are conceptually part of an Activity ancestor. Singleton Activities that
are related to the transaction are modeled with a Can-Use Semantic Relation. Each arc in
the tree represents either a hierarchical or semantic relation. To define Hierarchical
Relations, the analyst can refer to the Execution Flow defined by the Execution model and
conditions and execution rules defined in it. However, defining the semantic relations still
requires direct inspection of the application.
For each Activity and sub-activity, it is necessary to define the value for the ACIDS
PropertySet. The analyst is required to refer to the definition given for each of the
properties in the UWA documentation and discover the value to be assigned to each of
them through direct inspection using the Web-based application.
An Illustrative Example
To illustrate the potential benefits of design recovery, this section of the chapter focuses
on the use of the procedure described in the previous section. This technique is used
to recover the as-is transaction design model using the formalism outlined in the section
“UWAT+” of a real-world Web-based application. The application selected is the flight
reservation system of Alitalia airlines (Alitalia, 2004). The Italian Alitalia Web site
(www.alitalia.it) was chosen because it is representative of a commonly used e-
commerce application, and one that appears to offer significant room for improvement
from a user’s perspective. The analysis refers to a period of observation from November
to December 2003. It should be emphasized that it was the Italian version of the Alitalia
Web site that was analyzed; the versions for other locales, such as the USA, have been
found to be quite different.
The specific transaction from the Web site used to illustrate the design recovery
procedure is called “Round-Trip Flight Reservation.” The next two subsections de-
scribe the Organization and Execution models representing this transaction recovered
from the Alitalia Web site. The subsection “Discussion” narrates some of the perceived
shortcomings of the recovered transaction design that become apparent using these two
models.
The recovery was realized using a manual reverse engineering process. There is no
inherent reason why this process could not be made more efficient through the use of
appropriate tool support. For example, one possible useful tool would be a UML editor
with UWAT+ profiles. However, such tools do not as yet exist.
TEAM LinG

The Recovered Organization Model
The recovered “as-is” Organization model of the “Complete Flight Reservation”
process is shown in Figure 4. The Organization model has a tree structure, with the
Activity corresponding to its root representing the main process. The model includes the
Hierarchical and Semantic Relations existing among the Activities, and for each Activity,
the PropertySet it verifies.
The Activity names used in the model are purposely lengthy, so that they indicate some
of the characteristics worthy of attention later in the recovery process. The user-type
simulated in the analysis is “Nonregistered User.” Unless otherwise stated, this is the
user-type implied in the following discussion.
A registered user can choose to execute one of the following three activities to reserve
a flight using the Alitalia Web site: Fast Flight Reservation, Complete Flight Reserva-
tion, and Managing Reserved Flights. These activities are in fact connected to the main
activity of the diagram (the reservation process) with a Requires One relation. This last
activity is available only to the user type Registered User. The Payment activity is an
optional activity that the users could execute if they wish to purchase the corresponding
ticket online. The hierarchical relation of Optional that links it to its ancestor indicates
this.
The model in Figure 4 details the Complete Flight Reservation Activity; the other
Activities (which are represented by a filled version of the UML Class Stereotype), are
omitted for lack of space. The PropertySet of the Complete Flight Reservation activity
is set to AID (Atomic, Isolated, and Durable). It was observed that the user could
experience inconsistency among data visualized, so the Activity is not Consistent.
Moreover, the Activity is not Suspendable because it cannot be suspended in any time;
instead, it must be completed during one usage session of the application.
Figure 4. The “as-is” Organization model of the “Complete Flight Reservation”
Activityin the Alitalia.it Web site
<<AID_Activity>>
Complete Flight
Reservation
<<A_Activity>>
Identification
<<Requires_Visible>>
<<Requires One>>
<<Requires One>>
<<A_Activity>>
Login
<<A_Activity>>
Login
<<AD_Activity>>
Insert Name &
Telephone #
<<AD_Activity>>
Insert Name &
Telephone #
<<Requires_Visible>> <<Requires_Visible>> <<Requires_Visible>> <<Requires_Visible>> << Required >>
<<Compensates>>
<<AC_Activity>>
View & choose
Flight & Class
among available
<
<
<<AC_Activity>>
Define and Search
for Flights
<
<
View Flight Fare without
Taxes and Confirm Request
of Flight Reservation
<<A_Activity>>
<
<
<<ACD_Activity>>
View Reservation
Details and Total
Ticket Price
<
<
<<AC_Compensation>>
~ Confirm Reservation
Insert Passenger’s
Information & Choose
On-board Options
<<AC_Activity>>
<
<
TEAM LinG

Figure 5. The “as-is” Execution model of the “Complete Flight Reservation” Activity
in the Alitalia.it Web site
The diagram also shows the sub-activities into which the Complete Flight Reservation
Activity can be conceptually decomposed. These are Define and Search for Flights,
Choose Flight & Class Among available, Insert Passenger’s Information & Choose On-
board Options, View Flight Fare Without Taxes and Confirm Request of Flight
Reservation, View Reservation Details and Total Ticket Price, and Identification. All
of these are activities required for the main Complete Flight Reservation Activity to be
completed.
The activities that correspond to the leaves of the tree are elementary ones the user
normally executes in a single episode. The model shows that the user can accomplish the
Identification Activity by either logging into the system (Login activity, available only
for registered users) or providing a name and a telephone number (Insert Name and
TEAM LinG

Telephone # activity). These two activities are in fact related to their ancestor with a
Requires One hierarchical relation.
Most of the activities in the recovered Organization model were found to be Visible since
the changes they affect on data are visible by other activities during a session. The
~Confirm Reservation activity is a Compensates activity which in essence rewards the
effects of a successfully completed reservation when the user decides to delete it.
The Recovered Execution Model
The recovered “as-is” Execution model of the Complete Flight Reservation process is
shown in Figure 5. The model details the activities of Complete Flight Reservation and
Payment of the Organization model described in the “UWAT+” section. In the following
discussion, the most linear flow of execution the user can experience while reserving a
seat using the Alitalia Web site is used. (Note that while the Execution model also depicts
the sub-Activities that compose the Payment Activity and describes the set of payment
options the user can choose from, this activity is quite simply structured and is therefore
not the focus of the design recovery process.)
The process of Round-Trip Flight Reservation requires five steps to be completed.
These steps are illustrated in sequence by referring to the Execution model in Figure 5
and the screenshots of the Web page of the application supporting each of the five
activities.
Step 1. The user starts the flight reservation process by defining the request of “Round-
Trip Flight Reservation” and starting the flight search (Define and Search for Flights).
Figure 6. The activity of “Define and Search for Flights” in the Alitalia.it Web site
TEAM LinG

Figure 6 shows a screenshot of the Alitalia Web page for this Activity. For this Activity
to be successfully executed, the user must indicate the number of passengers, the
preferred class, the departure and destination airports, and the departure and return
dates. Default values are provided for most of the required input parameters; utilities that
might have been helpful, such as a calendar, are not available to the user.
Step 2. If the flight search is successful, a list of possible flights (with different routes
between departure and destination, and different times) is proposed for the itinerary (with
an indication of the traveling class) specified in the previous step. The user is then
required to choose the preferred path from the departure airport to the destination, and
class of travel (View & Choose Flight & Class Among Available). Even if the preferred
traveling class was specified in Step 1 of the process, the system still shows flights
belonging to other classes. Figure 7 shows the screenshot of the Web page that enables
the user to execute this Activity.
Step 3. To proceed ahead toward the completion of the reservation process, the user is
required to provide all the information about the traveling passengers and choose for
them the On-Board options such as the preferred meal and eventual needs for assistance
services (Insert Passenger’s Information & Choose On-board Options). Figure 8 shows
a screenshot of the Web page in charge of this activity.
Step 4. After the previous activities have been successfully completed in sequence, the
flight details and fare (without taxes) are shown. The user is asked to confirm the choices
in order to effectively request the flight reservation and the system to commit it (View
Flight Fare Without Taxes and Confirm Request of Flight Reservation). This is shown
in Figure 9.
Figure 7. The activity of “Choose Path & Class Among Available” in the Alitalia.it Web
site
TEAM LinG

Step 5. If the flight reservation request succeeded, then the activity of Complete Flight
Reservation, represented in Figure 5 by a large rounded rectangle as background, can
be considered successfully completed. As shown in Figure 10, at this point the user is
provided with the flight reservation code, the date they must purchase the ticket, details
of the reserved flight, and the total price (taxes included) (View Reservation Details and
Total Ticket Price). A necessary condition for the reservation confirmation to be
successful is that the user has previously been identified to the system by executing the
Identification Activity. This is accomplished by either logging into the system (in the
case of a registered user), or by specifying first and last name and providing a telephone
number (in the case of an unregistered user).
Figure 8. The “Insert Passenger
Information & Choose On-board Options”
Activity
Figure 9. The “View Fare Without Taxes
and Confirm Request of Flight
Reservation” Activity
Figure 10. The “View Reservation Details and Total Ticket Price with Taxes” Activity
TEAM LinG

When Step 5 is completed, the user can exit the process or proceed with the Payment for
purchasing the ticket corresponding to the reservation just confirmed by the system.
However, only the link that starts the Payment activity is made explicit by the application;
neither “Exit” nor “End Process” button is provided to the user to indicate that the
reservation process has been completed and can be exited. The model shows that only
the user call “Proceed with Payment Options” is provided to the user. This may be
considered a navigation problem, but if known at design time, it could have been avoided.
In the case of a registered user, the reservation is stored in Personal Travel Book and from
here the user can pay the ticket online at a later time. In the case of an unregistered user,
if the process is exited without contextually executing the Payment activity (e.g., simply
closing the browser or navigating outside the pages related with the process), the user
has no way to restart the Activity and to buy the ticket in a later session. The previous
consideration tells us that the Payment activity is Suspendable only for registered users.
As mentioned at the beginning of this section, Steps 1 to 5 depict the normal, linear
execution flow for the process of Complete Flight Reservation. However, depending on
the user’s choices and the system’s responses, several execution paths can be followed.
For example, the execution flow can take a different path from the one described if one
of the involved activities fails.
Failure causes and corresponding actions that can be undertaken by the user or the
system in response to them are described by Failure Tables. Two of these are summarized
in Table 1 and Table 2. The first table refers to the activity of Define and Search for
Flights, while the second refers to the possible failure causes identified for the activity
of View Flight Fare Without Taxes and Confirm Request of Flight Reservation.
Discussion
A number of observations can be made regarding possible areas of improvement for the
Alitalia transaction design, based on the as-is recovered Organization and Execution
models and taking into account other information extracted from the application during
its direct analysis. Five areas that can be considered the most important are: the
Table 1. Failure table for Activity “Define and Search for Flights”
TEAM LinG

suspendability of the entire process of Complete Flight Reservation, the Identification
Activity, the Insert Passenger’s Information & Choose On-board Options activity,
visualizing total cost, and restarting the process. Each of these shortcomings (SC) is
discussed in turn.
SC1: Suspendability of the Entire Process
The first consideration concerns the Suspendability of the entire “Complete Flight
Reservation” transaction. As shown by the Execution model, none of the activities
involved in the process are Suspendable. For example, the user cannot store a flight they
found interesting to continue the reservation process in a following session.
In addition, the Payment activity, as noted in Step 5 of the previous section, is
Suspendable for registered users only. An unregistered user has no chance to purchase
the ticket in a following usage session of the application. One could argue that this is an
implementation issue. One could also argue that this is a matter of security policy. In
either case, the designer could document the tradeoffs regarding design decisions such
as Suspendability if the rationale were made explicit in the model.
SC2: The Identification Activity
The second important consideration is related to the Identification Activity. As shown
by the Organization model in Figure 4, the Identification activity is required for the
successful completion of the “Complete Flight Reservation” process. In this case, the
shortcomings lie in the way the user is forced to access and execute this activity and what
its execution causes.The user can start the Identification Activity with the user call
Login (following a link provided by the application) only when executing the Define and
Search for Flights or the Choose Flight & Class Among Available activities. Moreover,
as described by the transition line of the Execution model in Figure 5, executing the
Table 2. Failure table for Activity “View Flight Fare Without Taxes and Confirm
Request of Flight Reservation”
TEAM LinG

Identification activity causes a loss of the state of the transaction (implementation of
the process) and forces the user to restart the process.This also happens when the user
reaches the confirmation step (Step 5) of the reservation process and, because the user
did not do it before, the activity fails in requesting the user to identify themselves.
SC3: The Insert Passenger’s Information & Choose On-Board Options
Another aspect worthy of attention is the Insert Passenger’s Information & Choose
On-board Options Activity. As shown by the Execution model in Figure 5 and
described in the previous section (Step 3), this Activity is required in order to carry out
the reservation process. The reverse modeling process exposed the fact that this activity
is executed before the user knows the fare of the selected flight (Step 4), and each time
the user conducts a new search or selection of flights. It rapidly becomes very frustrating
to the user to have to repeatedly input the same information. Iteratively searching for
flights by changing dates and itineraries looking for the best fare available is a very
common activity in any airline flight reservation application. Rather than acting as it does
now, the Alitalia system should instead request the Passenger’s Information only one
time, and then display the fare of the chosen flight during the entire session of usage.
The fact that the system loses the information entered by the user when executing this
activity is also modeled by the lack of the Durability property in the Organization model
in Figure 4.
SC4: Visualizing Total Cost
The fourth issue regards the visualization of the total cost, including taxes, of the chosen
flight. Users can easily find themselves guessing between available flights shown by the
systeminStep2,butneedingtoreachStep4toseetheflightfare.Moreover,thepriceshown
in this Step, as the names of the Activity suggests, does not include taxes, and only after
confirming the reservation request will the user finally know the total ticket price.
SC5: Restarting the Process
Last but not least is the consideration about how much easier it is for the user to start
over with another search for flights looking for a better fare. Since this is a common goal
for most of the users, the application should offer the opportunity to start a new search
at nearly every point of the reservation process. Instead, as the Execution model in Figure
5 shows, the application explicitly provides a way to start a new search only at Step 2,
which is prior to the user knowing the price of a chosen flight. The user can attempt to
get around this limitation by using the “Back” button in the browser, but this invites
problems related to session expiration.
TEAM LinG

Summary
This chapter presented an example of design recovery of Web application transactions.
The design recovery procedure relies on UWAT+, which is a conceptual model that is
based on extensions to the transaction design portion of the UWA framework. The
prescriptive recovery procedure is composed of three steps, which can be accomplished
by a human subject-matter expert. A commercial airline’s flight reservation system was
used to illustrate the procedure.To use the procedure, there is a one-time learning curve
required for the engineer to become familiar with the UWA design framework and the
UWAT+ refinements. However, once this is done, the procedure is relatively easy to
understand and systematic to apply. The designer is provided with a sequence of clear
steps to be carried out and a set of well-defined concepts to refer to, represented by means
of the well-known notation of UML diagrams. Applying the reverse modeling technique
allows the analyst to draw from the application and effectively represent with the models
a lot of information perceived by the user and worthy of attention from their point of
view.The design recovery procedure provides the analyst/designer with a tool (broadly
intended and not specifically a software tool) that is able to represent most of the aspects
related to the user execution of a process to carry out their goals. UWAT+ relies on two
models, the Organization model and Execution models, that, taken together, are suitable
for describing at a conceptual level the design of Web application transactions. These
are strong bases of discussion and comparison of ideas and strategies that the Web
application realizes.
Future Work
One area of future work we foresee is to develop tool support for the design recovery
procedure. Such tool support would greatly improve the likelihood of adoption by easing
the reverse modeling task. It would also make the analysis phase faster and more
thorough than the current manual approach. Supporting tools could range from commer-
cialUMLdiagrammingeditors,providedwithUWAT+OrganizationandExecutionmodel
profiles (plug-in), to semi-automatic tailored tools able to analyze and model the
Activities of an identified transaction.Another area of future work is to use the recovered
design as a guide to reengineering the Web site’s transactions. The following three steps
outline a possible reengineering technique for Web application transactions:
1. Perform the transaction design recovery of the Web site using the procedure
described in this chapter;
2. Analyze the recovered “as-is” UWAT+ transaction design model and evaluate it
according to quality attributes such as usability and fulfillment of business
requirements; and
TEAM LinG

3. Develop a new version of the transaction via restructuring of the as-is model,
resulting in a candidate “to-be” model that better meets the user’s expectations and
improves the user’s experiences using the Web site.
Evidence-based techniques such as empirical studies could be used to verify that the
resultant Web site is “better” in some quantifiable way than the original. The difficulty
is in quantifying “better,” both for the designer and the developer. For the designer, one
measure might be shorter time-to-market for a complex Web application, while still
retaining and even improving functionality and lower subsequent maintenance costs.
For the user, the measure is likely to remain usability—something that is notoriously
difficult to measure, but ultimately the most important attribute of all for any application.
Acknowledgments
Tauhida Parveen contributed to the development of an early draft of this chapter.
References
Alitalia (2003). Available online at www.alitalia.it
Bellows, J. (2000). Activity diagrams and operation architecture. CBD-HQ White paper.
Available online at www.cbd-hq.com
Booch, G., Rumbaugh, J., & Jacobson, I. (1998). The unified modeling language user
guide, (Rational Corporation Software). Reading, MA: Addison-Wesley.
Chikofsy, E. & Cross, J. (1990). Reverse engineering and design recovery: A taxonomy.
IEEE Software, 7(1), 13-17.
Distante, D. (2004). Reengineering legacy applications and web transactions: An
extended version of the UWA transaction design model. Unpublished Doctoral
Dissertation, University of Lecce, Italy.
Distante, D., Parveen, T. & Tilley, S. (2004, June 24-26). Towards a technique for reverse
engineering web transactions from a user’s perspective. In Proceedings of the 12th
International Workshop on Program Comprehension, IWPC 2004, Bari, Italy, (pp.
142-150). Los Alamitos, CA: IEEE Computer Society Press.
Müller, H., Jahnke, J., Smith, D., Storey, M.-A., Tilley, S., & Wong, K. (2003). Reverse
engineering: A roadmap. In A. Finkelstein (Ed.), The future of software engineering
(pp. 47-60). New York: ACM Press.
Object Management Group (OMG) (2003). Unified language modeling specification,
version 1.5. Available online at www.omg.org
TEAM LinG

Rossi, G., Schmid, H. & Lyardet, F. (2003). Engineering business processes in web
applications: modeling and navigation issues. Proceedings of the 3rd
International
Workshop on Web Oriented Software Technology (IWWOST 2003), Oviedo, Spain.
Schmid, H. & Rossi, G. (2004). Modeling and designing processes in e-commerce
applications. IEEE Internet Computing, January/February.
Tilley, S. (2000). The canonical activities of reverse engineering. Annals of Software
Engineering, 9, (pp. 249-271). Dordrecht, The Netherlands: Baltzer Scientific /
Kluwer Academic.
UWA (Ubiquitous Web Applications) Project (2001a). Deliverable D3: Requirements
investigation for Bank121 pilot application. Available online at
www.uwaproject.org
UWA (Ubiquitous Web Applications) Project (2001b). Deliverable D6: Requirements
elicitation: model, notation and tool architecture. Available online at
www.uwaproject.org
UWA (Ubiquitous Web Applications) Project (2001c). Deliverable D7: hypermedia and
operation design: Model and tool architecture. Available online at
www.uwaproject.org
UWA (Ubiquitous Web Applications) Project (2001d). Deliverable D8: Transaction
design. Available online at www.uwaproject.org
UWA (Ubiquitous Web Applications) Project (2001e). Deliverable D9: Customization
design model, notation and tool architecture. Available online at
www.uwaproject.org
UWA (Ubiquitous Web Applications) Project (2001f). The UWA approach to modeling
ubiquitous Web application. Available online at www.uwaproject.org
TEAM LinG

20 Grunske
Chapter II
Using a Graph
TransformationSystem
to Improve the Quality
Characteristicsof
UML-RTSpecifications
Lars Grunske, University of Potsdam, Germany
Abstract
This chapter presents the concept of graph-based architecture evolution and how this
concept can be applied to improve the quality characteristics of a software system. For
this purpose, the UML-RT used as an architectural specification language is mapped
to a hypergraph-based data structure. Thus, transformation operators can be specified
as hypergraph transformation rules and applied automatically.
Introduction
Over the past few years, software intensive technical or embedded systems have
increasingly been implemented in software components (Douglas, 1999; Gomaa, 2000;
Liggesmeyer, 2000). These software components have to fulfill requirements relating to
quality characteristics or nonfunctional properties (NFPs), such as safety, availability,
reliability, and temporal correctness. If a system does not fulfill these requirements, the
TEAM LinG

Improving the Quality Characteristics of UML-RT Specifications 21
system must be restructured to improve the quality characteristics. Due to economical
reasons, this change must be made as early as possible, preferably in the design phase,
after the development of the system/software architecture. Based on the architecture
specification, for the first time, an evaluation of the quality characteristics of the system
is possible.
For the restructuring of software architectures in Bosch and Molin (1999), a cyclic
process (see Figure 1) is presented that can be used to improve the quality characteristics
of software architectures. The precondition for its application is an architectural
specification that fulfills all functional requirements. Based on this specification, the
quality characteristics are determined by an evaluation of the architecture. If the
architectural specification does not meet its quality requirements, the software architec-
ture must be restructured by the application of transformation operators. These trans-
formation operators should influence the quality characteristics without changing the
functional behavior. Thus, after the transformation the architectural specification is still
functionally correct. If it turns out that all quality characteristics meet their correspond-
ing requirements, the cyclic process can be terminated and system development can
proceed with the detailed design and the implementation phase.
This chapter presents the concept of hypergraph-based architectural evolution and how
this concept can be applied in the process model. For this purpose UML-RT is used as
anarchitecturaldescriptionlanguageandtherelevantelementsoftheUML-RTmetamodel
are mapped to a hypergraph-based data structure. The main benefit of this approach is
the possibility to model architecture transformations as hypergraph transformation
rules. Consequently, this approach allows for a (semi-) automatic application. Due to the
complexity of the overall setup and the precision needed, it becomes inevitable to support
the evolution process with an appropriate utility. For this purpose, a tool called Balance
has been developed, which provides facilities for applying the architectural transforma-
tions explained previously.
To clarify the understanding of the hypergraph-based architecture evolution, we are
going to explain these items more precisely in the following sections. In the second
system-/software architecture that fulfills all functional
requirements
architecture-
evaluation
architecture-
transformation
ok
architectural
problem
system-/software architecture that fulfills all functional and non-
functional requirements
Figure 1. Cyclic process for the improvement of quality characteristics
TEAM LinG

22 Grunske
section, the theoretical background of hypergraphs and hypergraph transformations is
presented. The next section gives an overview of the current state-of-the-art for software
evolution with graph transformation. In the fourth section, an approach on how to use
graph transformation for architectural evolution is presented. The fifth section demon-
strates the application of this approach in the tool balance. Finally, conclusions are
drawn and directions for future work are discussed.
Theoretical Background
Hypergraphs Theory
Hypergraphsareageneralizationofnormalgraphs,whereanedgecanbeassociatedtomore
than two nodes. They are a data structure that can be applied in many areas (Habel, 1992).
Basic Concept
Generally, a hypergraph contains a set of nodes and hyperedges. Each hyperedge can
be attached to any number of nodes and each node can be attached by any number of
hyperedges.
To construct a hierarchical hypergraph, we use the concept of hyperedge refinement
(Drewes,Hoffmann,&Plump,2002;Hoffmann,2001;Hoffmann&Minas,2001).Forthis
purpose, special hyperedges are introduced that are used to embed another hypergraph.
These hyperedges are called complex hyperedges.
Altogether, the metamodel presented in Figure 2 characterizes a typed hierarchical
hypergraph.
hyperedge
hypergraph
att
cts
complex
hyperedge
*
*
1
* *
E V
node
Figure 2. Metamodel of a hierarchical typed hypergraph
TEAM LinG

Formal Definition
This section deals with the formal concept of a hierarchical typed hypergraph. Flat typed
hypergraphs are introduced first, followed by multi-pointed hypergraphs. Based on
these definitions, a hierarchically typed hypergraph can be defined.
According to Habel (1992) a flat typed hypergraph can be defined as follows:
Definition:TypedHypergraph
Let LV
be a set of node types and LE
be a set of hyperedge types, then a hypergraph G
from the possible set of hypergraphs GSET
over LV
and LE
is characterized by the tuple
<V, E, att, lab>, with two finite sets V and E of nodes (or vertices) and hyperedges, a
labeling function lab : V→LV
∪E→LE
and an attachment function att : E∪V *
, where V *
denotes a sequence of nodes with a specified order.
The labeling function allocates for each hyperedge, and each node, a hyperedge or node
type. The attachment function att assigns a sequence of nodes to a hyperedge. The
number of elements in this sequence att(e) is called the arity of the hyperedge.
Hierarchical hypergraphs are introduced in Drewes et al. (2002) and Hoffmann (2001) by
the refinement of special hyperedges. These hyperedges are used to embed a multi-
pointed hypergraph, which contains external nodes and is defined as follows:
Definition:Multi-PointedHypergraph
A multi-pointed hypergraph is characterized by the tuple <V, E, att, lab, ext>, where
<V, E, att, lab> is a typed hypergraph and ext describes a sequence of external nodes
ext∈V *
.
The arity of a multi-pointed hypergraph can be determined by the length of the external
node sequence ext. For the embedding of a multi-pointed hypergraph into another
graph a hyperedge with the same arity can be refined. For this reason, the hyperedge must
be removed from the graph and the multi-pointed hypergraph included in the remaining
hyperedge frame. This hyperedge frame consists only of the associated nodes of the
removed edge. The nodes of the hyperedge frame and the external nodes are mapped and
define the glue between the enclosing graph and the embedded hypergraph (Drewes et
al.,2002).
Based on the hyperedge refinement and the definition of a multi-pointed hypergraph, a
hierarchical typed hypergraph can be defined as follows:
Definition:HierarchicalTypedHypergraph
A hierarchical typed hypergraph G from the set of hypergraphs GSET
over LV
and LE
is
characterized by the tuple <V, E, att, lab, ext, cts>, where <V, E, att, lab, ext> is a multi-
pointed hypergraph and cts : E→GSET
is an assignment function which assigns contained
hierarchical typed hypergraphs to a hyperedge.
Due to the recursive nature of this definition, the structure of a hierarchical hypergraph
is defined inductively over levels of the hierarchy. In the lowest level G0
SET
, no hyperedge
TEAM LinG

24 Grunske
e∈E contains an embedded hypergraph cts(e) = ∅. Thus, all hypergraphs in G0
SET
are
regular typed graphs. In higher hierarchy levels G≥1
SET
with the function cts : E→GSET
the
embedded graphs are assigned to the hyperedges.
Based on object-oriented concepts, the node types LV
and hyperedge types LE
can be
specified as classes. These classes can contain a set of application-specific attributes
and operations. Furthermore, hypergraphs can be typed as classes.
Specific classes can be derived by inheritance from the classes of the metamodel. These
classes extend the set of attributes and operations. In addition, with the introduction of
classes it is easy to define variables and integrate them into a hypergraph specification.
These variables can be instantiated from the class itself or from a subclass.
Hypergraph Transformation
Basic Principles
Before graph transformation rules can be specified, some basic principles have to be
introduced. One of them is the identification of a subhypergraph that can be defined as
follows(Habel,1992):
Definition:Subhypergraph
Let G = <V, E, att, lab> and G' = <V', E', att', lab'> be two hypergraphs. Then G' is called
a subhypergraph of G, denoted by G' ⊆ G, if V' ⊆ V, E' ⊆ E and att(e) ⊆ att'(e), lab(e)
= lab'(e) lab(v) = lab'(v) for all edges e∈E' and nodes v∈V'.
A subhypergraph specifies the exact occurrence in an application graph—a graph to
which a transformation is to be applied. This exact identification restricts the application
of a transformation rule. Thus, the identification of a subhypergraph is done by a
hypergraph morphism, which is a structure- and type-preserving mapping (Habel, 1992):
Definition:HypergraphMorphism
Let G = <V, E, att, lab> and G' = <V', E', att', lab'> be two hypergraphs. A hypergraph
morphismm:G→G'consistsofapairofmappings<mV
,mE
>,withmV
:V→V'andmE
:E→E'
which satisfy the following conditions:
( )
( ) ( )
: E
e E lab m e lab e
′
∀ ∈ =
( )
( ) ( )
: v
v V lab m v lab v
′
∀ ∈ =
( )
( ) ( )
( )
e
att
m
e
m
t
at
E
e V
E
*
: =
′
∈
∀
If both mappings mV
: V→V' and mE
: E→E' are injective (surjective, bijective), then
the mapping m : G→G' is injective (surjective, bijective). Furthermore, if the mapping
TEAM LinG

m : G→G' is bijective, the morphism is called an isomorphism and both graphs G and G'
are isomorphic denoted by G G′
≅ .
In addition to the identification of a subhypergraph in an application graph for the graph
transformation, it is necessary to define how a subhypergraph can be removed and added
to an application graph. The hypergraph addition will be constructed by a disjoint union
of the node and hyperedge sets. The removal of a subhypergraph can be constructed
separately by the difference of sets for nodes and hyperedges.
Definition:DisjointUnionofHypergraphs,HypergraphAddition
Let G = <V, E, att, lab> and G' = <V', E', att', lab'> be two hypergraphs with V ∩ V' = ∅
and E∩E'=∅, then the disjoint union G+G' is defined by the tuple <V∪ V', E∪E', attG+G'
,
labG+G'
>, with attG+G'
and labG+G'
which can be constructed as follows:
( ) ( )
( )
( ) ( )
G G
G G
G G
att e att e if e E
att e
att e att e otherwise
′
+
′
+
′
+
= ∈

= 
′
=

( ) ( )
( )
( ) ( )
G G
G G
G G
lab a lab a if a E V
lab a
lab a lab a otherwise
′
+
′
+
′
+
= ∈ ∪

= 
′
=

Definition:RemovalofaSubhypergraph,HypergraphSubtraction
Let G = <V, E, att, lab> and G' = <V', E', att', lab'> be two hypergraphs, with G'⊆G, then
the hypergraph G – G' is characterized by the tuple <V – V', E – E', attG – G'
,labG – G'
>, where:
( ) ( ) ( ), ( )
( ) ( ) , ( ) ( )
G G
G G
att e att e V e E E
lab a lab a a V V E E
′
−
′
−
′ ′
= − ∀ ∈ −
′ ′
= ∀ ∈ − ∪ −
J
Hypergraph Replacement
A hypergraph transformation rule defines in an abstract manner the replacement of a
subhypergraph by another in an application graph. A hypergraph transformation rule
can be formally defined as follows (Corradini et al., 1997; Ehrig, 1979):
Definition:HypergraphTransformationRule
A hypergraph transformation rule is a tuple <GL
, GI
, GR
, l, r>, with three hypergraphs GL
,
GR
, GI
, ∈ G called left-hand-side graph, right-hand-side graph and interface graph and
two hypergraph morphisms l : GI
→GL
and r : GI
→GR
. For simplification, a hypergraph
transformation rule can be denoted with GL
←GI
→GR
.
TEAM LinG

26 Grunske
For the application of a hypergraph transformation rule, the following algorithm can be
used:
• Find an occurrence morphism o : GL
→Gthat identifies the left-hand-side graph GL
in an application graph G.
• Check the following two conditions:
• Dangling condition: No hyperedge e ∈ EG
– Eo(GL)
is associated with a node
k ∈ Vo(GL)
– Vo(GI)
• Identification condition: If two hyperedges x, y ∈ EGL
or nodes x, y ∈ VGL
are identified by o with o(x) = o(y), then these hyperedges or nodes are
elements of the interface graph x, y ∈ EGI
∪ VGI
.
• Remove the occurrence of the left-hand-side hypergraph except for the inter-
face graph from the application graph. The resulting graph is called context
graph D = G – o(GL
– GI
).
• Add the right-hand-side GR
except for GI
to the context graph resulting in G'
= D+(GR
– GI
) and connect all hyperedges e ∈ EGR
– EGI
which are
associated to a node k ∈ VGI
to the corresponding node of the context graph
o'(k), where o' : GI
→D.
The dangling condition and the identification condition must be checked to get a
syntactically correct graph after the application of the graph transformation rule. If the
dangling condition fails, hyperedges which are associated to already removed nodes
exist in the context graph. If the identification condition is neglected, elements exist in
the application graph which must be simultaneously preserved and removed. Thus, the
context graph cannot be constructed. Due to simplicity, for the implementation of a
hypergraphtransformationrulethealgebraicapproach(Ehrig,1979;Corradinietal.,1997)
is preferred. This approach is based on the construction of pushouts and pushout
complements in the category of typed graphs. To visualize a graph transformation rule
and its application within the algebraic approach the following pushout diagram can be
used:
l r
L I R
o o o
G G G
G D G
′ ′′
← →
↓ ↓ ↓
′
← →
The context graph D and the morphism o' are constructed by pushout complements of
the tuple <GL
, o, l>. Subsequently, the resulting graph G' can be constructed with the
pushout of the tuple <GI
, o, r>.
TEAM LinG

Type-Generic Graph Transformation
Type-generic graph transformation improves the expressiveness of graph transfor-
mation rules by allowing the identification of subtypes with the occurrence morphism
o : GL
→G (Mens, 1999). For this reason, the partial order for the subtype relationship
must be defined first.
Definition: Partial Ordered Type Hierarchies
A type hierarchy over the nodetypes LV
, edgetypes LE
and hypergraph types G ∈ GSET
can be defined by partially ordered relations ôV
, ôE
, ôG
, where x ô y means that the type
x is a subtype of y.
Based on this, a subtype preserving hypergraph morphism can be defined as follows.
Definition:SubtypePreservingHypergraphMorphism
Let G = <V, E, att, lab> and G' = <V', E', att', lab'> be two hypergraphs. A
hypergraph morphism m : G→G' consists of a pair of mappings <mV
, mE
>, with mV
:
V→V' and mE
: E→E' which satisfy the following conditions:
( )
( ) ( )
: ′
∀ ∈ E E
e E lab m e lab e
ô
( )
( ) ( )
: V V
v V lab m v lab v
′
∀ ∈ ô
( )
( ) ( )
( )
e
att
m
e
m
t
at
E
e V
E
*
: =
′
∈
∀
This subtype preserving hypergraph morphism allows the algebraic specification (Ehrig,
1979) of a type-generic graph transformation rule as presented in Mens (1999).
Hypergraph Transformation in Hierarchical Typed Hypergraphs
For the hypergraph replacement in hierarchical typed hypergraphs, the morphisms must
first be introduced into this category. This can be defined according to Drews, Hoffmann,
and Plump (2002) and Hoffmann and Minas (2001) inductively over the embedding
hierarchies:
Definition:MorphisminHierarchicalTypedHypergraphs
Let G = <V, E, att, lab, cts> and G' = <V', E', att', lab', cts'> be two hierarchical typed
hypergraphs, then a morphism m : G→G' is defined by a tuple <mV
, mE
, M>, where <mV
,
mE
> characterizes a morphism of a flat graph and M is a family of morphisms Me
for the
embedded hypergraphs of all complex hyperedges e ∈ dom(cts). Thereby, each morphism
Me
can be defined as follows:
TEAM LinG

28 Grunske
))
(
(
)
(
: e
m
s
ct
e
cts
M E
e
′
→
Drews, Hoffmann, and Plump (2002) show that in the category of hierarchical typed
hypergraphs, pushouts and pushout complements can be constructed. Thus, the
application of a hypergraph transformation rule can be applied similar to the algebraic
approach (Ehrig 1979).
Graph-Based Software Evolution:
An Overview
In this section, the existing approaches for graph-based transformation of software
specifications will be reviewed. For this purpose a short introduction into relevant
approaches is given. The goals, the theoretical background, and the practical realization
of each approach are presented. At the end of this section all approaches are compared
in Table 1 in order to decide which concepts and aspects can be used for the graph-based
architecture evolution. Furthermore, the relevant aspects for qualitatively improving
architectural evolution are pointed out.
Approach of T. Mens et al.
Mens (1999) introduces a general approach for the evolution and transformation of
models for the object-oriented software development process. This approach aims at a
consistent formalism for the evolution during the design time of the software. For this
purpose, graphs and graph transformation rules are utilized, where graphs represent
model-independent specification formalism, and graph transformation rules represent
model-independent transformation formalism. For the specification, hierarchical typed
graphs are considered in particular. This formalism is used in Mens, Demeyer, and
Janssens (2002) to describe behavior-preserving transformation rules. For the specifi-
cation of the transformation rules, conditional rules are used, which are graph transfor-
mation rules enhanced with preconditions. Consequently, a systematic selection of the
rules is possible and conflicts with the parallel and sequential rule application can be
identified. For the practical validation of the approach, a prototype realized in Fujaba is
described.
Approach of G. Taentzer
Taentzer’s approach (1999) describes the visual specification of the behavior and the
evolution of distributed systems. In particular, the runtime-evolution of the system is
considered. At this point, her approach differs from the previously presented approach.
TEAM LinG

For the description of the runtime evolution, the concept of distributed graph transfor-
mation based on the algebraic approach (Ehrig, 1979) is used (Ehrig, Boehm, Hummert,
& Löwe, 1988). The practical applicability of the approach and the application to two case
studies (Taentzer, 1999) is presented by the realization of a prototype in AGG (Taentzer,
Ermel,&Rudolf,1999).
Approach of D. Le Metayer
Le Metayer (1998) describes a basic approach for the formalization of architectural styles.
The idea of his approach is the specification of software architectures as a graph whose
nodes describe active components and whose edges describe the communication
relations between these components. Based on previous information, architecture
transformations with a refinement focus can be specified as graph transformation rules.
With these architecture transformations, a graph grammar can be constructed that
describes a class of architectures or an architectural style.
Approach of D. Hirsch et al.
Hirsch, Montanari, and Inverardi (1999) present an approach for the architectural
configuration of distributed systems. Communication systems and their basic compo-
nents, such as Client, Server, Router and Bridges, are considered particularly. The goal
of the reconfiguration is to refine architectures and thereby follow an architecture style.
The approach resembles the work of Le Metayer (1998). Hypergraphs are used for the
modeling of software architectures. Here, components are hyperedges and the commu-
General Information Specification and Transformation Notation Process and Tool Support
Characteristics
Approaches
Date of
Publica-
tions
Intention of the Ap-
proaches
Specification Formal-
ism (Special Charac-
teristics)
Transformation For-
malism (Special
Characteristics)
Selection and
Achievement
Test
Tool Support
T. Mens et al. 99, 00, 02,
03
Development of the
formal basics for the
evolution of object-
oriented Models
Hierarchical typed
hypergraphs
Hyper graph replace-
ment (SPO and DPO,
preconditions)
Limited
choice with
preconditions
Prototype
realized in
Fujaba
G. Taentzer 99, 01 Description of a visual
concept for the model-
ing and evolution of
distributed systems
Typed graphs Graph replacement
(distributed graph
transformations)
Prototype
realized in
AGG
D. Le Métayer 96, 98 Formalization of archi-
tecture styles by graph
grammars
Hypergraphs Proposition of Hyper
edge, Hyper graph
and node replacement
H. Fahmy, R. C. Holt 98, 00, 01 Improvement of the un-
derstandability of an
architecture specifica-
tion
Hierarchical typed
graphs +Tarski opera-
tions
Graph replacement
(SPO)
Prototype
realized in
PROGRES
M. Wermelinger 99, 01, 02 Formalization of the
dynamic architecture
reconfiguration at the
runtime of a system
Typed graphs Graph replacement
(DPO)
D. Hirsch et al. 99, 00 Reconfiguration of dis-
tributed systems under
retention of an architec-
ture style
Typed hyper graphs Hyper edge replace-
ment (SPO)
Table 1. Software evolution with hypergraphs: An overview
TEAM LinG

30 Grunske
nication between the components is modeled with nodes. As formalism for architecture
reconfiguration context-free hyperedge replacements are used.
Approach of H. Fahmy and R. C. Holt
The goal of the approach proposed in Holt (1998) and Fahmy and Holt (2000) is to reduce
the complexity and to improve the understandability of software architectures. For this
purpose, simple transformations are presented which predominantly improve the cou-
pling and binding. The transformations in Fahmy and Holt (2000) are specified as
conditional graph transformation rules and are realized prototypically in PROGESS. Holt
(1998) chooses a different approach for the representation of the same rules: the
architecture is specified as a graph with the classic, algebraic Tarski-operators. The
transformation of Holt’s architecture is described by algebraic relations realized by a
relation interpreter called GROK. The practical applicability of the approach is corrobo-
rated in Holt (1998) by several case studies (250-300 KLOC COBOL and C programs).
Approach of M. Wermelinger et al.
The study of Wermelinger, Lopes, and Fiadeiro (1999, 2001) aims at the formalization of
the dynamic architectural reconfiguration of a system at runtime. Distributed systems are
considered in particular. For the specification of architectures, an algebraic approach and
the architectural description language CommUnity are utilized. The possible modifica-
tions of the architecture at runtime are described by simple transformations. An example
of such transformations is the addition, removal, and refinement of components as well
as the assignment of communication variables. For the application of these trans-
formations the double-pushout approach of Ehrig (1979) is applied. Besides the simple
transformations in Wermelinger et al. (2001), a possibility is presented to design complex
transformations. These complex transformations use syntax constructs that are similar
to simple programming languages.
Summary of the Current Approaches
The current approaches as presented in Table 1 provide a good theoretical background
for the graph-based evolution of software specifications.
Nevertheless, the current approaches lack aspects that are necessary for the application
of graph-based architecture evolution in the process model presented in the introduc-
tion. These aspects are:
• An architectural description language that supports the quality improvement
process
TEAM LinG

• A set of transformation operators that improve quality characteristics without
changing the functional properties
• A tool that supports the (semi-) automatic application of the transformation
operators
To allow the utilization of graph-based architectural evolution, these aspects are
discussed in the following two sections.
Quality Improving Architecture
Evolution with the UML-RT
This section explains the basic concepts for the graph-based architectural evolution with
UML-RT. First, an introduction to UML-RT is given. Then, a mapping of the UML-RT
to a hypergraph-based data structure and an annotation with modular analysis models
for the evaluation of the relevant quality characteristics are presented. Based on this,
quality improving architectural transformations can be specified as hypergraph trans-
formation rules and applied (semi-) automatically.
Introduction to UML-RT
Due to the popularity in the industrial development of embedded systems, in this
approach, the UML-RT (Selic & Rumbaugh, 1998) is used as a modeling language for the
structure specification of a software intensive technical system. This modeling language
is based on the ROOM methodology developed by Selic, Gullekson, and Ward (1996) and
is suited to model architectural specifications as presented in Cheng and Garland (2001)
and Rumpe, Schoenmakers, Radermacher, and Schürr (1999).
To model architectural specifications with UML-RT, the following three principal
elements are needed:
• capsules
• ports (end-ports and relay-ports)
• connectors
The capsules are the main entities of the architectural specification. They encapsulate
the functional behavior and correspond to the ROOM concept of actors (Selic et al., 1996).
Furthermore, the capsules are concurrent objects, which are created based on capsule-
class definitions. These capsule-classes can also be defined as composites consisting
TEAM LinG

32 Grunske
of finer, more granular capsules. With respect to this, the hierarchical structure between
the capsules is defined by a (composition) hierarchy.
For communication with its environment, a capsule owns a set of interface objects. These
interface objects are called ports and describe the functional interfaces of a capsule.
Between the ports, point-to-point connections can be established that are used to send
messages or signals. These point-to-point connections are called connectors and
correspond to ROOM bindings (Selic & Rumbaugh, 1998). If a message is sent directly
to a component, the receiving port is called an end-port. To communicate with a capsule
inside a hierarchical capsule special ports are needed to forward a message from the
outside of a composite capsule to an inner capsule or in the opposite direction. These
ports are called relay-ports.
Mapping of UML-RT to Hierarchical-Typed
Hypergraphs
The mapping of the principal UML-RT elements to the elements of a hierarchical typed
hypergraph is presented with a type system in Figure 3. This type system contains two
meta-levels. The meta-level II describes the relevant elements of a hierarchical typed
hypergraph.
The meta-level I contains the metaclasses capsule, connector, end-port, and relay-
ports, needed to model architectures in the UML-RT.
The metaclass capsule is derived from the metaclass hypergraph and the metaclasses
end-port and relay-ports are derived from the metaclass node in the hypergraph
specification. Based on this, every capsule contains a finite set of ports, because of the
composition V in the hypergraph-meta-level. The metaclass connector is derived from
the metaclass hyperedge. Consequently, a connector can connect a set of ports to model
a communication connection between these ports.
Furthermore, the hypergraph-based structure specification distinguishes between flat
and hierarchical capsules. A flat capsule contains only one hyperedge. This hyperedge
relay port
end port
meta-level II (hypergraph)
node
hyperedge
complex
hyperedge
conector
capsule
att
cts
meta-level I (UML RT structure)
hypergraph *
*
1
* *
V
E
Figure 3. Mapping of the principal UML-RT elements to the elements of a hierarchical
typed hypergraph
TEAM LinG

is associated with all contained ports of the capsule. Hierarchical capsules can contain
a set of hyperedges. Some of these hyperedges can be complex and can contain other
capsules.
Level-Crossing Example
InFigure4,asimplifiedversionofacontrolsystemforalevelcrossingismodeledinUML-
RT, which is specified with a capsule called LevelCrossingControlSystem. This capsule
contains the capsules LevelCrossingControl, GateControl, TrainSignalControl,
GateSensorManager and TrainSensorManager. These capsules are not further decom-
posed. The LevelCrossingControl capsule is the controller of the level crossing system.
This capsule can send messages to the GateControl capsule to open or close the gates
and to the TrainSignalControl capsule to allow or deny the passage for an arriving train.
To get the information from the environment the LevelCrossingControl capsule utilizes
two sensors: One sensor determines the state of the gates, and the other detects an
arriving train and checks its progress through the level crossing section. These sensors
are controlled by the GateSensorManager and TrainSensorManager capsules.
Due to the mapping of the principal UML-RT elements to the elements of a hierarchical
typed hypergraph, as presented in the previous section, the specification of the
LevelCrossingControlSystem capsule is a hypergraph. This hypergraph contains a node
for each port. Thereby external ports are nodes of the type relay-port and all other ports
are of the type end-port. Additionally, the hypergraph contains a set of hyperedges.
These hyperedges are distinguished into hyperedges of the type connector that model
the communication-connections between the ports, and of the type hierarchical
hyperedge that contain the embedded capsules.
:LevelCrossingControl
:GateControl :GateSensorManger :TrainSignalControl :TrainSensor-
Manager
:LCGates :LCGateSensors :LCSignals
:LCTrainSensors
:GIntern
:GLC
:GSIntern
:SIntern
:TSIntern
:GSLC :SLC
:TSLC
:LevelCrossingControlSystem
:GExtern
:GSExtern
:SExtern
:TSExtern
Figure 4. Structure specification of the level crossing example
TEAM LinG

34 Grunske
Evaluation of Quality Characteristics
In the cyclic process presented in the introduction, software architectures must be
evaluated with an architecture evaluation method to prove that the system will meet its
quality requirements. For these evaluations, a set of analysis models must be integrated
into the presented structural specification.
For this purpose, the analysis models presented in Table 2 are used. These models
represent the state-of-the-art for each relevant quality characteristic (Birolini, 1999;
Douglas, 1999; Fenelon & McDermid, 1993; Gomaa, 2000; Liggesmeyer, 2000; Pumfrey,
1999).
For the annotation of the elements of the structural specification, these analysis models
are modularized as described in Papadopoulos, McDermid, Sasse, and Heiner (2001) and
extend the metaclass capsule. An analysis model for the complete software architecture
or a hierarchical capsule can be constructed with composition-based techniques accord-
ing to the composition hierarchy. To apply these techniques, a modular analysis model
only specifies the relevant aspects of the quality characteristics of an architectural
element and can be characterized by the following parts:
• a set of outputs
• a set of inputs
• a set of internal information
The set of outputs describes the effects of the architectural element on the quality
characteristics. As an example, in modular fault-trees, these outputs represent a set of
failures that can be produced by the capsule and their probabilities. For the calculation
of the outputs of a modular analysis model, the set of inputs and the internal information
must be considered. In a fault-tree the inputs describe external failures that can influence
the capsule. The internal information specifies the Boolean function that characterizes
the fault tree and the probability of internal elementary failures which can be determined
for an architectural element by expert knowledge or experimental studies (Birolini, 1999;
Liggesmeyer, 2000; Musa, Iannino, & Okumoto, 1987).
Quality characteristic Analysis model
Safety Fault-tree-model
Reliability, main-
tainability, availability
Fault-tree-model and
Markov chains
Temporal correctness Scheduling models
(RMA, EDFA) and
End-to-End analysis
Economic attributes Life-Cycle-Cost-
model
Table 2. Quality characteristics and relevant analysis models
TEAM LinG

Transformation Operators
A transformation operator describes in an abstract way the structural changes of
software architectures. These changes can be:
• the removal or the addition of architectural elements
• the redirection of a connection between the architectural elements
This section gives a graphical notation and describes how to specify a graph transfor-
mation rule with this graphical notation. Thereafter, four transformation operators are
presented that can be used to improve the quality characteristics of architectural
specifications. A more detailed description of the transformation operators and other
transformation operators can be found in Grunske (2003b).
Graphical Notation
A graphical notation is used for the representation of a transformation operator. This
notation is denoted as T-notation because it groups the architectural elements of an
operator into three parts, forming a T. The semantic of this notation implies that all
elements or connections on the bottom-left-side of the T must be removed from the
architecture. All elements or connections on the bottom-right-side of the T must be added
to the architecture. The elements above the T remain unaffected and serve as gluing
points between the rest of the architecture and the new added elements. This is the reason
why they are redundantly contained in the upper left and the upper right side.
An example for a transformational pattern in the T-notation is given in Figure 5. This
abstract operator shows that the capsules of type A and B, the two ports of type A, and
the connection between them must be removed. The ports (type A, B, and C) above the
T remain unaffected. They serve as gluing points for the component with type C. This
component must be added to the software architecture. The application of this pattern
is presented in Figure 6 for a concrete architecture.
Based on this graphical representation of the transformation operator, a graph transfor-
mation rule TO: GTO
L
←GTO
I
→GTO
R
can be created. In this graph transformation rule the left-
hand-side graph GTO
L
contains all COOL-elements in the bottom-left-side of the T. The
right-hand-side graph GTO
R
contains all COOL-elements in the bottom-right-side of the
T and the interface hypergraph GTO
I
is represented by the COOL-elements above the T.
:port C :port B
:port A
:port A
:component A :component B :component C
before after
:port C :port A :port B
:port A
Figure 5. Example of a transformational pattern in the T-notation
TEAM LinG

36 Grunske
Based on this graph transformation rule, a transformation operator can be applied
automatically to an architectural specification in COOL with the double pushout ap-
proach (Ehrig, 1979; Corradini et al., 1997).
Behavioral Equivalence
The automatic application of an architecture transformation operator requires a proof-
algorithm to verify the behavioral equivalence before and after the application of the
architectural transformation. Behavioral equivalence in this context means that the
system before and after the transformation responds in the same way to each possible
message trace that can be generated by the environment. Usually this is defined as trace
containment or trace equivalent.
To check the behavioral equivalence a proof algorithm should contain the following
steps:
1. Identify the part of the architecture that will be removed by the transformation
operator
2. Identify the part of the architecture that will be added by the transformation
operator
3. Construct for both parts the set of possible traces and check their equivalence
The removed part of the architecture can be constructed with the occurrence morphism
o : GL
→G and the hypergraph subtraction of the interface graph GI
from the left-hand-
side graph GL
as follows o(GL
–GI
). The added part to the architecture o''(GR
–GI
) can be
similarly constructed with the morphism o'' : GR
→G'.
The proof of trace equivalence of both parts is a complex problem that is extensively
discussed for state charts in Harel and Kupferman (2002). For the behavioral specification
with interface automata, a further proof of trace equivalence is presented in Grunske
(2003a). These interface automata as proposed in de Alfaro and Henzinger (2001) are
simpler than statecharts because they have no hierarchical states and no history states.
after
:component C
:component A
:port C
:port A
:component D
:port A
:port C
:port B
:port A
:port C
:port B
:port A
:component A
:component B
:port A
:port A
before
:component A
:port C
:port A
:component D
:port A
Figure 6. Example of the application of a transformational pattern
TEAM LinG

Multi Channel Redundancy with Voting
The first transformation operator we want to present is called Multi Channel Redundancy
with Voting. The idea of this transformation operator is to replace a capsule that does
not fulfill its safety, availability, or reliability requirements by multiple capsules on
different hardware platforms and a comparator (m-out-of-v voter) that gets the inputs from
the environment and generates multiple messages for the redundant capsules (Figure 7).
Based on these messages, the capsules compute the results and send them back to the
comparator, which in turn chooses the message to be sent to the environment by a
majority voting. For the realization of this pattern, often three components and a two-out-
of-three voting are used (Douglass, 1999, 2002). Due to the structure, random and single
point failures of the hardware platforms can be detected if homogeneous software
components are used. Thus, the reliability of the system will be improved if the hardware
platform of the comparator is more reliable than the hardware platforms of the redundant
capsules.
This operator also can be used to protect against systematic failures. Therefore, different
development teams must heterogeneously implement the redundant capsules. This will
reduce the probability that a systematic error in one component will affect the rest of the
system (Mitra, Saxena, & McCluskey, 1999). However, Knight and Leveson (1986) point
out that a diverse implementation does not detect all systematic errors, because different
development teams made similar faults, and therefore the different versions do not fail
independently.
v:voter
c:component
:port
c2:component
before after
c1:component cv:component
:port
:port
:port :port :port
Figure 7. Transformation operator: Multi Channel Redundancy with Voting
cv1:validation
:component
:port
cv2:validation
c2:component
before after
:switch to
backup
c1:component
:integrity
test
:integrity
test
:port :port
:port
:port
Figure 8. Transformation operator: Two Channel Redundancy
TEAM LinG

38 Grunske
Two Channel Redundancy
The transformation operator Two Channel Redundancy is similar to the transformation
operator Multi Channel Redundancy with Voting. This operator replaces a capsule with
two redundant channels operating in parallel on different hardware platforms (Figure 8).
One channel consists of a redundant capsule of the replaced type and a capsule that is
called channel validation. Both channels are getting all information from the environ-
ment, but one of them is active and one is passive. The active channel checks its operation
with a channel validation capsule. The results of this validation are sent to the channel
validation capsules of the passive channel via the connection between the switch to
backup ports. If a failure occurs, an error is detected, or if the active channel omits to send
the results, the passive channel becomes active. In this case, the former active channel
must be informed. To check the correct operation of one channel the utilization of several
strategies are possible (Grunske, 03b). By the application of this pattern, one channel can
be still available in case of random or wear-out failures of the hardware platform of the
other channel. Thus, availability can be increased by the application of this transforma-
tion operator.
Recovery Block
The transformation operator Recovery Block uses a concept developed by Randell (1975)
and Randell and Xu (1995). The basic idea of this operator is to use multiple heteroge-
neously developed capsules operating in parallel on a single hardware platform (see
Figure 9). All capsules are getting information from the environment, but one of them is
the primary capsule and the others are backup capsules. The primary capsule performs
the desired operations that are checked by an acceptance test capsule. The acceptance
test capsule checks the primary capsule itself to detect errors. If it detects an error or a
failure, the primary capsule becomes one of the backup capsules, and the next capsule
in the backup pool becomes the primary capsule. To obtain protection from failures
caused by systematic errors, the capsules must fail independently. For this, different
development teams should implement these capsules (Avizienis, 1985).
Figure 9. Transformation operator: Recovery Block
cv:component
:acceptance test
:component
:port
c2
:component
before after
cn:component
:port
:port
:integrity
test
TEAM LinG

Process Fusion
The Process Fusion operator should be applied if an architecture specification contains
a large number of active capsules (tasks or processes), which are processed and
scheduled on a single hardware platform; the time to switch between these capsules
(redirect the program counter, save and restore the registers, swap the cache pages) is
high. This can have a negative effect on the temporal correctness. Therefore, the
transformation operator merges two capsules into a new one, which acts like the two
processes did before (see Figure 10). This will lead to scheduling, where task switching
does not occur as often as before. As a result, the new components will have a better
chance to meet their deadlines.
Tool Support
To support the architectural evolution process, a tool called Balance was developed.
This tool is introduced next.
Short Description of Balance
Balance can be used to model architectural specifications in UML-RT. These specifica-
tions can be directly designed by the user, or they can be extracted from a commercial
tool like IBM/Rational Rose RT.
To further apply the graph-based architectural evolution process, the following steps
must be taken:
• The architectural elements must be annotated with modular evaluation models for
the relevant quality characteristics.
• The quality requirements must be specified.
With this information, the tool evaluates the quality characteristics of the system and
proposes a set of transformation operators that will improve the architecture. The
proposed transformation operators can be applied (semi-) automatically because they are
specified as hypergraph transformation rules.
Figure 10. Transformation operator: Process Fusion
x1:component x2:component x:component
before after
:port
:port
:port
:port
TEAM LinG

Exploring the Variety of Random
Documents with Different Content

Now behold the solitary Perkins adrift in the storm of fighting, even
as a champagne jacket of straw is lost in a great surf. He found it
out quickly. Four seconds elapsed before he discovered that he was
an almshouse idiot plunging through hot, crackling thickets on a
June morning in Cuba. Sss-s-swing-sing-ing-pop went the lightning-
swift metal grasshoppers over him and beside him. The beauties of
rural Minnesota illuminated his conscience with the gold of lazy corn,
with the sleeping green of meadows, with the cathedral gloom of
pine forests. Sshsh-swing-pop! Perkins decided that if he cared to
extract himself from a tangle of imbecility he must shoot. The entire
situation was that he must shoot. It was necessary that he should
shoot. Nothing would save him but shooting. It is a law that men
thus decide when the waters of battle close over their minds. So
with a prayer that the Americans would not hit him in the back nor
the left side, and that the Spaniards would not hit him in the front,
he knelt like a supplicant alone in the desert of chaparral, and
emptied his magazine at his Spaniard before he discovered that his
Spaniard was a bit of dried palm branch.
Then Perkins flurried like a fish. His reason for being was a Spaniard
in the bush. When the Spaniard turned into a dried palm branch, he
could no longer furnish himself with one adequate reason.
Then did he dream frantically of some anthracite hiding-place, some
profound dungeon of peace where blind mules live placidly chewing
the far-gathered hay.
"Sss-swing-win-pop! Prut-prut-prrrut!" Then a field-gun spoke.
"Boom-ra-swow-ow-ow-ow-pum." Then a Colt automatic began to
bark. "Crack-crk-crk-crk-crk-crk" endlessly. Raked, enfiladed, flanked,
surrounded, and overwhelmed, what hope was there for William B.
Perkins of the "Minnesota Herald?"
But war is a spirit. War provides for those that it loves. It provides
sometimes death and sometimes a singular and incredible safety.

There were few ways in which it was possible to preserve Perkins.
One way was by means of a steam-boiler.
Perkins espied near him an old, rusty steam-boiler lying in the
bushes. War only knows how it was there, but there it was, a temple
shining resplendent with safety. With a moan of haste, Perkins flung
himself through that hole which expressed the absence of the
steam-pipe.
Then ensconced in his boiler, Perkins comfortably listened to the ring
of a fight which seemed to be in the air above him. Sometimes
bullets struck their strong, swift blow against the boiler's sides, but
none entered to interfere with Perkins's rest.
Time passed. The fight, short anyhow, dwindled to prut … prut …
prut-prut … prut. And when the silence came, Perkins might have
been seen cautiously protruding from the boiler. Presently he strolled
back toward the marine lines with his hat not able to fit his head for
the new bumps of wisdom that were on it.
The marines, with an annoyed air, were settling down again when an
apparitional figure came from the bushes. There was great
excitement.
"It's that crazy man," they shouted, and as he drew near they
gathered tumultuously about him and demanded to know how he
had accomplished it.
Perkins made a gesture, the gesture of a man escaping from an
unintentional mud-bath, the gesture of a man coming out of battle,
and then he told them.
The incredulity was immediate and general. "Yes, you did! What? In
an old boiler? An old boiler? Out in that brush? Well, we guess not."
They did not believe him until two days later, when a patrol
happened to find the rusty boiler, relic of some curious transaction in

the ruin of the Cuban sugar industry. The patrol then marvelled at
the truthfulness of war-correspondents until they were almost blind.
Soon after his adventure Perkins boarded the tug, wearing a
countenance of poignant thoughtfulness.

THE CLAN OF NO-NAME
Unwind my riddle.
Cruel as hawks the hours fly;
Wounded men seldom come home to die;
The hard waves see an arm flung high;
Scorn hits strong because of a lie;
Yet there exists a mystic tie.
Unwind my riddle.
She was out in the garden. Her mother came to her rapidly.
"Margharita! Margharita, Mister Smith is here! Come!" Her mother
was fat and commercially excited. Mister Smith was a matter of
some importance to all Tampa people, and since he was really in
love with Margharita he was distinctly of more importance to this
particular household.
Palm trees tossed their sprays over the fence toward the rutted sand
of the street. A little foolish fish-pond in the centre of the garden
emitted a sound of red-fins flipping, flipping. "No, mamma," said the
girl, "let Mr. Smith wait. I like the garden in the moonlight."
Her mother threw herself into that state of virtuous astonishment
which is the weapon of her kind. "Margharita!"
The girl evidently considered herself to be a privileged belle, for she
answered quite carelessly, "Oh, let him wait."
The mother threw abroad her arms with a semblance of great high-
minded suffering and withdrew. Margharita walked alone in the
moonlit garden. Also an electric light threw its shivering gleam over
part of her parade.

There was peace for a time. Then suddenly through the faint brown
palings was struck an envelope white and square. Margharita
approached this envelope with an indifferent stride. She hummed a
silly air, she bore herself casually, but there was something that
made her grasp it hard, a peculiar muscular exhibition, not
discernible to indifferent eyes. She did not clutch it, but she took it—
simply took it in a way that meant everything, and, to measure it by
vision, it was a picture of the most complete disregard.
She stood straight for a moment; then she drew from her bosom a
photograph and thrust it through the palings. She walked rapidly
into the house.
II
A man in garb of blue and white—something relating to what we call
bed-ticking—was seated in a curious little cupola on the top of a
Spanish blockhouse. The blockhouse sided a white military road that
curved away from the man's sight into a blur of trees. On all sides of
him were fields of tall grass, studded with palms and lined with
fences of barbed wire. The sun beat aslant through the trees and
the man sped his eyes deep into the dark tropical shadows that
seemed velvet with coolness. These tranquil vistas resembled
painted scenery in a theatre, and, moreover, a hot, heavy silence lay
upon the land.
The soldier in the watching place leaned an unclean Mauser rifle in a
corner, and, reaching down, took a glowing coal on a bit of palm
bark handed up to him by a comrade. The men below were mainly
asleep. The sergeant in command drowsed near the open door, the
arm above his head, showing his long keen-angled chevrons
attached carelessly with safety-pins. The sentry lit his cigarette and
puffed languorously.

Suddenly he heard from the air around him the querulous, deadly-
swift spit of rifle-bullets, and, an instant later, the poppety-pop of a
small volley sounded in his face, close, as if it were fired only ten
feet away. Involuntarily he threw back his head quickly as if he were
protecting his nose from a falling tile. He screamed an alarm and fell
into the blockhouse. In the gloom of it, men with their breaths
coming sharply between their teeth, were tumbling wildly for
positions at the loop-holes. The door had been slammed, but the
sergeant lay just within, propped up as when he drowsed, but now
with blood flowing steadily over the hand that he pressed flatly to
his chest. His face was in stark yellow agony; he chokingly repeated:
"Fuego! Por Dios, hombres!"
The men's ill-conditioned weapons were jammed through the loop-
holes and they began to fire from all four sides of the blockhouse
from the simple data, apparently, that the enemy were in the
vicinity. The fumes of burnt powder grew stronger and stronger in
the little square fortress. The rattling of the magazine locks was
incessant, and the interior might have been that of a gloomy
manufactory if it were not for the sergeant down under the feet of
the men, coughing out: "Por Dios, hombres! Por Dios! Fuego!"
III
A string of five Cubans, in linen that had turned earthy brown in
colour, slid through the woods at a pace that was neither a walk nor
a run. It was a kind of rack. In fact the whole manner of the men, as
they thus moved, bore a rather comic resemblance to the American
pacing horse. But they had come many miles since sun-up over
mountainous and half-marked paths, and were plainly still fresh. The
men were all practicos—guides. They made no sound in their swift
travel, but moved their half-shod feet with the skill of cats. The
woods lay around them in a deep silence, such as one might find at
the bottom of a lake.

Suddenly the leading practico raised his hand. The others pulled up
short and dropped the butts of their weapons calmly and noiselessly
to the ground. The leader whistled a low note and immediately
another practico appeared from the bushes. He moved close to the
leader without a word, and then they spoke in whispers.
"There are twenty men and a sergeant in the blockhouse."
"And the road?"
"One company of cavalry passed to the east this morning at seven
o'clock. They were escorting four carts. An hour later, one horseman
rode swiftly to the westward. About noon, ten infantry soldiers with
a corporal were taken from the big fort and put in the first
blockhouse, to the east of the fort. There were already twelve men
there. We saw a Spanish column moving off toward Mariel."
"No more?"
"No more."
"Good. But the cavalry?"
"It is all right. They were going a long march."
"The expedition is a half league behind. Go and tell the general."
The scout disappeared. The five other men lifted their guns and
resumed their rapid and noiseless progress. A moment later no
sound broke the stillness save the thump of a mango, as it dropped
lazily from its tree to the grass. So strange had been the apparition
of these men, their dress had been so allied in colour to the soil,
their passing had so little disturbed the solemn rumination of the
forest, and their going had been so like a spectral dissolution, that a
witness could have wondered if he dreamed.

IV
A small expedition had landed with arms from the United States, and
had now come out of the hills and to the edge of a wood. Before
them was a long-grassed rolling prairie marked with palms. A half-
mile away was the military road, and they could see the top of a
blockhouse. The insurgent scouts were moving somewhere off in the
grass. The general sat comfortably under a tree, while his staff of
three young officers stood about him chatting. Their linen clothing
was notable from being distinctly whiter than those of the men who,
one hundred and fifty in number, lay on the ground in a long brown
fringe, ragged—indeed, bare in many places—but singularly
reposeful, unworried, veteran-like.
The general, however, was thoughtful. He pulled continually at his
little thin moustache. As far as the heavily patrolled and guarded
military road was concerned, the insurgents had been in the habit of
dashing across it in small bodies whenever they pleased, but to
safely scoot over it with a valuable convoy of arms, was decidedly a
more important thing. So the general awaited the return of his
practicos with anxiety. The still pampas betrayed no sign of their
existence.
The general gave some orders and an officer counted off twenty
men to go with him, and delay any attempt of the troop of cavalry to
return from the eastward. It was not an easy task, but it was a
familiar task—checking the advance of a greatly superior force by a
very hard fire from concealment. A few rifles had often bayed a
strong column for sufficient length of time for all strategic purposes.
The twenty men pulled themselves together tranquilly. They looked
quite indifferent. Indeed, they had the supremely casual manner of
old soldiers, hardened to battle as a condition of existence.

Thirty men were then told off, whose function it was to worry and
rag at the blockhouse, and check any advance from the westward. A
hundred men, carrying precious burdens—besides their own
equipment—were to pass in as much of a rush as possible between
these two wings, cross the road and skip for the hills, their retreat
being covered by a combination of the two firing parties. It was a
trick that needed both luck and neat arrangement. Spanish columns
were for ever prowling through this province in all directions and at
all times. Insurgent bands—the lightest of light infantry—were kept
on the jump, even when they were not incommoded by fifty boxes,
each one large enough for the coffin of a little man, and heavier
than if the little man were in it; and fifty small but formidable boxes
of ammunition.
The carriers stood to their boxes and the firing parties leaned on
their rifles. The general arose and strolled to and fro, his hands
behind him. Two of his staff were jesting at the third, a young man
with a face less bronzed, and with very new accoutrements. On the
strap of his cartouche were a gold star and a silver star, placed in a
horizontal line, denoting that he was a second lieutenant. He
seemed very happy; he laughed at all their jests, although his eye
roved continually over the sunny grass-lands, where was going to
happen his first fight. One of his stars was bright, like his hopes, the
other was pale, like death.
Two practicos came racking out of the grass. They spoke rapidly to
the general; he turned and nodded to his officers. The two firing
parties filed out and diverged toward their positions. The general
watched them through his glasses. It was strange to note how soon
they were dim to the unaided eye. The little patches of brown in the
green grass did not look like men at all.
Practicos continually ambled up to the general. Finally he turned and
made a sign to the bearers. The first twenty men in line picked up
their boxes, and this movement rapidly spread to the tail of the line.

The weighted procession moved painfully out upon the sunny
prairie. The general, marching at the head of it, glanced continually
back as if he were compelled to drag behind him some ponderous
iron chain. Besides the obvious mental worry, his face bore an
expression of intense physical strain, and he even bent his
shoulders, unconsciously tugging at the chain to hurry it through this
enemy-crowded valley.
V
The fight was opened by eight men who, snuggling in the grass,
within three hundred yards of the blockhouse, suddenly blazed away
at the bed-ticking figure in the cupola and at the open door where
they could see vague outlines. Then they laughed and yelled
insulting language, for they knew that as far as the Spaniards were
concerned, the surprise was as much as having a diamond bracelet
turn to soap. It was this volley that smote the sergeant and caused
the man in the cupola to scream and tumble from his perch.
The eight men, as well as all other insurgents within fair range, had
chosen good positions for lying close, and for a time they let the
blockhouse rage, although the soldiers therein could occasionally
hear, above the clamour of their weapons, shrill and almost wolfish
calls, coming from men whose lips were laid against the ground. But
it is not in the nature of them of Spanish blood, and armed with
rifles, to long endure the sight of anything so tangible as an enemy's
blockhouse without shooting at it—other conditions being partly
favourable. Presently the steaming soldiers in the little fort could
hear the sping and shiver of bullets striking the wood that guarded
their bodies.
A perfectly white smoke floated up over each firing Cuban, the
penalty of the Remington rifle, but about the blockhouse there was
only the lightest gossamer of blue. The blockhouse stood always for

some big, clumsy and rather incompetent animal, while the
insurgents, scattered on two sides of it, were little enterprising
creatures of another species, too wise to come too near, but joyously
raging at its easiest flanks and drilling the lead into its sides in a way
to make it fume, and spit and rave like the tom-cat when the glad,
free-band fox-hound pups catch him in the lane.
The men, outlying in the grass, chuckled deliriously at the fury of the
Spanish fire. They howled opprobrium to encourage the Spaniards to
fire more ill-used, incapable bullets. Whenever an insurgent was
about to fire, he ordinarily prefixed the affair with a speech. "Do you
want something to eat? Yes? All right." Bang! "Eat that." The more
common expressions of the incredibly foul Spanish tongue were
trifles light as air in this badinage, which was shrieked out from the
grass during the spin of bullets, and the dull rattle of the shooting.
But at some time there came a series of sounds from the east that
began in a few disconnected pruts and ended as if an amateur was
trying to play the long roll upon a muffled drum. Those of the
insurgents in the blockhouse attacking party, who had neighbours in
the grass, turned and looked at them seriously. They knew what the
new sound meant. It meant that the twenty men who had gone to
the eastward were now engaged. A column of some kind was
approaching from that direction, and they knew by the clatter that it
was a solemn occasion.
In the first place, they were now on the wrong side of the road.
They were obliged to cross it to rejoin the main body, provided of
course that the main body succeeded itself in crossing it. To
accomplish this, the party at the blockhouse would have to move to
the eastward, until out of sight or good range of the maddened little
fort. But judging from the heaviness of the firing, the party of twenty
who protected the east were almost sure to be driven immediately
back. Hence travel in that direction would become exceedingly
hazardous. Hence a man looked seriously at his neighbour. It might

easily be that in a moment they were to become an isolated force
and woefully on the wrong side of the road.
Any retreat to the westward was absurd, since primarily they would
have to widely circle the blockhouse, and more than that, they could
hear, even now in that direction, Spanish bugle calling to Spanish
bugle, far and near, until one would think that every man in Cuba
was a trumpeter, and had come forth to parade his talent.
VI
The insurgent general stood in the middle of the road gnawing his
lips. Occasionally, he stamped a foot and beat his hands passionately
together. The carriers were streaming past him, patient, sweating
fellows, bowed under their burdens, but they could not move fast
enough for him when others of his men were engaged both to the
east and to the west, and he, too, knew from the sound that those
to the east were in a sore way. Moreover, he could hear that
accursed bugling, bugling, bugling in the west.
He turned suddenly to the new lieutenant who stood behind him,
pale and quiet. "Did you ever think a hundred men were so many?"
he cried, incensed to the point of beating them. Then he said
longingly: "Oh, for a half an hour! Or even twenty minutes!"
A practico racked violently up from the east. It is characteristic of
these men that, although they take a certain roadster gait and hold
it for ever, they cannot really run, sprint, race. "Captain Rodriguez is
attacked by two hundred men, señor, and the cavalry is behind
them. He wishes to know——"
The general was furious; he pointed. "Go! Tell Rodriguez to hold his
place for twenty minutes, even if he leaves every man dead."
The practico shambled hastily off.

The last of the carriers were swarming across the road. The rifle-
drumming in the east was swelling out and out, evidently coming
slowly nearer. The general bit his nails. He wheeled suddenly upon
the young lieutenant. "Go to Bas at the blockhouse. Tell him to hold
the devil himself for ten minutes and then bring his men out of that
place."
The long line of bearers was crawling like a dun worm toward the
safety of the foot-hills. High bullets sang a faint song over the aide
as he saluted. The bugles had in the west ceased, and that was
more ominous than bugling. It meant that the Spanish troops were
about to march, or perhaps that they had marched.
The young lieutenant ran along the road until he came to the bend
which marked the range of sight from the blockhouse. He drew his
machete, his stunning new machete, and hacked feverishly at the
barbed wire fence which lined the north side of the road at that
point. The first wire was obdurate, because it was too high for his
stroke, but two more cut like candy, and he stepped over the
remaining one, tearing his trousers in passing on the lively
serpentine ends of the severed wires. Once out in the field and
bullets seemed to know him and call for him and speak their wish to
kill him. But he ran on, because it was his duty, and because he
would be shamed before men if he did not do his duty, and because
he was desolate out there all alone in the fields with death.
A man running in this manner from the rear was in immensely
greater danger than those who lay snug and close. But he did not
know it. He thought because he was five hundred—four hundred
and fifty—four hundred yards away from the enemy and the others
were only three hundred yards away that they were in far more
peril. He ran to join them because of his opinion. He did not care to
do it, but he thought that was what men of his kind would do in
such a case. There was a standard and he must follow it, obey it,
because it was a monarch, the Prince of Conduct.

A bewildered and alarmed face raised itself from the grass and a
voice cried to him: "Drop, Manolo! Drop! Drop!" He recognised Bas
and flung himself to the earth beside him.
"Why," he said panting, "what's the matter?"
"Matter?" said Bas. "You are one of the most desperate and careless
officers I know. When I saw you coming I wouldn't have given a
peseta for your life."
"Oh, no," said the young aide. Then he repeated his orders rapidly.
But he was hugely delighted. He knew Bas well; Bas was a pupil of
Maceo; Bas invariably led his men; he never was a mere spectator of
their battle; he was known for it throughout the western end of the
island. The new officer had early achieved a part of his ambition—to
be called a brave man by established brave men.
"Well, if we get away from here quickly it will be better for us," said
Bas, bitterly. "I've lost six men killed, and more wounded. Rodriguez
can't hold his position there, and in a little time more than a
thousand men will come from the other direction."
He hissed a low call, and later the young aide saw some of the men
sneaking off with the wounded, lugging them on their backs as
porters carry sacks. The fire from the blockhouse had become a-
weary, and as the insurgent fire also slackened, Bas and the young
lieutenant lay in the weeds listening to the approach of the eastern
fight, which was sliding toward them like a door to shut them off.
Bas groaned. "I leave my dead. Look there." He swung his hand in a
gesture and the lieutenant looking saw a corpse. He was not stricken
as he expected; there was very little blood; it was a mere thing.
"Time to travel," said Bas suddenly. His imperative hissing brought
his men near him; there were a few hurried questions and answers;
then, characteristically, the men turned in the grass, lifted their
rifles, and fired a last volley into the blockhouse, accompanying it

with their shrill cries. Scrambling low to the ground, they were off in
a winding line for safety. Breathing hard, the lieutenant stumbled his
way forward. Behind him he could hear the men calling each to
each: "Segue! Segue! Segue! Go on! Get out! Git!" Everybody
understood that the peril of crossing the road was compounding
from minute to minute.
VII
When they reached the gap through which the expedition had
passed, they fled out upon the road like scared wild-fowl tracking
along a sea-beach. A cloud of blue figures far up this dignified
shaded avenue, fired at once. The men already had begun to laugh
as they shied one by one across the road. "Segue! Segue!" The hard
part for the nerves had been the lack of information of the amount
of danger. Now that they could see it, they accounted it all the more
lightly for their previous anxiety.
Over in the other field, Bas and the young lieutenant found
Rodriguez, his machete in one hand, his revolver in the other, smoky,
dirty, sweating. He shrugged his shoulders when he saw them and
pointed disconsolately to the brown thread of carriers moving toward
the foot-hills. His own men were crouched in line just in front of him
blazing like a prairie fire.
Now began the fight of a scant rear-guard to hold back the pressing
Spaniards until the carriers could reach the top of the ridge, a mile
away. This ridge by the way was more steep than any roof; it
conformed, more, to the sides of a French war-ship. Trees grew
vertically from it, however, and a man burdened only with his rifle
usually pulled himself wheezingly up in a sort of ladder-climbing
process, grabbing the slim trunks above him. How the loaded
carriers were to conquer it in a hurry, no one knew. Rodriguez

shrugged his shoulders as one who would say with philosophy,
smiles, tears, courage: "Isn't this a mess!"
At an order, the men scattered back for four hundred yards with the
rapidity and mystery of a handful of pebbles flung in the night. They
left one behind who cried out, but it was now a game in which some
were sure to be left behind to cry out.
The Spaniards deployed on the road and for twenty minutes
remained there pouring into the field such a fire from their
magazines as was hardly heard at Gettysburg. As a matter of truth
the insurgents were at this time doing very little shooting, being
chary of ammunition. But it is possible for the soldier to confuse
himself with his own noise and undoubtedly the Spanish troops
thought throughout their din that they were being fiercely engaged.
Moreover, a firing-line—particularly at night or when opposed to a
hidden foe—is nothing less than an emotional chord, a chord of a
harp that sings because a puff of air arrives or when a bit of down
touches it. This is always true of new troops or stupid troops and
these troops were rather stupid troops. But, the way in which they
mowed the verdure in the distance was a sight for a farmer.
Presently the insurgents slunk back to another position where they
fired enough shots to stir again the Spaniards into an opinion that
they were in a heavy fight. But such a misconception could only
endure for a number of minutes. Presently it was plain that the
Spaniards were about to advance and, moreover, word was brought
to Rodriguez that a small band of guerillas were already making an
attempt to worm around the right flank. Rodriguez cursed
despairingly; he sent both Bas and the young lieutenant to that end
of the line to hold the men to their work as long as possible.
In reality the men barely needed the presence of their officers. The
kind of fighting left practically everything to the discretion of the
individual and they arrived at concert of action mainly because of
the equality of experience, in the wisdoms of bushwhacking.

The yells of the guerillas could plainly be heard and the insurgents
answered in kind. The young lieutenant found desperate work on
the right flank. The men were raving mad with it, babbling, tearful,
almost frothing at the mouth. Two terrible bloody creatures passed
him, creeping on all fours, and one in a whimper was calling upon
God, his mother, and a saint. The guerillas, as effectually concealed
as the insurgents, were driving their bullets low through the smoke
at sight of a flame, a movement of the grass or sight of a patch of
dirty brown coat. They were no column-o'-four soldiers; they were
as slinky and snaky and quick as so many Indians. They were,
moreover, native Cubans and because of their treachery to the one-
star flag, they never by any chance received quarter if they fell into
the hands of the insurgents. Nor, if the case was reversed, did they
ever give quarter. It was life and life, death and death; there was no
middle ground, no compromise. If a man's crowd was rapidly
retreating and he was tumbled over by a slight hit, he should curse
the sacred graves that the wound was not through the precise
centre of his heart. The machete is a fine broad blade but it is not so
nice as a drilled hole in the chest; no man wants his death-bed to be
a shambles. The men fighting on the insurgents' right knew that if
they fell they were lost.
On the extreme right, the young lieutenant found five men in a little
saucer-like hollow. Two were dead, one was wounded and staring
blankly at the sky and two were emptying hot rifles furiously. Some
of the guerillas had snaked into positions only a hundred yards away.
The young man rolled in among the men in the saucer. He could
hear the barking of the guerillas and the screams of the two
insurgents. The rifles were popping and spitting in his face, it
seemed, while the whole land was alive with a noise of rolling and
drumming. Men could have gone drunken in all this flashing and
flying and snarling and din, but at this time he was very deliberate.
He knew that he was thrusting himself into a trap whose door, once
closed, opened only when the black hand knocked and every part of

him seemed to be in panic-stricken revolt. But something controlled
him; something moved him inexorably in one direction; he perfectly
understood but he was only sad, sad with a serene dignity, with the
countenance of a mournful young prince. He was of a kind—that
seemed to be it—and the men of his kind, on peak or plain, from the
dark northern ice-fields to the hot wet jungles, through all wine and
want, through all lies and unfamiliar truth, dark or light, the men of
his kind were governed by their gods, and each man knew the law
and yet could not give tongue to it, but it was the law and if the
spirits of the men of his kind were all sitting in critical judgment
upon him even then in the sky, he could not have bettered his
conduct; he needs must obey the law and always with the law there
is only one way. But from peak and plain, from dark northern ice-
fields and hot wet jungles, through wine and want, through all lies
and unfamiliar truth, dark or light, he heard breathed to him the
approval and the benediction of his brethren.
He stooped and gently took a dead man's rifle and some cartridges.
The battle was hurrying, hurrying, hurrying, but he was in no haste.
His glance caught the staring eye of the wounded soldier, and he
smiled at him quietly. The man—simple doomed peasant—was not of
his kind, but the law on fidelity was clear.
He thrust a cartridge into the Remington and crept up beside the
two unhurt men. Even as he did so, three or four bullets cut so close
to him that all his flesh tingled. He fired carefully into the smoke.
The guerillas were certainly not now more than fifty yards away.
He raised him coolly for his second shot, and almost instantly it was
as if some giant had struck him in the chest with a beam. It whirled
him in a great spasm back into the saucer. As he put his two hands
to his breast, he could hear the guerillas screeching exultantly, every
throat vomiting forth all the infamy of a language prolific in the
phrasing of infamy.

One of the other men came rolling slowly down the slope, while his
rifle followed him, and, striking another rifle, clanged out. Almost
immediately the survivor howled and fled wildly. A whole volley
missed him and then one or more shots caught him as a bird is
caught on the wing.
The young lieutenant's body seemed galvanised from head to foot.
He concluded that he was not hurt very badly, but when he tried to
move he found that he could not lift his hands from his breast. He
had turned to lead. He had had a plan of taking a photograph from
his pocket and looking at it.
There was a stir in the grass at the edge of the saucer, and a man
appeared there, looking where lay the four insurgents. His negro
face was not an eminently ferocious one in its lines, but now it was
lit with an illimitable blood-greed. He and the young lieutenant
exchanged a singular glance; then he came stepping eagerly down.
The young lieutenant closed his eyes, for he did not want to see the
flash of the machete.
VIII
The Spanish colonel was in a rage, and yet immensely proud;
immensely proud, and yet in a rage of disappointment. There had
been a fight and the insurgents had retreated leaving their dead, but
still a valuable expedition had broken through his lines and escaped
to the mountains. As a matter of truth, he was not sure whether to
be wholly delighted or wholly angry, for well he knew that the
importance lay not so much in the truthful account of the action as it
did in the heroic prose of the official report, and in the fight itself lay
material for a purple splendid poem. The insurgents had run away;
no one could deny it; it was plain even to whatever privates had
fired with their eyes shut. This was worth a loud blow and splutter.
However, when all was said and done, he could not help but reflect

that if he had captured this expedition, he would have been a
brigadier-general, if not more.
He was a short, heavy man with a beard, who walked in a manner
common to all elderly Spanish officers, and to many young ones;
that is to say, he walked as if his spine was a stick and a little longer
than his body; as if he suffered from some disease of the backbone,
which allowed him but scant use of his legs. He toddled along the
road, gesticulating disdainfully and muttering: "Ca! Ca! Ca!"
He berated some soldiers for an immaterial thing, and as he
approached the men stepped precipitately back as if he were a fire-
engine. They were most of them young fellows, who displayed,
when under orders, the manner of so many faithful dogs. At present,
they were black, tongue-hanging, thirsty boys, bathed in the
nervous weariness of the after-battle time.
Whatever he may truly have been in character, the colonel closely
resembled a gluttonous and libidinous old pig, filled from head to
foot with the pollution of a sinful life. "Ca!" he snarled, as he
toddled. "Ca! Ca!" The soldiers saluted as they backed to the side of
the road. The air was full of the odour of burnt rags. Over on the
prairie guerillas and regulars were rummaging the grass. A few
unimportant shots sounded from near the base of the hills.
A guerilla, glad with plunder, came to a Spanish captain. He held in
his hand a photograph. "Mira, señor. I took this from the body of an
officer whom I killed machete to machete."
The captain shot from the corner of his eye a cynical glance at the
guerilla, a glance which commented upon the last part of the
statement. "M-m-m," he said. He took the photograph and gazed
with a slow faint smile, the smile of a man who knows bloodshed
and homes and love, at the face of a girl. He turned the photograph
presently, and on the back of it was written: "One lesson in English I

will give you—this: I love you, Margharita." The photograph had
been taken in Tampa.
The officer was silent for a half-minute, while his face still wore the
slow faint smile. "Pobrecetto," he murmured finally, with a
philosophic sigh, which was brother to a shrug. Without deigning a
word to the guerilla he thrust the photograph in his pocket and
walked away.
High over the green earth, in the dizzy blue heights, some great
birds were slowly circling with down-turned beaks.
IX
Margharita was in the gardens. The blue electric rays shone through
the plumes of the palm and shivered in feathery images on the walk.
In the little foolish fish-pond some stalwart fish was apparently
bullying the others, for often there sounded a frantic splashing.
Her mother came to her rapidly. "Margharita! Mister Smith is here!
Come!"
"Oh, is he?" cried the girl. She followed her mother to the house.
She swept into the little parlor with a grand air, the egotism of a
savage. Smith had heard the whirl of her skirts in the hall, and his
heart, as usual, thumped hard enough to make him gasp. Every time
he called, he would sit waiting with the dull fear in his breast that
her mother would enter and indifferently announce that she had
gone up to heaven or off to New York, with one of his dream-rivals,
and he would never see her again in this wide world. And he would
conjure up tricks to then escape from the house without any one
observing his face break up into furrows. It was part of his love to
believe in the absolute treachery of his adored one. So whenever he
heard the whirl of her skirts in the hall he felt that he had again
leased happiness from a dark fate.

She was rosily beaming and all in white. "Why, Mister Smith," she
exclaimed, as if he was the last man in the world she expected to
see.
"Good-evenin'," he said, shaking hands nervously. He was always
awkward and unlike himself, at the beginning of one of these calls. It
took him some time to get into form.
She posed her figure in operatic style on a chair before him, and
immediately galloped off a mile of questions, information of herself,
gossip and general outcries which left him no obligation, but to look
beamingly intelligent and from time to time say: "Yes?" His personal
joy, however, was to stare at her beauty.
When she stopped and wandered as if uncertain which way to talk,
there was a minute of silence, which each of them had been
educated to feel was very incorrect; very incorrect indeed. Polite
people always babbled at each other like two brooks.
He knew that the responsibility was upon him, and, although his
mind was mainly upon the form of the proposal of marriage which
he intended to make later, it was necessary that he should maintain
his reputation as a well-bred man by saying something at once. It
flashed upon him to ask: "Won't you please play?" But the time for
the piano ruse was not yet; it was too early. So he said the first
thing that came into his head: "Too bad about young Manolo Prat
being killed over there in Cuba, wasn't it?"
"Wasn't it a pity?" she answered.
"They say his mother is heart-broken," he continued. "They're afraid
she's goin' to die."
"And wasn't it queer that we didn't hear about it for almost two
months?"
"Well, it's no use tryin' to git quick news from there."

Presently they advanced to matters more personal, and she used
upon him a series of star-like glances which rumpled him at once to
squalid slavery. He gloated upon her, afraid, afraid, yet more
avaricious than a thousand misers. She fully comprehended; she
laughed and taunted him with her eyes. She impressed upon him
that she was like a will-o'-the-wisp, beautiful beyond compare but
impossible, almost impossible, at least very difficult; then again,
suddenly, impossible—impossible—impossible. He was glum; he
would never dare propose to this radiance; it was like asking to be
pope.
A moment later, there chimed into the room something that he knew
to be a more tender note. The girl became dreamy as she looked at
him; her voice lowered to a delicious intimacy of tone. He leaned
forward; he was about to outpour his bully-ragged soul in fine
words, when—presto—she was the most casual person he had ever
laid eyes upon, and was asking him about the route of the proposed
trolley line.
But nothing short of a fire could stop him now. He grabbed her
hand. "Margharita," he murmured gutturally, "I want you to marry
me."
She glared at him in the most perfect lie of astonishment. "What do
you say?"
He arose, and she thereupon arose also and fled back a step. He
could only stammer out her name. And thus they stood, defying the
principles of the dramatic art.
"I love you," he said at last.
"How—how do I know you really—truly love me?" she said, raising
her eyes timorously to his face and this timorous glance, this one
timorous glance, made him the superior person in an instant. He

went forward as confident as a grenadier, and, taking both her
hands, kissed her.
That night she took a stained photograph from her dressing-table
and holding it over the candle burned it to nothing, her red lips
meanwhile parted with the intentness of her occupation. On the
back of the photograph was written: "One lesson in English I will
give you—this: I love you."
For the word is clear only to the kind who on peak or plain, from
dark northern ice-fields to the hot wet jungles, through all wine and
want, through lies and unfamiliar truth, dark or light, are governed
by the unknown gods, and though each man knows the law, no man
may give tongue to it.

Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.
More than just a book-buying platform, we strive to be a bridge
connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.
Join us on a journey of knowledge exploration, passion nurturing, and
personal growth every day!
ebookbell.com

Advances In Uml And Xmlbased Software Evolution Illustrated Edition Hongji Yang

More Related Content

Similar to Advances In Uml And Xmlbased Software Evolution Illustrated Edition Hongji Yang (20)

More from uahpirsahrin (7)

Recently uploaded (20)

Advances In Uml And Xmlbased Software Evolution Illustrated Edition Hongji Yang