Get the full ebook with Bonus Features for a Better Reading Experience on ebookgate.

com

Management of the Object Oriented Development

Process 1st Edition Liping Liu

https://ebookgate.com/product/management-of-the-object-
oriented-development-process-1st-edition-liping-liu/

OR CLICK HERE

DOWLOAD NOW

Download more ebook instantly today at https://ebookgate.com

Instant digital products (PDF, ePub, MOBI) available
Download now and explore formats that suit you...

The principles of object oriented JavaScript Zakas

https://ebookgate.com/product/the-principles-of-object-oriented-
javascript-zakas/

ebookgate.com

Object Oriented Oracle Wenny Rahayu

https://ebookgate.com/product/object-oriented-oracle-wenny-rahayu/

ebookgate.com

PHP Object Oriented Solutions 1st Edition David Powers

https://ebookgate.com/product/php-object-oriented-solutions-1st-
edition-david-powers/

ebookgate.com

Applying UML and Patterns An Introduction to Object

Oriented Analysis and Design and the Unified Process 2nd
Edition Craig Larman
https://ebookgate.com/product/applying-uml-and-patterns-an-
introduction-to-object-oriented-analysis-and-design-and-the-unified-
process-2nd-edition-craig-larman/
ebookgate.com
Object oriented Analysis And Design Understanding System
Development With UML 2 0 First Edition Mike O'Docherty

https://ebookgate.com/product/object-oriented-analysis-and-design-
understanding-system-development-with-uml-2-0-first-edition-mike-
odocherty/
ebookgate.com

Object oriented programming with ABAP Objects 1st Edition

James Wood

https://ebookgate.com/product/object-oriented-programming-with-abap-
objects-1st-edition-james-wood/

ebookgate.com

Object Oriented Programming with C 2 e Second Edition

Sahay

https://ebookgate.com/product/object-oriented-programming-
with-c-2-e-second-edition-sahay/

ebookgate.com

Object Oriented Design and Patterns 2nd Edition Cay S.

Horstmann

https://ebookgate.com/product/object-oriented-design-and-patterns-2nd-
edition-cay-s-horstmann/

ebookgate.com

Object oriented programming in C 7th print. with

corrections Edition Lafore

https://ebookgate.com/product/object-oriented-programming-in-c-7th-
print-with-corrections-edition-lafore/

ebookgate.com
 Management of
the Object-Oriented
Development Process
Liping Liu
The University of Akron, USA

Boris Roussev
University of the Virgin Islands, USA

IDEA GROUP PUBLISHING

Hershey • London • Melbourne • Singapore
Acquisitions Editor: Renée Davies
Development Editor: Kristin Roth
Senior Managing Editor: Amanda Appicello
Managing Editor: Jennifer Neidig
Copy Editor: Maria Boyer
Typesetter: Larissa Zearfoss
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: [email protected]
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 © 2006 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

Management of the object-oriented development process / Liping Liu and Borislav Roussev, editors.
p. cm.
Summary: "This book consists of a series of high-level discussions on technical and managerial issues
related to object-oriented development"--Provided by publisher.
Includes bibliographical references and index.
ISBN 1-59140-604-8 (hard cover) -- ISBN 1-59140-605-6 (softcover) -- ISBN 1-59140-606-4
(ebook)
1. Object-oriented programming (Computer science) 2. Computer software--Development. I. Liu,
Liping. II. Roussev, Borislav.
QA76.64.M348 2005
005.1'17--dc22
2005004533

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. Each chapter is assigned to at
least 2-3 expert reviewers and is subject to a blind, peer review by these reviewers. The views expressed
in this book are those of the authors, but not necessarily of the publisher.
 Management of the
Object-Oriented
Development Process

Table of Contents

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

Chapter I
Object-Oriented Modeling in UML2 .................................................... 1
Boris Roussev, University of the Virgin Islands, USA

Chapter II
MDA with xUML: Model Construction and Process
Management ........................................................................................ 36
Boris Roussev, University of the Virgin Islands, USA

Chapter III
Management Planning in a Changing Development Environment ... 61
Melissa L. Russ, Luminary Software and Space Telescope
Science Institute, USA
John D. McGregor, Luminary Software and
Clemson University, USA

Chapter IV
MDA Design Space and Project Planning .......................................... 87
Boris Roussev, University of the Virgin Islands, USA

Chapter V
Agile Outsourcing to India: Structure and Management ................ 109
Boris Roussev, University of the Virgin Islands, USA
Ram Akella, University of California, USA
Chapter VI
User Requirements Validation and Architecture Discovery
through Use Case Invariants and Model Animation ....................... 141
Boris Roussev, University of the Virgin Islands, USA
Yvonna Rousseva, University of the Virgin Islands, USA

Chapter VII
RUP and eXtreme Programming: Complementing Processes ....... 183
Gary Pollice, Worcester Institute of Technology, USA

Chapter VIII
Managing Complexity with MDSD .................................................. 200
Jorn Bettin, SoftMetaWare, USA

Chapter IX
Agile RUP: Taming the Rational Unified Process ............................................ 231
Gary K. Evans, Evanetics, Inc., USA

Chapter X
Planning and Managing the Human Factors for the Adoption
and Diffusion of Object-Oriented Software Development
Processes ........................................................................................... 247
Magdy K. Serour, University of Technology, Sydney, Australia

Chapter XI
Web Services in Service-Oriented Architectures ............................ 278
Gerald N. Miller, Microsoft Corporation, USA

Chapter XII
Model-Based Development: Metamodeling, Transformation
and Verification .................................................................................. 289
Juan de Lara, Universidad Autónoma de Madrid, Spain
Esther Guerra, Universidad Carlos III, Spain
Hans Vangheluwe, McGill University, Canada

Chapter XIII
Agile Project Controlling and Effort Estimation ............................... 313
Stefan Roock, it-agile GmbH, Germany
Henning Wolf, it-agile GmbH, Germany
Chapter XIV
Improving OO Design Process Using Rules, Patterns and
Refactoring ........................................................................................ 325
Javier Garzás, University Rey Juan Carlos, Spain
Mario Piattini, University of Castilla-La Mancha, Spain

Chapter XV
The BORM Method: A Third Generation Object-Oriented
Methodology ...................................................................................... 337
Roger Knott, Loughborough University, UK
Vojtech Merunka, University of Agriculture in Prague,
Czech Republic
Jiri Polak, Deloitte & Touche, Prague, Czech Republic

About the Authors .............................................................................. 361

Index ................................................................................................... 368

vi

Preface

Introduction

Dilemmas involving notation, project planning, project management, and ac-

tivity workflow pervade the world of software development. Object-orienta-
tion provides an elegant language for framing such problems, and powerful
tools for resolving them.
In this book, we have brought together a collection of presentations, giving
the reader an in-depth look into the technical, business, and social issues in
managing object-oriented development processes, as well as presenting new
technologies, making software development more effective. The chapters in
the book examine many topics in the research frontier of software develop-
ment, including methods, technologies, strategies, and the human factor. The
book also presents the fundamentals of object-oriented project management.
The various backgrounds of the contributing authors—industrial, consulting,
research, and teaching—yielded presentations, complementing and enriching
each other. As a result, the book paints a holistic picture of the multi-faceted
problems in object-oriented software development. It should be of interest to
software developers, project managers, system analysts, and graduate and
upper-level college students majoring in information systems and computer
science who would like to deepen their knowledge in the field of object-
oriented project management.
Very briefly, some of the major topics discussed in this book include: software
development life cycle; development strategies, for example, open source,
outsourcing, and product lines; componentization; the human factor; object-
oriented notation and techniques, such as xUML, MDA, and MDSD; re-
quirements engineering; design patterns; project management; and system in-
tegration with Web services.
 vii

Organization

The book is organized into 15 chapters. Each chapter emphasizes a particular

area, identifies important shortcomings, discusses current activities, offers new
insights into the problematics, and suggests opportunities for improving the
management of object-oriented software development projects.
Motivated by computer simulation, the notions of object, class, and class gen-
eralization were formulated by Dahl and Nygaard in 1967. However, it was
not until the mid-1990s that the first industrial-strength, object-oriented nota-
tions were complemented by sound development methods. Today, the ob-
ject-oriented world is dominated by UML to the extent that UML and object-
orientation have become synonymous. The book naturally begins with an in-
troduction to UML2. The emphasis is on the novel features of UML and the
new trends in object-orientation, namely, modeling of large things, a higher
level of modeling abstraction, design automation, precision, and freedom from
the constraints of the implementation platform.
In Chapter II, the themes from the introductory chapter are re-examined in
the framework of xUML (executable UML) and MDA (model-driven ar-
chitecture). MDA and xUML are among the latest initiatives of OMG.
They promise to change the way software is created by combining a mod-
eling language with a model manipulation language, rendering implementation
programming obsolete. The chapter presents the two methodologies. It also
discusses the MDA activity workflow and presents a development method for
projects relying on xUML.
In Chapter III, Russ and McGregor present a model for planning object-
oriented projects. The authors structure the software development land-
scape into a triad of high-level dimensions—technology, method, and or-
ganizational strategy—where each dimension is further divided into sev-
eral sub-dimensions. The model defines project planning as navigating
through a multi-dimensional hyperspace.
In Chapter IV, the Russ-McGregor model has been applied to evaluate the
strength and weaknesses of xUML and MDA. The analysis sheds light on the
economics of model-driven software development, and on the difficulties
project managers and developers alike may encounter in adopting the two
technologies in an industrial setting.
In Chapter V, Roussev and Akella present a new approach to managing
outsourcing projects. Drawing on experience with Indian software firms, the
authors closely analyze the problems faced by outsourcing clients and off-
viii

shore developers. Roussev and Akella show how these problems can be suc-
cessfully resolved by scaling down a large outsourcing project to meet the
Agile “sweet spot,” and by carefully managing the communication patterns
among all stakeholders.
In Chapter VI, Roussev and Rousseva present a process extension applicable
to both lightweight and heavyweight development methods. The extension is
based on a business value invariant, and views the iterative and incremental
model of software development as a communication model. The proposed
techniques link the informal user requirements world to the system model,
which makes it possible to derive mechanically the system architecture from
the user requirements, and automatically to validate it with respect to the
system’s use case model through model animation.
It is a well-known fact that many of the agile practices are incompatible with
the context of large-sized projects. Gary Pollice and Gary Evans, two nation-
ally recognized methodologists, independently present their approaches to
reproducing the conditions for agility in large-sized projects by balancing agil-
ity and discipline. Pollice and Evans look out for common grounds between
Agile and RUP to get the best of both worlds.
In Chapter IX, Jorn Bettin, director of an international strategic technology
management consultancy, addresses the question of how to create durable and
scalable software architectures, so that the underlying design intent survives over
a period of many years. Bettin goes beyond object-orientation and traditional
iterative software development to define a set of guiding principles for compo-
nent encapsulation and abstraction, and to form the foundation for a model-
driven approach to software development.
In Chapter X, Magdy Serour from the Centre for Object Technology Appli-
cations and Research (COTAR) at the University of Technology, Sydney, delves
into a gray area of object-orientation, namely, the effect of various human
factors on the adoption and diffusion of an object-oriented software develop-
ment process. Serour defines a process to assist organizations in planning and
managing their transition to object-oriented development. The author discusses
key “soft” factors, such as motivation, leadership, and overcoming the resis-
tance to culture change, which are critical in promoting the process of organi-
zational change.
In Chapter XI, Gerald Miller from Microsoft addresses a very important area
of the new technological wave. Integration of systems in a cost-effective way
is crucial for most enterprises, as many integration efforts fail to bring about
the promised return on investment. Miller’s presentation discusses how to
 ix

resolve the system integration nightmare by building a service-oriented archi-

tecture with Web services which integrates disparate systems, both within
organizations and across business partners’ firewalls.
In Chapter XII, de Lara, Guerra, and Vangheluwe give an overview of model-
based software development, and propose ideas concerning meta-modeling
and the use of visual languages for the specification of model transformations,
model simulation, analysis, and code generation. They also examine the im-
pact of model-based techniques on the development process.
The Agile methods are based on the presumption that a complete and stable
requirements specification is generally impossible. This assumption invalidates
the very vehicle for computing project velocity, progress, deadline prognosis,
and budget allocations, as project managers cannot track the number of closed
vs. open requirements. In Chapter XIII, Roock and Wolf demonstrate a prac-
tical technique, integrating lightweight mechanisms for project controlling into
Agile methods. They propose to combining an (incomplete) hierarchical de-
composition of a system with abstract measurements. Their approach ad-
dresses pressing management needs without incurring the burden of a water-
fall-like exhaustive specification upfront.
Object-oriented knowledge comes in different forms, for example, principles,
heuristics, patterns, refactoring, lessons learned, defects, and best practices.
In Chapter XIV, Garzás and Piattini define an ontology of object-oriented
micro-architectural design knowledge to systematize this knowledge so that it
can be easily comprehended by developers and used in practical cases.
In the final chapter, Knott, Merunka, and Polak propose a new object-oriented
methodology, which makes extensive use of business process modeling. The
authors contrast and compare their approach to similar development approaches,
and provide a case study to demonstrate the feasibility of their methodology.
x

Acknowledgments

We would like to thank Mehdi Khosrow-Pour, Idea Group Inc. Senior Edi-
tor, for inviting and accepting our book proposal and for his insistence on
timely completion of this project. Thank you also to Jan Travers, Idea Group
Inc. Managing Director, for her patience that made it possible to bring this
project to fruition. We would also like to thank all referees for their assistance
in reviewing and improving on some of the chapter materials.

The second editor would also like to thank Professor Aubrey Washington and
Chancellor Jennifer Jackson at the University of the Virgin Islands for their
continued support and encouragement. He is indebted to his colleague, Pro-
fessor John Munro, for his professional advice, valuable suggestions, and feed-
back. He is grateful to Professor Akella at the University of California, Santa
Cruz, for providing me with the opportunity to work and do research in the
Silicon Valley.

Above all, he expresses his deep gratitude to Professor Yvonna Rousseva, his
spouse, for her insightful comments, incisive critique, and numerous thought-
provoking discussions. Without her, this book would have been impossible to
finish.
 Object-Oriented Modeling in UML2 1

Chapter I

Object-Oriented
Modeling in UML2
Boris Roussev
University of the Virgin Islands, USA

Abstract

Object-orientation (OO) is a powerful design methodology, which has

firmly moved into the mainstream of software development. In 2002, both
the IEEE John von Neumann Medal and the ACM Turing Award (the Nobel
Prize for Computing) were awarded to the scholars who started the
object-oriented journey back in 1967. Despite this recognition, object-
orientation is far from being the dominant technology of choice. Contrary
to the common belief, a recent authoritative study reports that only 30%
of the software companies rely on OO technologies, and that the waterfall
model is still the most popular lifecycle model of software development.
In this introductory chapter, we present the fundamental concepts and
principles of object-oriented modeling with UML version 2. Born out of
the efforts to resolve the software crisis, UML has taken such a hegemonic
role that we fear object-orientation may undergo a population
“bottleneck.” In biology, this is an event that dangerously cuts the
amount of genetic diversity in a population. The objectives of this chapter
are as follows: 1) to present the influential ideas in the evolution of object-
orientation; 2) to identify the lasting trends in object-orientation; 3) to

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
2 Roussev

introduce the core UML modeling languages and some of the techniques
closely associated with them; and 4) to discuss some of the challenges with
object-oriented modeling. In addition, we present the E-ZPass system, a
system of moderate complexity used as a running example in the first five
chapters of this book. This presentation is the book’s cornerstone. There
is not a single chapter in the rest of this volume that does not assume an
overdetermined <<UML>> reader.

Introduction

Building large and complex software systems is notoriously difficult. To build

such systems, we need methodologies backed by languages that would feature
characteristics addressing the following needs:

Features Needs
To structure a system into modular components that can
u Control complexity.
be developed, maintained, and reused separately.
To base the semantic structure and behavior of the
v Reduce the cognitive burden.
solution on the problem being solved.
To raise the level of abstraction of the artifacts being
w Curb complexity.
constructed.
To use a common vocabulary with the client. To describe Link business and
x the problem in a notation that is client and designer technology, and improve
friendly. communication.
Testability, executability,
To describe a problem precisely and in a way that avoids
y portability, productivity, and
delving into technical details.
design automation.
To allow for reuse at all levels: requirements, analysis,
Improve quality and
z design, architecture, and domain, and at all levels of
productivity.
interest: structural, behavioral, and communicational.
To provide the basis for effective management of the
{ Develop cost-effectively.
development process.
Improve quality and
| To automate repetitive design and implementation tasks.
productivity.
To facilitate iterative and incremental, architecture- Risk mitigating, exploratory
}
centered, test-driven processes. processes.
To respond to change quickly and in a cost-effective Satisfy the ever-evolving
~
manner. user needs.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Oriented Modeling in UML2 3

Object-orientation (OO) is a powerful design methodology based on the

principles listed above. The importance of OO has now been firmly
recognized by industrial and research communities alike. In 2002, both the
IEEE John von Neumann Medal and the ACM Turing Award (the Nobel
Prize for Computing) were awarded to Ole-Johan Dahl and Kristen Nygaard
for their pioneering work in OO through the design and implementation of
SIMULA67. A quote from the ACM address confirms the importance of this
seminal work:

Their [Dahl and Nygard’s] work has led to a fundamental change

in how software systems are designed and programmed, resulting
in reusable, reliable, scalable applications that have streamlined
the process of writing software….

In modern history of science, it is not very common to have such a low adoption
rate as in the case of OO. The work of Dahl and Nygaard was made almost
extinct by two programming languages called COBOL and C, which muscled
their way through, backed by several major industry players and governmental
agencies.
Despite the recognition, OO (with the exception of use cases) is not yet the
dominant technology of choice. In a comprehensive study, Laplante and
Neill (2004) report that only 30% of the software companies rely on OO
technologies and that the waterfall model is still the most popular lifecycle
model in use. The authors conclude that OO techniques are not dominant,
which is in sharp contrast with the common belief about the popularity of
OO methods and technology.
In this introductory chapter, we lay the fundamental concepts of OO using
the Unified Modeling Language (UML, 2004). Since it was adopted by the
OMG in 1997, UML has been widely accepted throughout the software-
modeling world and successfully applied to diverse domains. Therefore,
it will not be much of an exaggeration to paraphrase from Wittgenstein1:
namely, the limits of UML mean the limits of my OO world.
Since OO modeling is dominated by UML in all areas, it seems unlikely for
an OO notation or method to be able to survive away from UML. In the
foreseeable future, the evolutionary history of OO will be tied in very
closely to that of UML. As a result, OO methods may undergo a population
“bottleneck.” In biology, this is an event that cuts dangerously the amount

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
4 Roussev

of genetic diversity in a population. On the bright side, OMG is backed by a

large industrial consortium, and important decisions are taken with broad
consensus and (in truly OO spirit) after an incremental and iterative
process. Despite the dominant role of UML, there are alternative ap-
proaches, for example, the OPEN Modeling Language (Firesmith,
Henderson-Sellers, & Graham, 1998) and the Business Object Notation
(Paige & Ostroff, 1999).
The rest of the chapter is structured as follows. The next section presents
a brief history of OO focusing on influential ideas and contribution. Then
we introduce the core set of modeling language of UML2. We use as a
running example a real-world system of moderate complexity. We next
discuss some of the challenges with OO modeling, before concluding the
chapter.

Brief History of Object-Orientation

The crisis in software development is not from yesterday. Being relatively

young, software development has lacked until recently a proven apparatus
for design and evaluation of software products. The historic conference,
sponsored by NATO, that diagnosed the crisis of software development and
proposed “software engineering” as a remedy, took place in Garmisch,
Germany, in the Bavarian Alps, in 1968. After the conference, Dijkstra, one
of the participants, wrote: “For me it was the end of the Middle Ages. It was
very sunny.” However, almost 40 years later, resorting to best practices,
documented as development methods, such as RUP and Agile, testifies to
the fact that it might have marked not so much the end of the Middle Ages,
but rather it might have foreshadowed the harbinger of a Renaissance.
In this section, we attempt to summarize chronologically the OO Renais-
sance. The review of the early OO analysis and design methods is based on
the insightful discussion in Graham and Wills (2001).
The rapidly improving performance/price ratio of hardware entailed wide
adoption of client-server multi-tier information systems in every sphere of
human activity. In the 1980s, the software development community came
under increased pressure to develop usable, dependable, and scalable
distributed systems in a cost-effective way.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Oriented Modeling in UML2 5

To increase productivity and quality, the software industry had to adopt

methods of building systems out of reusable components, and at the same
time to raise the level of abstraction of the designed artifacts. There were
two major challenges to materializing these ideas. First, with structured
methods, less than half of a system could be built out of reusable components
(Biggerstaff & Richter, 1989). And second, raising the level of abstraction
leaves developers with less meaningful artifacts—that is, less semantic
richness and fewer venues for extensibility.
Structured methods view a system as a hierarchy of functions and rigidly
separate process knowledge from data. Self-contained, customizable, and
reusable components did not naturally fit in this environment.
The software industry responded to these challenges by shifting its focus to
OO methods. Up until the early 1980s, OO was largely associated with the
development of graphical user interfaces and AI. In the 1980s, interest
extended to OO design, mainly to support the OO programming language
Smalltalk and the OO extension of the imperative language C, named C++.
In the late 1980s and early 1990s, interest moved away from OO design to
OO analysis. Several influential works helped gradually shape the field of
OO analysis. The coinage object-oriented design is attributed to Booch,
who published a paper in 1988 and a book (Booch, 1991, 1993) with the
same name.
The switch from well-established structured analysis techniques to OO
analysis methods naturally began with extending the entity-relationship
model (Codd et al., 1980) and endowing entities with behavioral aspects,
the so-called data-driven approach. Data-driven methodologies (Coad &
Yourdon, 1991; Rumbaugh et al., 1991; Shlaer & Mellor, 1988) approached
application development as relational database development.
Coad and Yourdon (1991) added operations to entities to define class
models as a basis of a simple OO analysis method, which immediately
became popular. OMT (Rumbaugh et al, 1991), built on the work of Coad
and Yourdon, and Shlaer and Mellor (1988) proposed the use of finite state
machines (FSMs) to describe the lifecycles of class instances. This idea
came to fruition in the work of Shlaer and Mellor (1992), who also advanced
the notion of translational modeling, thus laying the foundation for Execut-
able UML (Mellor & Balcer, 2002) and Model-Driven Architecture (MDA,
2004).

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
6 Roussev

A second group of OO methods emerged in parallel with the data-driven group,

called responsibility-driven methods. They shied away from the entity-relation-
ship model and more strictly adhered to OO principles.
Wirfs-Brock et al. (1990) developed a set of responsibility-driven design
(RDD) techniques. Among the most important contributions of RDD are the
extension of the idea of CRC cards (Beck & Cunningham, 1989) and the
introduction of stereotypes. CRC cards are physical cardboard pieces
visualizing classes with their responsibility and collaborations (hence the
name CRC). Developers are encouraged to take the view of an instance of
a class (called anthropomorphism) and act out the object’s lifecycle in order
to discover new classes in the problem domain. Then, these CRC cards are
used as a starting point for design. This technique became one of the
underpinnings of the Agile methodologies (Beck, 1999).
Cook and Daniels’ (1994) Syntropy added rigor to OO modeling by
introducing a pure expression language, later called OCL to express
modeling concepts, such as uniqueness constraints, invariants, transition
guards, and operation pre- and post-condition, that cannot even be repre-
sented on class diagrams and finite state machines.
As OO notations mushroomed in the early 1990s, so did the OO methods that
lived on them. MOSES (Henderson-Sellers & Edwards, 1994) was the first
OO method to include a full-fledged development process and metrics.
SOMA (Graham, 1994), following in the footsteps of MOSES, attempted
to fuse the best practices of all methods, and in addition emphasized
requirements engineering, process, and rigor.
Arguably the most influential work, which later became the foundation of
RUP (Kruchten, 2000), was the OO incarnation of Objectory (Jacobson,
1992). Objectory started out as a proprietary method in Erickson, a Swedish
telecommunication company, in the late 1960s. The major contributions of
Jacobson’s work are the following: use cases (clusters of scenarios of
system usage); use case analysis; the use of sequence diagrams for class
discovery and distribution of responsibilities among classes; the boundary-
controller-entity design pattern, which allowed the containment of “change-
ability” through “locality of change;” and the definition of software
development as model transformation from more abstract to more detailed
and precise models.
In 1997, OMG standardized and published UML version 1. UML1 quickly
became the norm for OO modeling. UML was influenced by OMT, OCL, the
Booch notation, activity diagrams for process modeling (Martin & Odell,

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Oriented Modeling in UML2 7

1992), stereotypes (Wirfs-Brock et al., 1990), and multiple interfaces from

Microsoft’s COM+ technology. UML’s belated conception was the major
cause for its inconsistencies and deficiencies (Miller, 2002). The industry
had already invested in the creation of expensive CASE tools, and CASE
tool vendors resisted many innovations and simplifications that would
render their tools obsolete.
The two most popular methods used for OO software development with
UML are RUP, developed at Rational by Jacobson et al. (Kruchten, 2000),
and the lighter-weight Agile methods (Beck, 1999). Both RUP and Agile are
based on an iterative and incremental lifecycle, in which the system
architecture evolves (hence the term evolutionary) incrementally from a
prioritized set of user requirements in a series of mini-waterfall cycles of
business-modeling/requirements-elicitation/analysis/design/implementa-
tion/test. The evolutionary approaches are requirements-driven (each
artifact can be traced to a requirement) and architecture-centered (or
architecture first). They outperform in terms of customer satisfaction and
cost methods based on the waterfall model in fast-paced, dynamic environ-
ments, with a great risk exposure due to the multiple feedback opportunities
for customers to situate and orient the development effort. The evolutionary
approaches are based on a reciprocal relationship between system and user.
On the one hand, the user envisions the system. On the other hand, the system
changes the user’s perception about the system. Therefore, we could expect
that a partially completed prototype (increment) will be able to reveal early
on the anticipated change in the users, and in this way to reduce the
backtracking in the development process.
The inconsistencies in UML1 prompted several minor revisions (UML1.x),
followed by a major one, whose result will be UML2. The standardization
process is scheduled for completion by the end of 2004. UML2 promises
to be a breakthrough in model-driven development by making models
executable and by automating the relationship between models and code.
Objects turned out to be disproportionately small compared to the size of
the systems being built with them. The second wave of innovations in OO
analysis was marked by an increased interest in things bigger than objects,
namely things allowing reuse on a larger scale, but foremost, things
automating the software design process. The trend, which began in the mid-
1990s, is toward more complex structures at a higher level of abstraction,
gradating from design patters and components, through aspects, to domains.
The second trend informing OO today is design automation.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
8 Roussev

Introduced in a seminal work (Gamma, Helm, Johnson, & Vlissides, 1995),

design patterns have quickly gained popularity among developers. A design
pattern is a description of a problem, a best practice for its solution, and
when and how to apply the best practice (typically, via instantiation) in new
situations. Gamma et al. showed the advantage of reusing aggregations of
objects along with the mechanisms for their interactions. The reusability of
design knowledge with design patterns, however, comes at a certain price.
Garzás and Piattini (2005) list a number of problems with design patterns:
difficult application, temptation to recast everything as a pattern, pattern
overload, high-dependence on a programming language (except for analysis
patterns), complex non-homogeneous catalogs, and a steep learning curve
for some counter-intuitive patterns, to name a few. It is important to note that
design patterns do not raise the level of abstraction at which design is
carried out. They describe solutions at the object level.
OO provided the foundation for component-based development. Compo-
nents are big things that do raise the level of abstraction in design. A
component is a set of closely related objects, encapsulated together to
support a set of clearly defined interfaces. With components, a system is
described in terms of interactions among component interfaces. Designed
with reusability in mind, components lead to increased productivity and
quality. To use components, developers ought to be equipped with tools for
component customization, initialization, and interface inspection.
To address the issue of crosscutting concerns, Kiczales (1996) introduced
aspect-oriented programming (AOP). AOP deals with abstractions on a
plane different from object-oriented modeling. AOP advocates specifying
separately the various pervasive requirements of a system, for instance,
security and transaction management, which do not decompose into behav-
ior centered on a single locus, and then, to weave them together into a
coherent system. AOP focuses on the system’s infrastructure, something that
cannot be done effectively only in terms of components and objects. AOP’s
major drawback is that aspects are defined at code level.
The largest truly reusable constructs in OO are domains. An executable
domain model captures precisely the conceptual entities of a single subject
matter (Mellor & Balcer, 2002). Each domain forms a cohesive whole,
semantically autonomous from other domains, which makes domains the
largest units of reuse. A domain is modeled as a set of communicating
objects or more precisely as a set of communicating object state machines.
Executable domain models can be simulated and debugged, woven together

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Oriented Modeling in UML2 9

through bridges, and automatically compiled to code based on the principles of

generative programming (Czarnecki & Eisenecker, 2000). Domains bear
certain similarity to aspects, but they are, in distinction, defined at a very
abstract model level.
In line with model-driven development and domain modeling, OMG launched
the Model-Driven Architecture initiative (MDA, 2004). The essence of the
MDA approach is the clear separation between executable platform indepen-
dent models (PIM) and platform specific models (PSM), and the application
of marks and mappings to transform PIMs to PSMs, and to generate code from
PSMs. The notions of model executability and model mappings bring in the so-
much-sought-after design automation. MDA raises the level of abstraction and
avoids technology dependence, thus addressing the complexity and portability
problems. Furthermore, MDA applies very successfully the separation-of-
concern principle by capturing design knowledge in machine-readable map-
pings and application knowledge in executable domain models. Model
executability affords model testing and debugging, thus realizing the “proving
with code” principle, only at a much more abstract level.
The level of reuse culminates in product lines (Withey, 1996; PL, 2004),
breaking easily the 90% reuse barrier. The product lines method aims at
identifying units of common functionality in a family of products and
defining a customized development process, minimizing the effort neces-
sary to duplicate this functionality in the related products. Several methods
(Bosch, 2000; Bayer et al., 1999; Atkinson, Bayer, & Muthig, 2000) attempt
to combine component-based development, design patterns, and product
lines, and to provide developers with the necessary automation tools.
Design automation reaches its highest in Model-Driven Software Develop-
ment (MDSD) (Bettin, 2004, 2005). MDSD is a synergy of product line,
DSLs2, and MDA. MDSD is characterized by the conscious distinction
between building software factories and building software applications
(also referred to as domain engineering). MDSD supports domain-specific
specialization and mass customization.
With less emphasis on programming, requirements engineering and systems
analysis will grow more and more important as time goes by. Research
efforts in the requirements engineering area are toward understanding the
role of requirements in the wider systems engineering process and toward
validating user requirements in a manner similar to validating software—
that is, requirements should be automatically translated to code and executed
via simulation techniques (Lamsweerde, 2000).

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
10 Roussev

Figure 1. E-ZPass system

Modeling with UML

In this section, we introduce the core set of the UML modeling languages
needed to design OO systems. The UML models we discuss are class
diagrams modeling the information structure of a system, FSMs represent-
ing the behavior of individual objects, use cases expressing user require-
ments, and interaction diagrams (sequence and communication diagrams)
modeling interactions among societies of objects, collaborating to realize
user requirements.

Case Study

In this and the next four chapters, we will use the following system as a
running example.
In the road traffic E-ZPass system, drivers of authorized vehicles are
charged at tollgates automatically. They pass through special lanes called
E-Z lanes. To use the system, a driver has to register and install an electronic
tag (a gizmo) in his/her vehicle. The vehicle registration includes the
owner’s personal data, credit card or bank account, and vehicle details. As
a registered vehicle passes through the tollgate, an antenna electronically reads
account information on the gizmo, and the toll is automatically deducted from
the prepaid account. The amount to be debited depends on the kind of the
vehicle. When an authorized vehicle passes through an E-Z lane, a green light

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Oriented Modeling in UML2 11

comes on, and the amount being debited is displayed. If an un-authorized

vehicle passes through an E-Z lane, a yellow light comes on and a road camera
takes a photo of the plate, used to fine the vehicle’s owner (fine processing is
outside the system scope). There are E-Z lanes where the same type of vehicles
pay a fixed amount, for example at a toll bridge, and there are E-Z lanes where
the amount depends on the type of vehicle and the distance traveled, for
example on a highway. For the latter, the system stores the entrance tollgate and
the exit tollgate.

User Requirements Model

A user requirement is a dialogical specification of what the system must do.

As user requirements are elicited, they are organized into use cases.
Requirements are not yet first-order elements in UML, but they are sched-
uled to become such in the forthcoming Systems Engineering UML profile.
The systems engineering profile defines about 10 different types of require-
ments, which fall into three broad categories: operational, functional, and
quality of service (QoS). Operational and functional requirements are best
expressed as usage scenarios modeled with sequence diagrams or commu-
nication diagrams (formerly collaboration diagrams). QoS requirements
come in several types (e.g., usability, security, and performance, to mention
a few) and are modeled as constraints.
Since their introduction in the late 1980s (Jacobson, 1987), use cases have
proven to be an immensely popular software development tool. Use cases
organize requirements—such as tens of usage scenarios—around a common
operational capability. They describe the system as a black box. Use cases
present a conceptual model of the intended system behavior by specifying
services or capabilities that the system provides to its users.
In use case models, the system’s environment, or context, is modeled as
actors, which are essentially roles played by end users or external systems
(a single user may perform many roles). In Figure 2, the actors for the E-
ZPass system are Driver, Bank, and Operator. They are rendered as stick
figures. The actors communicate with the use cases rendered as ovals via
communication links. A use case contains and organizes multiple scenarios. A
scenario is a linear sequence of transactions performed by actors in a dialogue
with the system that brings value to the actors.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
12 Roussev

Figure 2. E-ZPass use case model

Register Vehicle
Operator

Driver <<include>> Bank

Pass 1-Point Tollgate

<<extend>>
<<include>>
Debit Account

Invalid Account
Pass 2-Point Tollgate

A system is conceptually decomposed into subsystems of related use cases

linked by <<include>> and <<extend>> dependency relationships or sharing
common actors. <<>> indicates a stereotype. Stereotypes are a lightweight
UML extension mechanism. A stereotype defines the meaning of a new building
block, which has derived from an existing one. The <<include>> relationship is
used to extract out a coherent part of a use case, typically for the purpose of
reuse. It can also be used to decompose a system-level use case into “part” use
cases to be realized by different subsystems. The <<extend>> relationship is used
when the behavior of one use case, called base use case, may be extended with
the behavior of another use case under certain conditions. Users find the
direction of the <<extend>> relationship counter-intuitive (from the extension use
case to the base use case). It is best to think of it as the extension use case
pushing functionality to the base use case. Figure 2 illustrates the discussed
concepts related to use cases.
A use case diagram shows only the use case’s organization. The flows of events
in every use case are described in text. The following is a fairly standard
template for use case descriptions.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Oriented Modeling in UML2 13

Use case name

Description: brief narrative description.
Actors: a set of Actors
Basic flow of events: numbered sequence of events
Exceptional flow of events: numbered sequence of events
Pre-conditions: contract between actors and use case
Post-conditions: result of a use case execution

We show below the structure of PassOnePointTollgate use case.

Use Case: PassOnePointTollgate

Description: This use case describes the system’s behavior in response to
a vehicle passing through a single tollgate.
Actors: Driver
Basic Flow
1. The use case begins when a vehicle with a gizmo passes through a
single tollgate. The tollgate sensor reads the gizmo’s ID. The system
records the passage, including date, time, location, and rate; dis-
plays the amount the driver will be charged; and turns the green light
on.

Exceptional Flow of Events:

• The gizmo is invalid or missing. The system turns the yellow light
on and a photo of the vehicle is taken.
Pre-Conditions: None
Post-Conditions: The vehicle’s account is updated with the passage
information and the driver’s credit card.

Modeling the System’s Information Structure

The concepts used for describing systems’ information structures in UML are
class, object, relationship, component, subsystem, and OCL constraints.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
14 Roussev

Objects, Classes, and Relationships

The real world is populated with objects (or instances) of different kinds:
books, bank accounts, and tollgates, to mention a few. Each object has a
number of characteristic attributes that identify it. For example, a book has
a title, author, and publisher. A bank account has an account number, owner,
and interest rate. Figure 3 shows the characteristic attributes of several
kinds of objects. Such an object description is called class, because it
describes a class (set) of similar objects.
Although the object’s attribute values give us information about the object’s
identity, this information is somewhat static. The attributes alone fail to
represent the dynamic nature of many objects. What we need to know are the
operations in which the objects can be involved, or in other words, the behavior
the objects can exhibit. For example, a bank account can accumulate interest
rate, can be debited or credited.
Graphically, a class is represented as a rectangle with three compartments as
shown in Figure 4. The top compartment contains the class name. The middle

Figure 3. Class attributes

Book
BankAccount
ISBN Tollgate
AccountNumber
Title Loc ation
Owner
Publisher Rate
InterestRate
FirstAuthor

Figure 4. Class structure with characteristic attributes and operations

BankAccount
AccountNumber
Class Name Owner
InterestRate
Attributes
Debit()
Operations()
Credit()
Balance()
AccumulateInterest()

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Oriented Modeling in UML2 15

compartment contains the characteristic features, called attributes. The bottom

compartment defines the operations in which the objects of the class can be
involved. Depending on the modeler’s goals, any comportment, except for the
name, can be omitted.

Relationships
The attributes and operations alone are not sufficient to understand the
“essence” of an object. An object in isolation does not have a complete “self-
identity.” The human mind distinguishes between objects by difference. This
difference is determined by the relationships into which objects can enter, by
the ways the objects can be used. The relationships into which an object can
enter are determined by the object’s responsibilities to other objects (imple-
mented as publicly accessible operations). Similar to how words mean in a
language, we can say that an object acquires “self-identity” through different
relationships with other objects. Objects are never strictly defined and identi-
fied unless they enter into relationships.
Jacques Derrida, the French linguist-philosopher, has famously argued that
everything has an originary lack. By entering into relationships with other
objects, the thing compensates for this originary lack. Let us consider a bed
and breakfast room. The room alone is a lump of bricks and furniture,
inconsequential for understanding its purpose, which can be articulated and
manifested only through the relationships into which the room participates. The
relationship room-owner and the relationship room-guest are the room’s
“essential” characteristics. For the owner, the room is a source of income, while
for the guest, the room is a place to rest. The former relationship satisfies the
owner’s lack or desire (for a source of income), while the latter satisfies the
guest’s lack (a home away from home). We can say that the room’s relation-
ships came into being to fill in the owner’s and the guest’s voids.3
In OO, relationships are formalized as associations of various kinds. Associa-
tions model the rules of a problem domain. On class diagrams, associations are
drawn as lines connecting classes. An association between two classes implies
that at runtime the instances of the classes can be linked in some way, enabling
them to invoke each other’s operations. An arrowhead is indicative of the
association’s navigability. A line with no arrowheads denotes a bi-directional
association—that is, at runtime objects on either side of the association can
invoke an operation on the object on the opposite side.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
16 Roussev

Figure 5. Class relationships

0..1 R2 1..* 1..* R1 1

Guest Room Owner
accommodates rents owns is_owned_by

Each association has an identifier, which can be a meaningful name or an

automatically generated label (e.g., R2). The meaning of an association is
expressed with a pair of association ends and a pair of multiplicity ranges. An
association end can be either a role (e.g., “buyer”) or a verb phrase (e.g.,
“rents”), as shown in Figure 5. The association end indicates the meaning
of the association from the point of view of the class on the opposite end.
Roles help overcome the following deficiency of class models. Once
created, an instance belongs to its class forever. To show that this instance
may serve different purposes at different times, we use roles: for example,
an instance of class Employee can be acting as developer in one relationship
and as a supervisor in another one.
A multiplicity range shows how many instances of the class on the near (next
to the range) end can participate in a relationship with a single instance from
the class on the far end. For instance, a room has exactly one owner (we have
consciously excluded partnership), but an owner can own (at least) one or more
rooms (see Figure 5). The most commonly used multiplicity ranges are: 1..1 (1,
for short), 1..* (one or many), 0..1 (0 or 1), 0..* (0 or many).
To describe a relationship, modelers take the view of an instance of each
participating class, a technique called anthropomorphism. For example, let
us consider association R2 in Figure 5. From the room’s point of view: “A
room is owned by one owner;” and from the owner’s point of view: “An
owner owns one or more rooms.”

Aggregation and Composition

An aggregation is a kind of association denoting a “whole-part” relation
between two classes. Since aggregation is a kind of association, all properties
applying to associations apply to aggregations too. In class diagrams, the
“whole” end is represented by an empty diamond.
Composition is a stronger form of aggregation, where the “whole” is respon-
sible for creating and destroying the “part.” The composition end is signified

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Oriented Modeling in UML2 17

Figure 6. Aggregation and composition

R3
Tollgate 1 Lights
controls owner

with a filled diamond. The real difference between aggregation and composition
stands out only in coding as containment by reference and containment by
value. In terms of modeling there are no semantic differences between the two
associations.

Interface
An interface is a named collection of operation signatures (name, parameter
types, return type), attributes, and a protocol state machine (a subset of FSM)
defining a service. An interface specifies a contract for a service to be offered
by a server class, without revealing any implementation details. It has no
behavior by itself, and it cannot not be instantiated. The operations an interface
specifies are implemented in a class (could be a structured class, see below),
and at runtime they are provided by an instance of this class. The relationship
between an interface and its realizing class is best described as type inheritance,
since it signifies that the realizing class conforms to the contract specified by the
interface—that is, the realizing class is type conformant to the interface type. In
class diagrams, this relation is stereotyped as <<realize>> (see Figure 7). UML
also uses the ball-and-socket notation, where the ball represents an interface
to be realized by a class (see Figure 7). Interfaces are there to separate the
specification of a service from its implementation. We say that a class realizes
an interface if it provides operations for all the operations specified in the
interface. One class may realize multiple interfaces.

Figure 7. Interface specifying a service and a class implementing the

service

<<Interface>> Bank Bank

iCharge
makePayment() makePayment()
makePayment() authorize() authorize()
iCharge

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
18 Roussev

Generalization
When two or more classes share a common structure and behavior, the
commonalities can be factored out and placed in a more general super class,
from which the rest of the classes inherit (or derive). The super class has
attributes, associations, or behavior that apply to all derived subclasses. The
derived classes are said to specialize the super class by adding or modifying
attributes, associations, or behavior.
In Figure 8, EZPass is a superclass, and OnePointPass and TwoPointPass are
subclasses. The subclasses can either specialize or extend the super class.
Generalization can be described as “is_a” relationship, for example,
OnePointClass “is_a” kind of EZPass. The “is_a” relationship imposes
interface compliance on the participating classes. This means that any
occurrence of the superclass can be substituted with an instance of the
subclass without semantically breaking the model.
Specializing, also called polymorphism, means that the same operation has a
different implementation in the subclass. In UML, only operations and FSMs
can be specialized (overridden or redefined); for example, operation
CalculateRate in TwoPointPass is implemented differently from its analog
in EZPass, even though it has the same interface. Extending means that the
subclass can have new attributes, operations, states, or transitions.
Through generalization, we may avoid class modification by elegantly reusing the
superclass functionality for creating specialized subclasses. The specialized

Figure 8. Generalization-specialization hierarchy

EZPass
Vehicle
1 R4 0..* Rate
Plate
Tag belongs_to makes
getRate()
calculatePay()

R5
TwoPointPass
OnePointPass EntryLocation
Location ExitLocation
DateTime EntryDateTime
ExitDateTime
Distance

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Oriented Modeling in UML2 19

classes have some of their inherited responsibilities redefined and possibly new
ones added. For example, if a need arises for a super-fast E-Z tollgate, we will
not have to change anything in the existing tollgates. All that is required is to extend
the generalization hierarchy with a new subclass for the new type of tollgate.

Package, Structured Class, Component, and Subsystem

To effectively develop large systems, we need to model their large-scale parts

and how these parts interact with each other. To be scalable, a modeling
notation should allow for parts to contain smaller parts, which can have, in turn,
even smaller parts, and so on. At the most detailed level, parts are class
instances. For modeling things at the large end of the spectrum, UML provides
structured classes, components, and subsystems, all based on the notion of
class. To develop large systems, it is also important to be able to divide the
work into manageable units. For this purpose, UML provides packages.

Package
UML packages are a mechanism for organizing modeling elements, including
other packages, into groups. A package defines only a namespace for the
elements it contains. Packages are used to divide a system model into
independent parts, which can be developed independently. Graphically, a
package is rendered as a tabbed folder (see Figure 9).

Figure 9. Packages and <<import>> relation

Tollgate

Register Driver Payment

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
20 Roussev

A dependency is a using relation signifying that a change in the independent thing

may affect the dependent thing, but not vice versa. <<import>> is a kind of
dependency relation, which grants permission to the elements in one package to
access the elements contained in another one. Relation <<import>> is rendered
as a dotted arrow. The arrowhead points to the package being imported, as
shown in Figure 9. It is important to note that the permission is one-way.

Structured Class
A structured class is a runtime container for instances of classes and other
structured classes, collectively called parts or elements. These parts are
interconnected with communication links named connectors, as shown in
Figure 10. Apart from being in charge of creating and destroying its parts
and connectors, a structured class may coordinate its parts’ activities, for
example, through an FSM.
A structured class contains its part through composition. An instance multiplic-
ity number written in the corner of a part shows the number of instances from
that part. The parts and the connectors constitute the part topology of the
structured class.
A structured class offers a collection of services to its environment, published
via <<provided>> interfaces and accessed at runtime via ports. A provided
interface is a contract for service. If, in turn, a structured class uses the services
of other instances (including structured classes), it can place demands on these
instances by <<required>> interfaces. UML uses the ball-and-socket notation
for the provided (ball) and required (socket) interfaces (see Figure 10). Ports
can be thought of as being typed by their interfaces. Typed ports serve as

Figure 10. Structured class, ports, provide and required interfaces, and
connectors

StructuredClass

1 1
port_cl InstanceA InstanceB port_serv

iRequest iService
1
InstanceC

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Oriented Modeling in UML2 21

access points for interactions between the internal parts of the structured class
and its environment.
Ports relay the incoming messages to the internal parts and the outgoing
messages from the internal parts to the external objects attached to the
structured class through connectors without revealing the part’s identity.
To summarize, a port publishes the operations implemented by a collaboration
of internal parts on the structured class border. The structured class boundary
and ports decouple the internal elements from the external environment, thus
making a structured class reusable in any environment that conforms to the
required interfaces imposed by its ports.

Components
A UML component is a structured class providing a coherent set of services
used and replaced together. A component’s behavior is specified in terms
of provided and required interfaces. We say that a component is typed by
its interfaces. A component may be substituted by another one, only if the two
are type conformant. There are no differences between structured classes and
components, except for the connotation that components can be configured
and used like Lego blocks in different contexts to build things.
At present, the most widely used commercial component frameworks are
Enterprise Java Beans, .NET, COM+, and CORBA Component Model.

Subsystem
A subsystem is a large-scale component and a unit of hierarchical decompo-
sition. At the highest level, a system is decomposed into several subsystems. In
addition to a collection of services, a subsystem defines a namespace for its
parts. A subsystem may have separate specification and realization parts
stereotyped respectively as <<specification>> and <<realization>>. This
makes it possible for one specification to have multiple realizations.
Components can be assembled in an enclosing <<subsystem>> container by
wiring together their required and provided interfaces. The components’
interfaces are linked either by connectors or by dependency relationships
(see Figure 11).
The Infrastructure package is a container for common elements such as types
(classes and interfaces) exposed in component interfaces, usage points (ser-
vices), and extension points (classes to subclass in other packages).

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
22 Roussev

Figure 11. Components, subsystems, and packages

RegisterDriver
port_get_card port_debit
debitOperation
iGetCard iDebit
<<Subsystem>>
RegisterDriver RegisterDriver
<<flow>>
iGetCard port_debit

port_card iDebit
PassOnePointTG
<<Subsystem>> <<Component>>
port_debit
port_get_card
iGetCard
iDebit
<<Subsystem>>
Infrastructure

CreditCardInfo iDebit
<<interface>>

iGetCard Confirmation
<<interface>>

Since structured classes, components, and subsystems are classes (unlike

packages), they may participate in associations and generalizations.

Constraints and Object Constraint Language

Constraints are a fundamental part of a system’s structure and semantics. The
Object Constraint Language (OCL) (Warmer & Kleppe, 1998) is a formal,
pure expression language augmenting graphical UML models to produce
unambiguous and precise system descriptions. OCL is an integral part of UML,
and it is used to define the semantics of UML. OCL combines first-order
predicate logic with a diagram navigation language. It provides operations on
sets, bags, and sequences to support the manipulation and queries of collec-
tions of model elements.
UML uses OCL to express constraints, navigability, action semantics, and object
queries. Even though visual models define some constraints, like association
multiplicities, in OCL we can specify richer ones, such as uniqueness constraints,
formulae, limits, and business rules. OCL constraints provide precision, which
facilitates design by contract and executability (see Chapter II).
Very succinctly, a constraint is a semantic restriction on one or more model
elements. Types of constraints include, but are not limited to, constraints on

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Oriented Modeling in UML2 23

Figure 12. Class diagram

Driver
CreditCard 1 R4 1..* Vehicle 1..* R1 1
covered_by charged_for owns belongs_to
LastName
Age
1 made_by

R5

0..* gets
Passage 1 R6 0..1 Payment
calculateRate() is_for is_paid Amount

associations between classes, pre- and post-conditions on class operations,

multiplicity of class instances, type constraints on class attribute values,
invariants on classes, and guards in state models.
Each OCL expression is written and evaluated in the context of an instance of
a model element. Let the context be an instance of class Driver, shown in Figure
12 (the irrelevant elements on the class diagram are suppressed). We can
restrict the driver’s age to 16 years with the following constraint.

context Driver inv:

self.Age > 16

As another example, if we want to make sure that all tags have unique IDs, we
can write:

context Tag inv:

Tag.allInstances()->forAll(t1, t2 |
t1<>t2 implies t1.TagID <> t2.TagID)

Pre- and post-conditions specify the effect of a class operation without stating
its algorithm or implementation. To indicate the operation for which the
conditions must hold, we extend the constraint’s context with the operation
name. For example,

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
24 Roussev

context CreditCard::Charge(Amount: Real): Boolean

pre: self.IsValid
post: self.Balance = self.Balance@pre + Amount

where Balance@pre refers to the value of the attribute at the start of the
operation.
Next, we show how starting from a specific instance we can navigate its class
associations to refer to related objects and the values of their attributes. To
navigate association R6 in Figure 12, we use the association’s label and the role
predicate at the far end:

context Payment inv:

self.Amount = self.R6.is_for.CalculateRate()

It is important to note that OCL is not a programming language, and OCL

expressions cannot, therefore, express assignment statements or flow of
control. The evaluation of an OCL expression is instantaneous, meaning that
the states of the objects in a model cannot change during expression
evaluation.
Often OCL expressions are critiqued for having poor readability and for being
inefficient in specifying requirements-level and analysis-level concepts (Ambler,
2002). This critique comes from methodologists favoring code over models
and from system analysts using UML diagrams as sketches of OO designs, the
so called UMLAsSketch.4 To improve OCL readability, Mellor (2002, p.128)
introduces the notion of constraint idiom as a general pattern for commonly
occurring types of constraints and suggests the use of predefined tags for these
types. The latter makes models less cluttered and less cryptic (see Chapter 2).
Since constraints are a fundamental part of the semantics of a problem domain,
there is no simple alternative for building precise models.
With OCL, an object’s interface can be defined as a set of protocols to which
the object conforms. A protocol consists of the following three invariants
defined for each operation: pre-condition, post-condition, and operation
signature.
Constraints do not have to be written in OCL. They can be specified in any
action language supporting the Precise Action Semantics for UML (UML AS,
2001), for example, OAL (2004) and KC (2004). However, action languages

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Oriented Modeling in UML2 25

are not specification languages. Their purpose is to define computations in

executable models.

Object Behavior

We are interested in how objects act both in isolation and in collaboration

with other objects. In UML, the former behavior is modeled with FSM
models, while the latter is modeled with communication (formerly collabo-
ration diagrams) and sequence diagrams.

State Dependent Behavior

In order to determine the future actions of a class instance, we need to know

its past, a rather Newtonian approach.5 For example, the answer to the
question “Can I withdraw $50 from my account?” depends upon the history
of deposit and withdrawal transactions carried out. If the owner has
deposited $60 and withdrawn $20, the answer will be “No,” given that the
account cannot be overdrawn.
We could succinctly represent the history of the bank account by its balance,
$40, rather than the whole sequence of past bank transactions. To do so, we
can add an attribute, say Balance, to class BankAccount, and base the behavior
of operation Debit() on the value of the new attribute.
We call the abstract representation of an object’s history state. The state of an
object represents that object’s potential, or in other words, the actions in which
the object can be engaged.
It takes a lot of sophisticated and error-prone code to manage the concurrent
access to the data and operations of objects with a great number of states.
For such objects, it is better to model explicitly their states, state evolution,
and the relation between states and allowed actions. An object can progress
through different states over its lifetime. This progression is called lifecycle.
An FSM model defines the lifecycle of a state-dependent class. In UML,
statecharts diagrams visualize FSMs. FSM models comprise four types of
elements: states, transitions, events, and procedures.
A state represents a stage in the lifecycle of an object. The states are a bounded
set of mutually exclusive conditions of existence: at any moment, an object is
in exactly one state, referred to as current state. Signals are incidents in the

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
26 Roussev

domain modeled as events. They can be internal (generated by the FSM) or

external (generated by other FSMs). A transition points to “the next” state,
which the object will enter from the current state upon receipt of a particular
event. States are drawn as rectangles with rounded corners and transitions as
arrows. Each state has a name. A transition is labeled with the event that causes
the transition.
In the executable UML profile, the FSM model includes procedures of actions
(executable sections), one per state, executed on entry to a state. Figure 13
shows the FSM for class Tollgate. For readability’s sake, we have written the
state procedures in pseudo code. The initial state for the FSM is NewTollgate.
In this state, the tollgate controller sets its own location and rate, and then it
relates itself to an instance of class Lights. Once related, the tollgate controller
signals the Lights instance to turn its green lights on. Next, the initialized tollgate
generates signal operate(mode) to itself to transition to state Ready. This signal
is shown as an event attached to the transition from state NewTollgate to state
Ready. In state Ready, the tollgate checks the mode value provided by event
operate(mode) to see if it has to send a signal to the lights controller to turn its
yellow lights on, and then waits passively to receive a “tag detected” signal from
its sensor. Upon receipt of detectTag(), the tollgate enters state VerifyTag and
executes its state procedure. The procedure verifies the detected tag, creates
a new Passage instance, and transitions to state CreatePayment. If the tag is
invalid, the tollgate goes back to state Ready. In state CreatePayment, the

Figure 13. FSM model for class Tollgate

NewTollgate Ready
entry/ entry/
// Set location and rate operate(mode) // If mode is 2
// Relate self to lights // Generate signal to turn yellow lights on
// Generate signal turn lights green // Else
// Generate signal to transition to // Transition to state VerifyTag
state Ready // End if

operate(mode)
operate(mode) detectTag(tagID)

VerifyTag
entry/
CreatePayment
// If the tag is valid
entry/ procPayment() // Create a new Passage instance
// Create a new credit card charge
// Transition to CreatePayment
// Generate signal to self to transition to
// Else
state Ready
// Generate signal operate(2)
// End if

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Oriented Modeling in UML2 27

tollgate retrieves the credit card, serving the vehicle related to the detected tag,
and creates a Payment instance, taking care of charging the credit card. At this
point, the tollgate returns to state Ready to process the next vehicle.
Not all classes exhibit interesting lifecycles. The behavior of a class can be
defined as state dependent or simple (state independent). FSM models are not
constructed for simple classes.

Collaborative Behavior

In order to work toward achieving a common goal, objects interact by calling

synchronously each other’s operations, called message passing, or by sending
asynchronously signals modeled as events. Interactions can be visualized on
interaction diagrams, which come in two main forms: sequence and communi-
cation diagrams.
Unlike FSMs, interaction diagrams do not tell the complete story about the
involved objects. Instead, they focus on particular sequences of messages
or events, called scenarios or traces. Scenarios are used to communicate
with stakeholders or to conduct interaction analysis. Interaction analysis
aims at understanding and defining the communication patterns within a
collaboration of objects realizing one or more user requirements.
If we have to compare interaction diagrams to FSMs, we can say that, apart
from their scope—individual versus group—the former provide a black box
view of the participating instances, while the latter afford a white box view of
the ways in which instances respond to signals and messages. For this reason,
interaction diagrams are said to be partially constructive, and as such, they
cannot be used to generate code.

Sequence Diagrams
Once the elicited user requirements are modeled with use cases and the classes
supporting the use cases are discovered, it is time to verify the decisions made.
An important objective in the early stages of a project is to mitigate risks and
to gain a high level of confidence in the discovered classes and their responsi-
bilities. Mistakes at early stages are costly since they result in backtracking and
extensive rework.
Interaction analysis is a technique employing sequence diagrams to analyze the
dynamics of the classes derived from a use case description. Sequence

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
28 Roussev

diagrams have the following uses: (1) to analyze the dynamic interactions
between class instances and to reduce the risk of incorrect class discovery; (2)
to create traceability relationships from use cases to class diagrams;( 3) to
tackle the problem of allocating responsibilities among classes and to define the
class interfaces (public operations); and (4) to plan functional system testing.
Sequence diagrams display the causal dependencies among messages and
signals exchanged between lifelines of instances and their relative time
ordering. Figure 14 shows how a sequence diagram portrays the time ordering
of the messages exchanged among instances during the execution of a scenario.
The instances taking part in the scenario are arranged along the X-axis, with the
initiating instance (usually an actor) being on the far left side. The lifelines of the
instances are represented as vertical bars, with time flowing from top to bottom.
Messages and signals are modeled as arrows pointing to the receiver. Signals
are modeled with a half arrowhead, while messages are modeled with a full
arrowhead. The direction of the arrowhead is indicative of the invocation
direction and not of the data flow. The lifeline of an object created or destroyed
during an interaction starts or ends, respectively, with the receipt of a message
or signal. A large X marks the end of a lifeline. The focus of control is a rectangle
superimposed over a lifeline, indicating that the instance is performing an action.
The top of the rectangle coincides with the start of the action, while its bottom
aligns with the action’s completion.
The black box view offered by a sequence diagram can be cracked open if
instead of focus of control, the modeler shows the names of the states through
which the instance progresses.

Communication Diagrams
A communication diagram is an object diagram showing the messages and their
ordering attached to the static links between the objects, as illustrated in Figure
14. A communication diagram emphasizes the organization of the objects.
To sum up, interaction diagrams lack the completeness of FSMs. They are used
primarily to explore and verify a particular scenario rather than build an artifact.
During exploration, new messages, signals, operations, and even classes can be
discovered and added to the model.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Oriented Modeling in UML2 29

Figure 14. Sequence and communication diagrams

: Sensor : Tollgate : Passage : Vehicle : Payment

: Driver
pass_by
detectTag
create

getCCard

: Sensor 9: operate : Payment

makePayment 1: pass_by 2: detectTag 7: makePayment

operate
8:
: Tollgate

4: 5: getCCard

: Driver

3: create 6:
: Passage : Vehicle

Some Merits and Deterrents

Advantages

According to many authors, OO is advantageous because it allows for a

seamless transition between the phases of software development by using
a uniform language for requirements engineering, analysis, design, and
programming.6 This is a major prerequisite for transformational development,
where the system is built in a sequence of transformations or refinements from
more abstract to more detailed models. Each transformation or refinement
preserves the source model properties in the target model.
OO narrows the semantic gap between entities in the problem and the solution
domains, leading to better traceability, and ultimately, to better chances of
validating the software artifacts by customers.
Improved interpersonal communications through objects is another success
factor. OO encourages a common vocabulary between end users and develop-
ers (Booch, 1996).
As a system evolves, the function or the business processes it performs tend to
change, while the object abstractions tend to remain unchanged. Thus, remov-
ing the emphasis on functions results in more maintainable designs. When

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
30 Roussev

changes are necessary, OO contains changeability through locality of change.

Inheritance and polymorphism make OO systems easier to extend.
OO analysis emphasizes the importance of well-defined interfaces between
objects, which led to the development of components.

Disadvantages

Traditionally, OO methods have paid little attention to business modeling,

a very important area of software development. The enterprise business
model represents the business concepts in the problem domain. An explicit
description of the system’s business processes leads to a better understand-
ing of the role of the system in the organization, and therefore, the resulting
system is more likely to be appropriate to the problem being solved.
Though OO modeling is supported by object abstraction, this device alone
cannot capture aspects bigger than small-scale entities. There are many
pervasive requirements (e.g., security, concurrency, transaction manage-
ment) that do not decompose into behavior centered on a single locus. In
addition, the gains from reusability at the object (i.e., class) level are insignifi-
cant. The real benefit from reusability comes at the component level, and even
more so at the architecture level and domain level.
OO might exacerbate the “analysis-paralysis” problem. Because of the uniform
notation, there is a strong temptation to design rather than perform analysis.
Another downside of OO modeling is that it takes myriads of models to
understand and express objects: static (class and deployment diagrams),
behavior models (sequence, communication, diagrams, and use cases), and
state-change models (statechart and activity diagrams).
UML2 is expected to add new features to the OO modeling repertoire. This
raises reasonable concerns and is rightfully perceived by developers as a
language bloat. To counter this effect, the creators of UML2 maintain that the
modeling language has been compartmentalized in two ways. First, the different
sub-languages are meant to be independent of each other, which, if true,
threatens to invalidate the multi-view approach to system modeling. Second,
they say that learning UML2 is not an “all or nothing” proposition. UML
modelers will be able to select only those parts that are useful in solving their
problem and safely ignore the rest. In our view, the latter is easier said than
done. In order to choose which part of UML to leave out, the developer should

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Oriented Modeling in UML2 31

be familiar with the capabilities and limitations of all parts of the language, so
sufficient breath of knowledge is still required.

Conclusion

It is firmly believed that the solution to the current software crisis depends on
raising the level of abstraction of the constructed software artifacts and on
increasing the level of automation in the software design process. “Divide and
conquer” proved insufficient to contain the software complexity. This point is
illustrated by the revised Roman adage, “Divide to conquer, but unite to rule.”
Abstraction and automation are the only effective means we can apply to curb
complexity that overwhelms our cognitive capacities. “Un-mastered complex-
ity” is the root cause for the software crisis.
The use of models with executable semantics is set to move into the mainstream
of OO software development. Automation through executability challenges the
tacit assumption that software development will remain the same type of mental
activity it has always been—that is, given a problem, a developer should
liberally apply creativity to synthesize a solution. The “liberal creativity”
approach rules out a quantum leap in the ability to develop software, because
the human mind does not evolve in sync with the growing software complexity.
As Herbert Robins has stated, “Nobody is going to run 100 meters in five
seconds, no matter how much is invested in training and machines. The same
can be said about using the brain. The human mind is no different now from what
it was five thousand years ago. And when it comes to mathematics [understand
software], you must realize that this is the human mind at an extreme limit of its
capacity.”
Dijkstra’s reaction to this statement was “So reduce the use of the brain and
calculate!” and then, Dijkstra went on to elaborate that “for going from A to B
fast, there exist alternatives to running that are orders of magnitude more
effective.” Robbins’ argument fell flat on its face.
The advantage of adding automation to object-oriented models is, in
Dijkstra’s spirit, increased use of calculation at the expense of “liberal
creativity” to master the software complexity and put the software crisis to
rest.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
32 Roussev

With less emphasis on programming, requirements engineering and systems

analysis will become more and more important as time goes on. Mellor has aptly
said that the model is the code. Since models are derived from user require-
ments, we can conclude by transitivity that in the OO future, the user will be the
code.

References

Ambler, S. (2002). Toward executable UML. Software Development Jour-

nal, (January).
Atkinson, C., Bayer, J., & Muthig, D. (2000). Component-based product line
development. The KobrA approach. Proceedings of the 1st Software
Product Lines Conference (SPLC1) (pp. 289-309).
Bayer, J., Flege, O., Knauber, P., Laqua, R., Muthig, D., Schmid, K., Widen,
T., & DeBaud, J. (1999). PuLSE: A methodology to develop software
product lines. Proceedings of the Symposium on Software Reusabil-
ity (SSR’99).
Beck, K. (1999). Extreme programming explained: Embrace change.
Reading, MA: Addison-Wesley.
Beck, K., & Cunningham, W. (1989). A laboratory for teaching object-
oriented thinking. Proceedings of OOPSLA ’89. ACM SIGPLAN
Notices, 24 (pp. 1-6).
Bettin, J. (2004). Model-driven software development: An emerging paradigm
for industrialized software asset development. Retrieved from http://
www.softmetaware.com
Bettin, J. (2005). Managing complexity with MDSD. In B. Roussev (Ed.),
Management of the object-oriented software development process.
Hershey, PA: Idea Group Inc.
Booch, G. (1993). Object-oriented analysis and design with applications
(2nd ed.). Reading, MA: Addison-Wesley.
Booch G. (1996). Object solutions. Reading, MA: Addison-Wesley.
Booch, G. (1996). Object solutions: Managing the object-oriented project.
Reading, MA: Addison-Wesley.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Oriented Modeling in UML2 33

Bosch, J. (2000). Design and use of software architectures: Adopting and

evolving a product line approach. Reading, MA: Addison-Wesley.
Brooks, F. (1998). The mythical man-month: Essay of software engineer-
ing (anniversary ed.). Reading, MA: Addison-Wesley.
Chen, P. (1977). The entity-relationship approach to logical data base
design. Wellesley, MA: Q.E.D. Information Sciences.
Coad, P., & Yourdon, E. (1991). Object-oriented design. Englewood
Cliffs, NJ: Prentice-Hall.
Codd, A.F. (1970). A relational model for large shared data banks.
Communication of the ACM, 13(6).
Coleman, D., Arnold, P., Bodoff, S., Dollin, C., Gilchrist, H., Hayes, F., &
Jeremaes, P. (1994). Object-oriented development: The fusion method.
Englewood Cliffs, NJ: Prentice-Hall.
Cook, S., & Daniels, J. (1994). Designing object systems: Object-oriented
modeling with Syntropy. Englewood Cliffs, NJ: Prentice-Hall.
Czarnecki, K., & Eisenecker, U. (2000). Generative programming: Meth-
ods, tools, and applications. Reading, MA: Addison-Wesley.
D’Souza, D., & Wills, A. (1998). Objects, components and frameworks
with UML: The catalysis approach. Reading, MA: Addison-Wesley.
Firesmith, D., Henderson-Sellers, B., & Graham, I. (1998). OPEN modeling
language reference manual. New York: Cambridge University Press.
Fowler, M. (2003). UML distilled: A brief guide to the standard object
modeling language (3rd ed.). Reading, MA: Addison-Wesley.
Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design patterns:
Elements of reusable object-oriented software. Reading, MA:
Addison-Wesley.
Garzás, J., & Piattini, M. (2005). Improving the OO design process using rules,
patterns, and refactoring. In B. Roussev (Ed.), Management of the
object-oriented software development process. Hershey, PA: Idea
Group Inc.
Graham, I. (1994). The SOMA method: Adding rules to classes. In A.
Carmichael (Ed.), Object development methods (pp. 199-210). New
York.
Graham, I., & Wills, A. (2001). UML—A tutorial. Retrieved from
www.trireme.com

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
34 Roussev

Henderson-Sellers, B., & Edwards, J.M. (1994). BOOKTWO of object-

oriented knowledge: The working object. Prentice-Hall.
Jacobson, I. (1987). Object-oriented development in an industrial environ-
ment. ACM SIGPLAN Notices, 22(12), 183-191.
Jacobson, I. (1992). Object-oriented software engineering: A use case
driven approach. Reading, MA: Addison-Wesley.
Kiczales, G. (1996). Aspect-oriented programming. Computing Surveys,
28(4), 154.
Kruchten, P. (2000). The rational unified process: An introduction.
Reading, MA: Addison-Wesley.
Lacan, J. (1977). Ecrits: A selection (A. Sheridan, trans.). London:
Tavistock.
Lamsweerde, A. (2000). Requirements engineering in the year 00: A
research perspective. Proceedings of the 2nd International Confer-
ence on Software Engineering. Limerick: ACM Press.
Laplante, P.A., & Neill, C.J. (2004). “The demise of the waterfall model
is imminent” and other urban myths. ACM Queue, (February), 10-15.
Martin, J., & Odell, J. (1992). Object-oriented analysis & design.
Englewood Cliffs, NJ: Prentice-Hall.
MDA. (2004). OMG Model-Driven Architecture. Retrieved from
www.omg.org/mda
Mellor, S.J., & Balcer, M.J. (2002). Executable UML: A foundation for
Model-Driven Architecture. Reading, MA: Addison-Wesley.
Miller, J. (2002). What UML should be. Communications of the ACM,
45(11).
OAL. (2004). BridgePoint object action language. Retrieved from
www.projtech.com
Paige, R.F., & Ostroff, J.S. (1999). A comparison of the business object
notation and the Unified Modeling Language. In R. France & B. Rumpe
(Eds.), Proceedings of <<UML>>’99—The Unified Modeling Lan-
guage Beyond the Standard, Fort Collins, Colorado, USA.
PL. (2004). SEI collection of resources on product lines. Retrieved from
www.sei.cmu.edu
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Loensen, W. (1991).
Object-oriented modeling and design. New York: Prentice-Hall.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Oriented Modeling in UML2 35

Shlaer, S. & Mellor, S.J. (1988). Object-oriented systems analysis: Model-

ing the world in data. Englewood Cliffs, NJ: Prentice-Hall.
Shlaer, S., & Mellor, S.J. (1992). Object lifecycles: Modeling the world in
states. Englewood Cliffs, NJ: Prentice-Hall.
UML. (2004). Unified Modeling Language. Retrieved from www.uml.org
UML AS. (2001). UML Action Semantics. Retrieved from www.omg.org
Warmer, J., & Kleppe, A. (1998). The Object Constraint Language:
Precise modeling with UML. Reading, MA: Addison-Wesley.
Wendorff, P. (2001). Assessment of design patterns during software
reengineering: Lessons learned from a large commercial project.
Proceedings of the European Conference on Software Maintenance
and Reengineering (pp. 77-84).
Wirfs-Brock, R., Wilkerson, B., & Wiener, L. (1990). Designing object-
oriented software. Englewood Cliffs, NJ: Prentice-Hall.
Withey, J. (1996). Investment analysis of software assets for product lines.
Retrieved from http://www.sei.cmu.edu/publications/documents/
96.reports/96.tr.010.html

Endnotes
1
“The limits of my language mean the limits of my world” - Ludwig
Wittgenstein.
2
DSLs (domain specific languages) are modeling languages targeting a
particular technological domain or problem.
3
The linguistic approach to object-orientation is an ongoing interdisci-
plinary project with Yvonna Rousseva, who is credited with the idea
of redefining objects through the premises of the theory of
deconstruction.
4
Fowler (2003) divides the use of UML into UMLAsSketch, UMLAs
BluePrint, and UMLAsProgrammingLanguage.
5
In Newtonian mechanics, if we know the trajectories of a system of
bodies, we can determine the positions of the bodies at any future moment.
6
Other authors see this as a weakness, for example, Knott et al. (2005),
included in this book.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
36 Roussev

Chapter II

MDA with xUML:

Model Construction and
Process Management
Boris Roussev
University of the Virgin Islands, USA

Abstract

xUML epitomizes the convergence of visual modeling with model

manipulation programming. The results of this merger are executable
models and model-driven software development. This chapter presents
the fundamental notions of constructing executable domain models with
xUML, as well as the principles of the MDA approach. In particular, we
define the new roles of the developers in development processes based on
MDA and the MDA activity workflow. We discuss also the output artifacts
from each activity. As new technologies require new software development
processes, we present an iterative and incremental model-driven process,
combined with techniques for project planning and progress estimation
based on BERT and ERNIE. We show how model executability creates
congenial conditions for the application of higher-order cognitive skills in
the software development process, and for the substitution of liberal
creativity with design automation.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 MDA with xUML: Model Construction and Process Management 37

Introduction

C.A. Petri was the first to define formally the notion of communicating state
machines in his PhD thesis, “Kommunikation mit Automaten,” back in 1962.
His visual modeling language for modeling concurrency and synchronization,
later known as Petri nets, is an extension of the Finite State Machine (FSM)
theory. Even though Petri nets is an intuitive and powerful process coordination
language, several pieces were crucially missing to bridge the Petri nets paradise
to the real world. Petri nets lacked an information structure model such as class
diagrams, a development process for effective product development from
informal requirements such as Agile (Beck, 1999), and action semantics (other
than transition firing rules). Action semantics defines a virtual machine for model
interpretation, giving substance to the notion of model “executability.”
The Shlaer-Mellor method (Shlaer & Mellor, 1988, 1992), one of the first
object-oriented (OO) analysis methods, uses class diagrams to represent the
information structure of a system. This information model was influenced by the
relational theory of data (Codd, 1970) and database modeling with entity-
relationship diagrams (Chen, 1977). Shlaer and Mellor reinvented the idea of
communicating FSMs in the context of OO by employing FSMs to abstract
lifecycles of objects, whose progression is driven by external or internal
asynchronous signals. They describe objects’ execution behavior as state
procedures consisting of actions. The actions perform tasks on modeling
elements; for example, they traverse an association link to retrieve the value of
an attribute in a related instance, or generate signals to the FSMs of related
objects. Shlaer and Mellor advanced the idea of composing complete systems
out of executable models.
Shlaer and Mellor put at the top of the OO agenda the notion of model
executability. Their method evolved into a pure object-oriented notation
(Mellor & Balcer, 2002; Mellor et al., 2004), which is currently shaping up the
future of UML.
Model-Driven Architecture (MDA) (Mellor & Balcer, 2002) is a term defined
by OMG. The MDA approach to software development relies on Executable
UML (xUML) (MDA, 2004), a UML profile with executable semantics. MDA
distinguishes between Platform Independent Models (PIM) and Platform
Specific Models (PSM).
In MDA, software does not need to be programmed at all, or at least not by
humans. This can be achieved through the integration of a programming

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
38 Roussev

language at a high level of language abstraction into a visual modeling language.

The result is a modeling language with executable semantics. The models
constructed with such languages can be simulated and debugged—that is,
validated at model level and then compiled to source code for any target
platform. This eliminates the verification gap between visual software models
and end users. As a result, a system can be delivered in small increments of
executable models produced in fast cycles.
MDA spearheads the new wave of OO technologies aiming at design automa-
tion and at IT artifacts construction at a higher level of abstraction. MDA is kith
and kin with technologies such as generative programming (Czarnecki &
Eisenecker, 2000) (transformational mappings), aspect-oriented program-
ming (Kiczales, 1996) (merging mappings), design patterns (Gamma, Helm,
Johnson, & Vlissides, 1995) (modeling societies of objects along with their
interactions), product lines (PL, 2004) (clear separation between application
logic and software architecture), MDSD (Bettin, 2004) (design automation),
Microsoft’s software factories, domain engineering (PL, 2004) (software
assets), and domain-specific languages (Czarnecki & Eisenecker, 2000)
(metamodeling and domains).
This chapter has several objectives: 1) to examine the relationship between
cognitive skills and model-driven software design; 2) to justify the adoption of
the MDA approach; 3) to present in sufficient detail the xUML technology; 4)
to define the developer roles in the MDA process; 5) to present the operational
structure of an MDA process; and 6) discuss issues in planning xUML projects.
The examples in this chapter are from the E-ZPass system described in Chapter
1. The rest of the chapter is organized as follows. First, we discuss how merging
mappings, called bridges, resolve the interface problem in component-based
software design and justify the adoption of MDA. Next, we show how to
construct executable models and present an iterative process for model-driven
development with xUML. In the final section, we offer our conclusions.

Abstract Executable Assets

In this section, we discuss how model executability, model mapping, and

software design at a higher level of abstraction blend together to produce
software assets.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 MDA with xUML: Model Construction and Process Management 39

Constructing Assets with Late Component

Externalization

Objects have not lived up to all expectations. They have turned out to be
disproportionately small compared to the size of the systems being built with
them. Gamma et al. (1995) showed the advantages of reusing collections of
related objects. In the E-ZPass system, for example, a vehicle inevitably
belongs to a driver, and it only makes sense to reuse these two objects together.
Societies of closely related objects provide the foundation for components. A
component is an encapsulation of objects exposing a set of interfaces. With
components, a system is described in terms of interactions among component
interfaces and is built by wiring up these interfaces. There are two major
challenges to component-based software development. The first is active
dependency management—how to minimize the dependencies among compo-
nent interfaces. A component is said to have a fully externalized interface if all
types exposed in its interfaces are defined in a package residing outside the
component (Bettin, 2005). The fully externalized interface defines the usage
environment of the component, and decouples the component from its peers.
However, even with active dependency management, a small change in one of
the interfaces entails locating every place where the interface is used, changing
it to use the new interface, unit test the new code, reintegrate, and then
integration test the whole system (Mellor et al., 2004). The second challenge
to component-based development is how to wire up the component interfaces.
Wiring is done with glue code, which prevents the reuse of the individual
components in a new environment since the components become dependent on
the glue code. The remedy to this problem is to apply late (or dynamic)
externalization, meaning to externalize the interfaces and apply the glue code
just before the system is deployed. Late externalization makes each component
a reusable asset, and not a liability (Bettin, 2005).
MDA achieves late externalization through bridges. Bridges are formal map-
pings between modeling elements of two executable models. Ironically, inter-
faces decouple components, and in turn, bridges decouple (or localize)
interfaces.

Do Not Work Harder, Work Smarter and Get Help

It is well known that software creators labor away at their products under the
intense pressure of the time-to-market force and the ever-increasing demand

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
Discovering Diverse Content Through
Random Scribd Documents
de veinte juzgados de campaña, indica con razon, "que merece
llamar la atencion el corto número de artesanos que hai en aquellos
partidos, en los que podrian, dice, hallar ocupacion lucrativa un
número diez veces mayor, especialmente carpinteros, albañiles,
herreros, etc." Pero ya hemos indicado la verdadera causa de este
fenómeno; i es faltar la materia primera de las artes en cada una de
esas localidades. Si ha de traerse del puerto la madera i el hierro en
bruto ¿no vale mejor traerlo labrado en puertas i cerraduras? Otro
hecho notado por el señor Maezo es mui ilustrativo. De quinientos
treinta i dos europeos que poseen majadas de ovejas, solo setenta i
nueve poseen la tierra en que las apacentan. ¿Cuál es la condicion
social de los cuatro cientos cincuenta i tres restantes? Son inquilinos,
arrendadores, o toman prestada esa tierra? He aquí en signos
palpables los síntomas del desórden social que apuntamos. Todos los
propietarios de majadas son irlandeses, escoceses, o ingleses; es
decir gran número de ellos, resto de las colonias que empezaron a
formarse en 1825. Estos antiguos residentes en el país, con un
capital para poseer ovejas, no han podido sin embargo adquirir
tierra, que es lo que fija al hombre en un país. ¿Quién les ha
estorbado poseerla? Así pues, el artesano no acude a la campaña, ni
el que se consagra al pastoreo se afinca. ¿Qué haría Buenos-Aires, si
como Nueva-York recibiese en dos dias consecutivos, el sábado i el
lúnes 21 de octubre, nueve mil trescientos cincuenta i cuatro
emigrantes de un golpe[12]? ¿Los dueños de saladeros o de
estancias ocuparian a los que por su falta de capital o de capacidad
industrial se resignen a trabajar como peones gañanes; pero la
inmigracion mas útil que va a los Estados-Unidos no es esa, sino la
de hombres que poseyendo un capitalito buscan tierra barata para
poseer un domicilio i fundar una familia, o los que ejerciendo una
industria desean ponerla a provecho en países donde no haya la
concurrencia que en Europa; i estos se verán pronto forzados a
emigrar de nuevo en busca de país mas adecuado, desde que en la
ciudad i puerto de Buenos-Aires se acumulen muchos artesanos, i
abunden los hombres que hacen el comercio de menudeo, ya que la
campaña, por mas que parezca, es inabordable para las profesiones
industriales i la posesion de la tierra, que es la base de la
agricultura. El sistema de poseedores del suelo, labrado por
arrendadores e inquilinos ha arruinado a la Irlanda, despoblándola
de dos millones de habitantes en estos diez últimos años, segun
resulta de la comparacion de los censos de 1841, i 1851[13]. Otro
sistema, otras leyes, otras instituciones preparatorias necesita
Buenos-Aires para desarrollar sus inmensos recursos, i el sistema
que propongo sería el mas sencillo de todos los andamios que deben
construirse para obra tan grande. No olvidemos que lo que se llama
campaña es el asiento en donde han de existir ciudades, villas,
aldeas, i que, para que la poblacion se aglomere en un punto, es
preciso que haya una razon de conveniencia que lo exija.
Veráse pues, que al pedir como base para una lei eficaz de
educacion comun, cierta estension de territorio de distancia en
distancia, no he obedecido a principios teóricos de distribucion
ordenada de los medios de difundir los conocimientos, ni cedido a la
anticipacion de una época lejana, cuando con el transcurso del
tiempo haya de rebozar de poblacion la tierra que hoi ocupa el
ganado. Ni pretendo cambiar bruscamente industria que, aunque
mezquina en sus resultados jenerales, es pingüe para el reducido
número de los que la esplotan. Pido solo los medios de irla
conduciendo sin trastorno a camino mas productivo para el
propietario actual, sin ser ruinosa para el país. I sin embargo, haya o
no habitantes hoi en cada punto del territorio de Buenos-Aires, el
hombre de estado debe suponer que debe haberlos mas tarde o mas
temprano, si no se resigna desde ahora a creer que esa parte de la
tierra ha de permanecer por siempre despoblada. Es por esto, que
sobre el mapa han de fijarse los locales de escuelas, a las distancias
menores posibles que sea permitido, en consideracion a la
actualidad, designarlas. El plan propuesto no hace mas que
restablecer el órden primitivo que debió seguirse para la enajenacion
de las tierras públicas, abandonadas a la esplotacion particular, sin
las reservas que el interés comun reclamaba. Por la lei de tierras de
los Estados-Unidos, con la sábia prevision que distinguió a los
primeros lejisladores de aquella gran república, se ordenó medir las
tierras en manzanas de dos leguas cuadradas de frente, subdivididas
en lotes de una milla cuadrada cada uno, como se ve en el plano
siguiente, en el cual se señalan con números gruesos las reservas
del Estado, para proveer a las necesidades de la futura poblacion. Es
ajeno de mi propósito entrar en el detal de la distribucion de cada
uno de los lotes ofrecidos en venta, los cuales deben venderse uno
entero, i el siguiente por secciones de mitad, i de un cuarto, con el
fin de que se promedien propietarios de una milla cuadrada, i otros
de algunas cuadras, dando así lugar a todas las fortunas, i
mezclando la poblacion.

MUNICIPIO.

1 2 3 4 5 6
12 11 10 9 8 7
13 14 15 16 17 18
24 23 22 21 20 19
25 26 27 28 29 30
36 35 34 33 32 31
A la venta pública se entregan todos los lotes, excepto los números,
8, 11, 16, i 29 que se reservaron para las escuelas, i otros objetos
de interés público, por lo que independiente de las ciudades i
poblaciones que habrian de fundarse donde quiera que las
circunstancias locales favoreciesen su desarrollo, se dejó ya
designado un local, de cuatro en cuatro millas de distancia, a
disposicion de los venideros, a fin de que no les sucediese lo que en
Chile, i en todas partes, que cuando llegó la época de fundar
escuelas, se encontraron con toda la tierra ocupada i sin medios de
edificarlas ¿Creeráse que hai en Chile finca en cuyo territorio viven
englobados dos mil inquilinos, a quienes el propietario del suelo no
da educacion ni proporciona maestros, por no ser necesarios para el
servicio de su hacienda peones que sepan leer[14]?
La medida que propongo es pues, la reparacion simple de una
omision imprevisora; sin que se crea que estas reversiones de la
propiedad territorial al donador primitivo, carecen de ejemplo en
nuestras leyes. La alcabala es de esta clase, pues que imponiendo
un cuatro por ciento sobre el valor de la venta de las propiedades
raíces, en veinte i cinco veces que el fundo cambia de poseedor, el
Estado ha vuelto a recuperar no solo la donacion primitiva sino una
parte de las mejoras, i aumento de valor que fué adquiriendo
sucesivamente. No sería repugnante recurso en nuestros países,
para remediar la mala distribucion de la tierra hacer pagar la
alcabala en la tierra inculta, haciendo una separacion de un pequeño
lote de terreno toda vez que pasase de un poseedor a otro. El
momento de la enajenacion o el de la trasmision de la propiedad es
el que la lei ha escojido para imponerla estos gravámenes, porque es
el momento en que el sentimiento de la propiedad se debilita o
muere en el poseedor, i aun no ha cobrado fuerza en el que va a
comenzar a poseer.
La reversion que propongo concilia tres objetos, mui atendibles;
preparar el local de la escuela futura; crear con el valor que la
industria i cultivo le dará un fuerte capital para el sosten de las
escuelas, i un medio auxiliar para que la propiedad adyacente tome
mayor valor i mejore la industria ganadera, disminuyendo las
probabilidades de pérdida, i los costos de manejo, aumentando los
productos.
 Organizacion.

Es de todos los movimientos sociales principiar por donde hubieran

debido acabar, o cultivar especiales ramos, abandonando al olvido
otros que le son esencialísimos. La educacion científica ha precedido
en todas partes a la educacion rudimental en las atenciones de los
gobiernos, poniéndose así un capitel sobre edificio sin base; las
instituciones de caridad para los enfermos, los locos, los huérfanos,
los pobres de solemnidad, han precedido a las escuelas para los que
se hallaban en estado peor si cabe de desamparo, enfermos, locos i
huérfanos, con salud, razon i padres, e inhabilitados para el trabajo i
la moralidad por su ignorancia i depravacion. Los primeros esfuerzos
se hicieron para educar las jeneraciones venideras, dejando la
presente abandonada a su propia suerte, dando a aquella instruccion
rudimental en las letras, sin acordarse que era tambien necesario
educar las fuerzas productoras del hombre, única garantia que
puede conservar la moralidad del espíritu, enseñando a vivir i
dotando de medios de subsistencia. El desórden de prelacion ha
llegado hasta apasionarse pueblos como la Inglaterra por la
emancipacion de los negros de lejanas colonias, sin echar una
mirada de compasion sobre los blancos, esclavos del crímen i de la
desnudez que los filonegros tenian a su vista.
Todo se ha hecho ya, todo se ha iniciado, pero no en un país solo, ni
en una época. Para aleccionarse completamente en los elementos
dispersos de esta ciencia, era necesario recorrer toda la tierra,
examinar las instituciones de diversos pueblos, penetrar en el
secreto de los principios que las rijen, i atisbar los nuevos desarrollos
que están en jérmen ya. Para desempeñar esta tarea, con respecto a
nuestros países, era necesario ademas que el que se encargase de
ella fuese maestro de escuela, a fin de comprender la eficacia de los
métodos de enseñanza, como medios mecánicos de producir ciertos
resultados, i el conjunto de disposiciones puramente pedagójicas.
Del hombre de Estado debia tener por lo ménos la intuicion de lo
que se oculta a los que desligan la instruccion primaria de las
grandes cuestiones sociales, i como lo acaba de establecer M.
Rendu, enviado por el gobierno frances a Inglaterra a examinar la
educacion en Lóndres, persuadirse "que las cuestiones de moralidad,
de trabajo, criminalidad, de ejercicio de los derechos políticos, todas
parten de la instruccion primaria i vuelven a ella;" que "toda miseria
física en los individuos, como toda decadencia política en los
pueblos, proviene de una enfermedad moral," hallándose siempre "el
oríjen de la miseria que amancilla el alma, matando el cuerpo, en un
vicio de educacion[15]." Era necesario para trabajar con provecho
estar imbuido en esos nobles principios, que sin participar del
espíritu de innovacion i reorganizacion brusca de la sociedad que
atormenta a nuestro siglo, sostienen la fé en medio de las
reacciones, i concilian las necesidades del órden aparente, que
reprime las manifestaciones del mal, con la urjencia de acudir a la
raiz, a perseguirlo en sus fuentes, la ignorancia, la destitucion, el
envilecimiento o la depresion moral del mayor número, incapaz de
comprender el juego de las instituciones que nos impone la marcha
del mundo i las conquistas que han hecho los pueblos. La economía
política no debiera serle desconocida, en cuanto estudia el oríjen de
la riqueza moderna de las naciones, la que proviene de la
combinacion de capitales, máquinas e intelijente labor, sin cuyos
elementos la agricultura misma deja de ser fuente de riqueza, desde
que sus productos han de presentarse en la feria del mundo a
rivalizar en precio barato i calidad superior con los de todos los
países de la tierra. Debiera ademas, para iniciar con suceso la
reforma de nuestros sistemas de educacion, ser publicista, autor,
periodista, a fin de hallarse en aptitud de obrar sobre la opinion
pública, por medio de esa iniciacion lenta pero constante, diaria,
seguida por años, que cambia insensiblemente las ideas, que
introduce otras nuevas, que hace nacer convicciones en la masa de
los hombres que influyen en los destinos de las naciones. Las
escuelas no se fundan con niños, sino con leyes, con rentas
especiales, con la cooperacion de los padres de familia, con
erogaciones espontáneas i con espíritu público que las de vida. Una
guerra puede sostenerse con soldados de línea, escuadras i
empréstitos, aun prescindiendo de la voluntad de los gobernados. La
instruccion comun parte del corazon de los vecinos, i sin sus
simpatias, sin su anhelo, será siempre planta raquítica, cultivada en
suelo ingrato, e incapaz de propagarse. "El espíritu público es la vida
de un pueblo," i donde no existe es preciso hacerlo nacer
especialmente para la enseñanza comun. Era preciso para importar
en nuestra América española la instruccion primaria, ser literato, lo
suficiente para conocer lo que en el idioma sirve a la fácil
propagacion de los elementos de enseñanza, i qué libros, tratados,
textos no posee aun nuestra lengua; para inventar métodos,
introducir tratados, i estudiando el conjunto de la bibliografía
española, encontrar en la falta de libros la causa i el efecto a la vez
de la inferioridad intelectual en que se arrastran, en Europa i
América, los pueblos del habla castellana, relativamente a los otros
que en otros tiempos les fueron inferiores en civilizacion i poder; i
despues de todo esto, era todavía necesario ser hombre práctico,
para aconsejar la fundacion de escuelas Normales i encargarse de
realizarlas; para reunir los elementos que deben constituir una lei de
enseñanza, i componer un silabario; para elevarse
momentáneamente a la contemplacion de la causa de la grandeza i
decadencia de los pueblos, i descender sin derogar a las humildes
ocupaciones del pedagogo, dando la medida de un banco, el
bosquejo de una escuela, o los libros de lectura adecuados para la
comprension infantil. Preciso era para todo esto, disipar el tiempo i
posponer consideraciones de fortuna i elevacion personal,
perseverando en una idea fija años i años, miéntras cambian a su
alrededor gobiernos, ministerios e instituciones, i la tierra cruje bajo
las plantas, sacudida por las revoluciones en que no se desdeña
tomar parte, a fin de destruir los obstáculos, de otro modo
insuperables, para todo progreso i mejora intelectual en nuestras
sociedades.
En cualquiera grado en que sea necesario poseer estas calidades,
necesito decir que, para proponer un proyecto de educacion comun
a que sirvan de introduccion estas esplicaciones, yo he ensayado
esos trabajos, pasado por esa larga preparacion, i puéstome en
aptitud de tener juicio acabado sobre la materia que trato. Si los
medios indicados no hubieran bastado a madurar el espíritu, mucho
habrian hecho las resistencias con que la organizacion de la
instruccion primaria ha tenido que luchar en Chile, los aplazamientos
reclamados por las otras necesidades del gobierno, la indolencia del
público, la antipatia de las aristocracias educadas, propietarias,
nobiliarias, o de senectud; la inconsistencia de la accion de los
sucesivos gobiernos, la fuerza de inercia de la rutina, i la mala
direccion de las ideas de la juventud. Gracias a estas causas
diversas, obrando en tan largo lapso de tiempo, el estudio ha debido
pasar de la teoría a la práctica, de las instituciones a los hombres, de
los fines a los medios, i de todo sacar resultados i útiles lecciones.
Con estos antecedentes, i, economizando una erudicion fuera del
caso aquí, espondré brevemente los diversos ramos que debe en
nuestro país abrazar un sistema de educacion comun para el
presente i para el porvenir, para los niños que formarán la jeneracion
venidera i para los adultos que hoi pueden recibir nociones útiles;
para los que individualmente se instruyen, i para el idioma mismo
como el vehículo de las ideas; para la tierra inculta que mantiene la
barbárie, i para el ganado que usurpa al hombre el suelo en que
está por la falta de cultura diseminado.
Tres elementos hago entrar en mi sistema, el maestro, el libro, i las
plantas. De todos tres es preciso proveerse, i para ello fundar
fábricas de donde salgan permanentemente, al ménos costo posible,
aquellos tres artículos indispensables. La teoría i la práctica han
demostrado ya a todos los pueblos que el maestro no se encuentra
formado, i es preciso crearlo tomando un niño, infundiéndole
espíritu, enseñándole una profesion mecánica, cual el arte de
enseñar, i dotándolo de un fondo de instruccion que lo ilumine a él
mismo para guiar a los que le siguen.
Sin embargo, era preciso proveer no solo de capacidad a un
maestro, sino asegurarse ese producto, de manera que dedique su
vida entera si es posible a hacer redituar, enseñando, el capital que
se invirtió en prepararlo.
En Europa, donde los hombres de mediana instruccion abundan i las
ocupaciones escasean, el maestro permanece largos años, siempre
en la práctica de su profesion. No así en los Estados-Unidos, donde
el desarrollo de la riqueza convida a todos a procurársela sin límites,
i la enerjía característica del pueblo, le hace desdeñar un salario
como la permanente aspiracion de su ser. En Chile sucede peor, pues
siendo pocos los hombres instruidos, el maestro convenientemente
educado en la Escuela Normal, terminados los siete años que tiene
por obligacion enseñar, se lanza en la carrera de los empleos, del
comercio, o simplemente de escribiente, lo que con mas salario i
mas goces, le economiza las molestias i la monotonia de la escuela.
En el nuevo sistema combinado este inconveniente desaparece. El
maestro salido de la Escuela Normal pasará a las propiedades de las
Escuelas, adonde llevará consigo su peculio en plantas para
propagar, donde hallará casa i ocupaciones varias, prospecto de
fortuna e interes de continuar la residencia que le da,
desempeñando deberes públicos, tiempo i medios de cuidar de sus
intereses.
El juicio esperimentado del Visitador Moseley en Inglaterra es digno
de ser citado.

"La influencia de una escuela normal, dice, no ha de medirse

esclusiva ni principalmente por el poder con que comunica la
instruccion, que no es la masa de conocimientos adquiridos ni el
ejercicio de la intelijencia lo que le da su valor mas saneado,
sino la disciplina moral unida en sus alumnos al cumplimiento
laborioso, fiel i puntual de su deber.
"En la visita de las escuelas primarias no fué siempre lo que
mas me llamó la atencion la superioridad, como profesores, de
los antiguos alumnos de las escuelas normales, training schools.
 Distínguense mas bien, los que han recibido una educacion
normal, por una mayor consagracion a sus deberes, por la mas
elevada idea que de sus funciones tienen. El pensamiento del
aislamiento, oríjen fatal del desaliento en la obra impuesta al
maestro, es por otra parte, apartado hasta cierto punto por la
influencia de la Escuela Normal, la cual crea entre los maestros
un vínculo de fraternidad que hace para ellos, de la obra de la
educacion elemental, una causa i un trabajo comun.
"En mis relaciones con los maestros me ha llamado muchas
veces la atencion la falta de fé en el poder de la educacion. I sin
embargo, el niño está seis horas al dia con los ojos fijos en el
maestro, en la época de la vida en que su espíritu esta mas
abierto a la influencia del ejemplo, i en que mas fácilmente se
contraen hábitos de bien i de mal por las ideas i por las
acciones. Ya es mucho para el maestro tener que dar a la
intelijencia del alumno su alimento cuotidiano, absorver la
voluntad del niño en la suya, i, si es hábil, constituir la opinion
pública de la escuela.
"Oigo hablar mucho de la imposibilidad en que se halla la
escuela de producir algun bien, a causa de la mala influencia del
hogar doméstico; pero la verdad es que el maestro posee un
inmenso poder sobre la educacion del niño. Mi esperiencia de
Inspector me ha permitido comprobar este hecho de una
manera positiva. Yendo de escuela en escuela he podido
distinguir en cada una de ellas un carácter especial, i era el del
maestro. La personalidad del maestro pasa a la escuela; i en los
niños me parece ver, como otros tantos pedazos de un espejo
roto. No necesito decir qué importancia dan estas observaciones
al carácter del maestro, a su educacion relijiosa i moral, i por
consiguiente a las Escuelas Normales[16]."

Lo que los sabios inspectores de Inglaterra han podido notar allá, lo

ha esperimentado Chile desde un estremo a otro. Los primeros
alumnos de la Escuela Normal hicieron en todas las provincias una
saludable revolucion en las costumbres i en el espíritu público,
habiendo, como sucedió en Chiloé, comunicado a todos su interes
por la difusion de los conocimientos. Los informes de los Visitadores,
incluidos en el Monitor de las Escuelas, dan una idea de cómo puede
el espíritu impreso por la enseñanza de la Escuela Normal
comunicarse a los hombres que se consagran a este ramo de la
ventura de los pueblos. Si nada mas hubiese producido la Escuela
Normal que Visitadores como Bustos, Rojas, Suarez, Roldan,
Ramirez, etc., mucho se habria obtenido. Acaba de decretarse un
Ejercicio de Maestros, para convocar en un congreso de estudio a
estos representantes de la cultura intelectual de las provincias en
que residen, i es seguro que los efectos morales de esta medida
serán bien pronto palpables.
Pero la Escuela Normal, que es la pepinera de los maestros, tal como
la propongo en este sistema, es al mismo tiempo Quinta-modelo de
Agricultura, donde se aprende i se practica, donde se estudia i se
adquiere. País alguno del mundo necesita mas un jardin de
aclimatacion de plantas que Buenos-Aires. El hombre necesita
completar con sus manos la obra que la naturaleza entregó
inacabada, i los climas templados de ámbas zonas, el estranjero i el
propio territorio arjentino, le brindan con las semillas i plantas que
han de propagarse de preferencia. Mas que gastos de dinero se
necesita solo un pedazo de tierra, i una direccion para procurarse lo
que se necesita; lo demas es obra del tiempo i de la naturaleza, que
es pródiga en la reproduccion de sus dones. El cultivo, la enseñanza
práctica, i mas tarde la Escuela Normal necesitan brazos, i estos
brazos a precios ínfimos, limitados al alimento, lo suministrarian la
Cuna, convertida en Hospicio de Huérfanos afecto al local de la
Escuela Normal i Quinta de aclimatacion, i a quienes la caridad
pública, mal ordenada hasta hoi, deja en la destitucion o abandona a
merced de la suerte, despues de haberlos salvado de la muerte
temprana del expósito, sin casas de Reforma para niños
delincuentes, mal entretenidos o abandonados. Estos
establecimientos aislados, como existen hoi en todas partes, que
cuestan mucho i nada producen, se convierten en los mas poderosos
ausiliares de la grande obra de mi sistema de educacion. Las Cunas
toman el niño recien nacido hasta concluida la lactancia. La Sala de
Asilo empieza a educarlo desde la edad de dos años hasta la de seis,
tiempo en que, en un sistema combinado de establecimientos que se
den la mano unos a otros, puede emplear con producto sus débiles
fuerzas, barriendo, desgranando semillas, deshervando, tejiendo
estera, i otras mil ocupaciones infantiles. De siete años adelante
sirve de alumno en las escuelas de aplicacion en que se ejercitan en
la práctica los maestros educandos, i en la Quinta Normal de peon,
plantando legumbres, hortalizas, plantas, etc., i todo lo que
desempeña tambien un niño como un adulto, por requerirse
inteligencia i no fuerza.
De 12 años hasta 16 empiezan a ser peones de trabajo para el
manejo del arado, i alumnos de estudios mayores de botánica,
ganaderia, etc. A veinte son hombres formados, intelijentes, aptos
para entrar en la vida, i a veces poseen un peculio adquirido durante
su aprendizaje en lugar de haber costado nada al erario. De esos
niños que nacieron huérfanos, o mas tarde eran vagos, el país hace
hombres instrumentos de moralidad, trabajo intelijente, educacion,
desarrollo de riqueza i de civilizacion; i halla en ellos un empleado a
quien mas tarde dará casa, familia, ocupacion, i empleos públicos,
como maestro de escuela, administrador de la vacuna, bibliotecario,
maestre de posta, etc.
Todas las instituciones que entran en este plan de educacion están
de largos años planteadas, esperimentadas i practicadas en varios
países del mundo. Las constituciones norte-americanas hacen
obligatoria la creacion de establecimientos para la educacion de
niños mal entretenidos o delincuentes. Quintas Normales i jardines
de plantas los hai en todas partes. Las Escuelas Normales han
pasado ya requisito indispensable para la formacion de las escuelas;
la caridad cristiana, sobre todo en los Estados-Unidos, ha hecho de
las antiguas casas de espósitos, establecimientos de educacion
moral e industrial, continua hasta la edad viril; las Bibliotecas
populares son hoi el instrumento de la educacion comun, i la
continuacion i complemento de la escuela; pero, creadas cada una
de estas instituciones en diversos países, en épocas diversas, i con
un objeto esclusivo, cada una en su especialidad, no han formado
hasta hoi un todo armonioso, haciendo que las unas sean
preparacion de las otras; que ésta remedie lo incompleto de aquella;
i que todas marchen dándose la mano al mismo fin, que es la
propagacion de los medios de mejorar la condicion del país i de los
hombres que lo habitan. Chile ha gastado cien mil pesos, si no mas
en una Quinta Normal que aun no ha dado agrónomos; otro tanto
en Escuela Normal, cuyos alumnos maestros apénas cumplen siete
años de servicio obligatorio abandonan carrera que han tomado solo
para abrirse paso en la vida. Hoi se funda un Hospicio de Huérfanos
que ya cuesta 70,000 pesos, i cuando se pregunta ¿qué se hará con
esos jóvenes cuando hayan llegado a la edad viril, se responde que
se fundarán colonias, por no saber qué destino darles. Mi plan es
mas sencillo, demanda gastos exiguos, i asegura brazos para la
continuacion indefinida de la profesion de maestro. Yo tomo un
espacio de terreno, donde por lo pronto acampan cuatrocientos
jóvenes, como acampa un batallon de infantería en Lujan. Estos
jóvenes labran la tierra i se educan para enseñar a labrar la tierra i a
leer. La tierra que labran les da de que vivir, dejando al Estado solo
los gastos de creacion. En lugar de peones para las labores que no
requieren fuerza, tomo niños a quienes sus padres no pueden dar ni
moral, ni oficio ni instruccion, i ellos ayudando al trabajo, se
moralizan por la educacion relijiosa i por la disciplina i la instruccion.
Los sacerdotes que presiden hoi a la educacion de Huérfanos toman
al niño desde la cuna, lo educan en las Salas de Asilo, i a los siete
años es ya un hombrecito moral, relijioso, instruido i trabajador. La
Quinta Normal continúa la obra, i ésta i la Escuela Normal le dan
aplicacion i objeto; i de materiales tan humildes al principio, el
sistema ha hecho maestros de escuela, agrónomos, impresores,
litógrafos, grabadores intelijentes, relijiosos i morales, para ir cada
uno al puesto que le aguarda, es decir una quinta donde hai tierra
que labrar, servicios diversos que prestar a sus semejantes, una
escuela que presidir, los goces de la familia i de la propiedad, i un
porvenir asegurado, miéntras la honradez, la laboriosidad i el
desempeño de sus deberes le hagan acreedor a permanecer en
situacion que es de suyo buena. En veinte años la fisonomía física i
moral del país ha cambiado, quedando echadas las bases de un
porvenir de civilizacion, moralidad i riqueza.
Incluimos en la mejora agrícola los medios de mejorar las razas de
animales, aun en el estado actual de la industria ganadera. Como
una yegua de valor de un peso necesita de la misma estension de
tierra para mantenerse que una de raza i que da potros de valor de
cien pesos, el criador con un animal de raza, emplearia cien veces
ménos tierra con igual resultado que la que hoi embaraza, dando de
comer a seres tan degradados. Sucede otro tanto en las razas de
vacas, cerdos, ovejas, de lo que en Buenos-Aires tienen suficiente
esperiencia, pero de lo que no se dan cuenta los que presiden a los
destinos del país. A principios de este siglo se introdujeron en
Francia dos caballos padres, de raza inglesa pura. El gobierno
mandó poco despues formar haras, o establecimientos para la cruza
i mejora de las razas en los varios departamentos de Francia,
presididos por los jefes políticos, tanta importancia se daba a este
asunto. Los resultados han correspondido a esta solicitud,
poseyendo hoi la Francia caballos que en nada ceden a los de
Inglaterra. La estadística en 1851 ha podido contar mil setecientos
noventa, entre yeguas i caballos de raza inglesa, i mil doscientos
cincuenta i cinco de raza árabe. Las sociedades de aclimatacion han
continuado la obra iniciada por el estado, aplicándose a dotar a la
Francia de todos los animales útiles al hombre de que ántes carecia,
i a mejorar las razas existentes. Una vaca ordinaria produce seis
litros de leche, miéntras que ciertas razas especiales dan hasta
veinte i seis litros diarios, es decir, cerca de una arroba[17]. Iguales
ventajas se obtienen en la calidad i cantidad de las lanas de los
carneros. Pero para mejorar así la calidad de las razas es preciso
cuidados intelijentes, locales adecuados; son libros los que contienen
los preceptos de esta ciencia, i no todos los particulares a un tiempo
han de emprender los primeros ensayos. Los Estados-Unidos sobre
todo se distinguen hoi por la intelijencia de los procederes, i la
uniformidad de la impulsion, debido esto a una poblacion educada
en masa ya, i preparada para recibir instrucciones i hacer aplicacion
inmediata a los negocios de interes. Para esta esencial reforma
servirian especialmente los locales indicados, limitándose al principio
a la distribucion de merinos tipos, de cerdos, para proceder con el
tiempo a la refina de vacas i caballos, sirviendo estas ocupaciones
ausiliares de dar medios de industria i sosten a los futuros maestros.
Decimos lo mismo con respecto a la rica produccion de las lanas,
que hoi forma uno de los artículos de esportacion de Buenos-Aires.
En 1840, cinco millones ciento diez i ocho mil ovejas produjeron, en
el Estado de Nueva-York, nueve millones i poco mas de ochocientas
mil libras de lana, miéntras que en 1850 tres millones cuatrocientas
cincuenta i tres mil ovejas produjeron diez millones setenta mil libras
de mejor lana. ¿Cómo se obró este prodijio? Por los cuidados
intelijentes de los criadores, mejorando las razas, e instruyéndose en
los mejores métodos conocidos, por medio de la difusion de
conocimientos. En el estado semi-salvaje de la cria de ovejas en
Buenos-Aires, tomada ésta en jeneral, se necesitarán siete millones
de ovejas para producir diez millones de lana de calidad mediocre;
ocupando doble o triple terreno para el sustento de los animales que
la producen.
Tenemos pues lo que la tierra i la enseñanza requieren. Quedan las
ideas. Las ideas son libros; los libros son productos de una o mas
industrias. Afecta a la educacion pública habrá una imprenta a la que
se agregarán mas tarde fábricas de papel, encuadernacion,
litografía, grabado en madera, etc., etc. Para educar un pueblo, el
primer elemento es el libro, i el libro barato i en numerosas
ediciones. Era este el defecto de la educacion en sus primeros
ensayos. Ocupándose del arte de leer no se acordaba que era
preciso proveer tambien lo que habia de leerse: celosa de la mejora
de las jeneraciones nacientes que no nos han de robar ni degollar a
nosotros los que estamos vivos, prescindia de la presente jeneracion
tan educable o mas que la venidera. De aquí ha nacido la institucion
de las Bibliotecas populares, que son hoi la palanca del desarrollo i
civilizacion de los Estados-Unidos.
Pero nosotros tenemos mas que hacer todavía, i es educar el idioma
mismo traduciendo el libro, importando la industria que lo
reproduce.
Los productos de la imprenta afecta a la educacion pública han de
ser de tres clases. Primera: los testos de la enseñanza en español
para todos los ramos de instruccion primaria i superior, haciendo
ediciones en gran número, lo que da a cada ejemplar un valor
mínimo. Segunda; la traduccion, compilacion i composicion de libros
de instruccion útil para todas las clases de la sociedad, i para la
paulatina formacion de las Bibliotecas populares, que principiando
por un libro, deben de año en año enriquecerse con nuevos
continjentes, i no cesar nunca de subministrar pasto fresco a la
intelijencia, a medida que los conocimientos se desenvuelven, i las
ideas van marchando. El error que ha tenido la civilizacion detenida
entre nosotros, estaba en creer que, salvo rarísimas excepciones, hai
libros que pueden leerse en todos tiempos, i que no envejecen i
mueren con la época, los hombres, e ideas de que fueron la
espresion.
Tercera, i la mas seria; pasar al castellano las obras maestras de los
otros idiomas, i de cuya doctrina están privados los que solo hablan
el nuestro; reproducir cada diez años el diccionario de la lengua
aumentado, los códigos reformados; i cada veinte por lo ménos las
Enciclopedias metódicas, de Inglaterra sobre todo, que son las que
contienen datos mas prácticos sobre las artes modernas, las
máquinas, las ciencias, etc. El pueblo español, en materia de libros,
va todavía por los rudimentales i novelas que entretienen la
imajinacion. El que quiera saber qué libros se necesitan en español,
eche la vista a su propia biblioteca i verá la masa de conocimientos
de que la jeneralidad está privada. Los catálogos de libros de
Bossange en Francia, de Mellado en España, son verdaderos
necrópolis de libros difuntos, hediondos a fuerza de ser inútiles.
Por qué el Cosmos de Humboldt, La Mecánica celeste de La Place,
las obras de Buffon, los trabajos de Cuvier, de Lacépède i Beaumont
no están en castellano? Por qué no hai un Maltebrun en jeografía, un
Mac'Culock en datos comerciales, ni un Million de faits, ni una
enciclopedia que consultar? En materia de ciencia, como en derecho,
habremos de estar sujetos a idiomas muertos o estraños? El
Congreso de los Estados-Unidos hace publicar anualmente los
Informes que sobre mecánica i agricultura pasa el Patent Office al
Senado todos los años a sesenta mil ejemplares, el compendio del
censo a cien mil, i las obras de jeolojia i delineacion de costas, viajes
i descubrimientos a millares de ejemplares, para instruccion del
pueblo i desarrollo de la riqueza. Nosotros necesitamos mas todavía,
i ántes de estampar en el papel lo que pensamos, debemos
principiar por hacer conocer lo que otros pensaron i nosotros
ignoramos.
Toda la América del Sur necesita libros, i aun la España, i con
perseverancia i dilijencia se hallaría colocacion al exceso de
produccion, por medio de intercambios con los otros gobiernos, i con
las imprentas de España i de otros estados. La Alemania, que como
se sabe, se compone de estados diversos, a quienes no liga entre sí
sino el idioma, ha llevado al último grado de perfeccion este sistema
de permutas i jeneralizacion de los libros. Todas las imprentas i
librerías de la Alemania forman entre sí una asociacion para el
cambio de libros. Publicado uno o en via de publicarse, en Prusia, el
librero pasa circulares anunciando a sus cofrades la obra, para que
cada uno pida los ejemplares que quiera. Esto lo hacen
recíprocamente todos, i en la feria de Leipsic se reunen los libreros o
sus dependientes, ajustan la cuenta de cargo i data que se llevan
entre sí, i el saldo en pro o en contra queda para abrir la cuenta del
año siguiente, sin que jamas se cruce un centavo de dinero en estas
transacciones.
Antes que estas ideas sean aceptadas, por gobiernos que en materia
de civilizacion responden con el evanjelio "mirad las aves del cielo
que no siembran, ni ciegan ni allegan en trojes, o cómo crecen los
lirios del campo que no trabajan ni hilan," esa civilizacion por
perfeccionamientos recientes habrá puesto en manos de los pueblos
ménos avanzados, como la imprenta ántes, el papel a precios
ínfimos, i una arte tipográfica para la reproduccion de las imájenes.
La basofia o zupia de la caña de azúcar acaba de ser aplicada con
éxito a la fábrica de papel, i la reproduccion instantánea de las
figuras a precios ínfimos, por artes derivadas de la fotografia
eléctrica, está ya adquirida a los procedimientos industriales. Hai
estados americanos que no han ensayado aun el aprovechamiento
de los trapos para papel, i que se cuentan sin embargo en el número
de los pueblos civilizados; i gobiernos que montan fábricas de armas
que no cuidan de proveer de esta arma que llena una necesidad del
espíritu, la difusion de las ideas.
Otro motivo tiene Buenos-Aires para vaciar en molde tan vasto las
instituciones que han de cimentar su grandeza futura. Por su
posicion, por su mercado, será siempre el representante i el centro
comun de todos los pueblos de la lengua española de aquel lado de
los Andes. La imprenta no se desarrolla en pueblos pequeños o poco
adelantados. El Paraguai, Montevideo i las provincias interiores se
proveerán de libros de los grandes centros donde pueden construirse
bellos i baratos, con el auxilio de poderosa maquinaria. En Buenos-
Aires toman tierra los inmigrantes de todas las lenguas, i ya desde
hoi predominan en su poblacion vascos, italianos, franceses e
ingleses. Un idioma no vive porque un pueblo inculto lo habla, que
entónces vivieran aun el latin, el fenicio i el sanscrito. Vive por las
ideas de que es vehículo, por la ciencia que trasmite de jeneracion
en jeneracion, por los monumentos que en leyes, artes,
descubrimientos ha legado a la posteridad. Cuando los hijos de esos
franceses, vascos e italianos pidan al idioma de la tierra el medio de
desenvolver las tradiciones de civilizacion que sus padres dejaron, i
no los encuentren, caerán en la barbárie que su nueva patria les
impone, i adoptando nuestros usos i hábitos, serán gauchos con
pelo rubio i ojos celestes, como ya se ha visto con los hijos de los
alemanes e irlandeses que poblaron a Quilmes i la Guardia del
Monte.
No se pierda de vista otro hecho mui importante. Treinta años de
inmigracion aunque limitada, han dejado columbrar qué pueblos son
los que contribuyen a la poblacion de nuestro territorio con mayor
número de habitantes. Son los del medio dia de Europa, son las
clases trabajadoras, que de ordinario traen brazos robustos, hábitos
de economía i sobriedad, pero limitada instruccion. No sucede así en
el Norte de la América, a donde acuden los habitantes del Norte de
Europa, llevando de la Alemania sobre todo i de Inglaterra,
tradiciones de industria, instruccion i ciencia, lo que no estorba que
el estado de Nueva-York, punto de desembarco de la inmigracion,
mantenga escuelas nocturnas para enseñar el ingles i dar educacion
a los que no la traen de entre los estranjeros que llegan a sus
playas. Tienen ademas los Estados-Unidos por herencia un idioma, el
primero en las ciencias de educacion i el rival del frances en filosofía,
literatura i actividad intelectual. Tienen ademas la enerjía de su
propia raza, la cultura de sus habitantes, lo arraigado de sus
instituciones propias, la facilidad de difundirlas, lo que hace que los
nuevos arribantes se pleguen i amolden luego al espíritu, hábitos e
ideas del pueblo que los acoje i confunde en su propio ser. Todos los
idiomas, el aleman mismo, ceden a la atraccion i predominio que el
ingles ejerce sobre todo lo que toca. ¿Tenemos nosotros en nuestro
idioma, en nuestras instituciones esta fuerza central, esta atraccion
dominante? No: Nosotros necesitamos fundar la nacionalidad futura
de esos elementos heterojéneos, dando a la lengua todos los medios
que le faltan de preponderar, de perpetuarse, de llenar todas las
necesidades intelijentes de la sociedad. Los Estados Unidos, pues
que hemos de tomar los ejemplos en naciones de oríjen colonial,
eran cerca de cuatro millones de habitantes al declararse
independientes, con un espíritu nacional profundamente arraigado,
instituciones fundadas en una práctica secular, i hábitos, civilizacion
e ideas que tienen hasta hoi en los Estados de la Nueva-Inglaterra
un foco que conservándolas vivas, las difunden, por todo el resto de
la Union. La inmigracion durante los primeros treinta años no pasó
de 234,000 individuos, lo que da siete mil ochocientos inmigrantes
por año, número insignificante, comparado con la masa de la fuerte i
vigorosa poblacion nacional que ya ascendia a doce millones de
individuos.
No sucede lo mismo entre nosotros. Las investigaciones laboriosas
del señor Maezo lo han llevado a comprobar que de muchos años
atras llegan a Buenos-Aires seis mil inmigrantes por año, i las cifras
de estranjeros residentes que presenta lo comprueban. Segun él hai
en Buenos-Aires hoi veinte i dos mil ingleses, veinte i seis mil
franceses, veinte mil españoles, quince mil italianos i el resto hasta
cien mil de oríjen diverso. Esta masa de arribantes que debe
aumentar cada dia mas, sufocará bien luego la poblacion indíjena,
sin imprimirle carácter ninguno, porque no puede tenerlo esta
mezcla etereojénea i aun sin impregnarse del nuestro, no solo por la
poca influencia que ejerceria nuestro pequeño número, sino porque
ningun rasgo apetecible tenemos de carácter nacional, ni en moral,
ni en instituciones, ni en prácticas gubernativas, ni en tradiciones, ni
en costumbres, si no son las de la barbárie. Los inmigrantes del
medio dia de Europa nos traen poco en costumbres i aun en
civilizacion que adelante la nuestra, i solo por una fuerte educacion
pública comun podrá impedirse que los hijos de vascos, italianos i
españoles desciendan de los hábitos industriales de sus padres a los
de incuria i barbárie de nuestras masas, ya que en falta de
instruccion corren parejas. ¿Qué estado, qué nacion va a formarse
de elementos tan diversos, sin una base a que se adhieran, sin un
carácter nacional predominante que les imprima a todos su sello, sin
tradiciones comunes, i aun con idiomas diversos que en el país
mismo se conservan i perpetuan? Todavía en California que ha
pasado en seis años por ese revolverse de elementos reunidos por el
acaso de todas las partes del globo, si bien la falta de la familia
hacia mas estraña la confusion, hubo siempre un jérmen del espíritu
nacional, i predominó luego el jenio norte-americano, saliendo de
aquel caos el Estado de California hecho en idioma, instituciones,
usos, costumbres i leyes a imájen i semejanza de la Union, acaso
mas civilizado, acaso ménos moralizado. Que se juzgue por estos
hechos de la magnitud de la tarea que la educacion debe
emprender. Si Dios nos ha dado una tierra a medio hacer, la
inmigracion nos dará una sociedad por formar que ha de reposar
solo en la fuerza de la lei para vivir i desenvolverse, sin el auxilio de
hábitos i tradiciones que suplen su fuerza, o contienen las pasiones i
las ideas en ciertos límites.
Solo haciendo marchar de frente i en combinacion estos diversos
elementos, es que la educacion puede difundirse entre nosotros,
producir resultados inmediatos, interesar en su propagacion a las
muchedumbres ignorantes, mejorándolas, i a las muchedumbres
propietarias, que verán aumentada, asegurada i beneficiada esa
propiedad, a la que sacrifican hasta su propia tranquilidad, dejando
a sus hijos, con esa propiedad misma, entregados a los azares de un
porvenir que de manera alguna se les presenta como seguro, desde
que en el fondo de los hechos actuales se divisan ya las causas de
perturbacion que nosotros mismos les legamos.
Con las esplicaciones que preceden, someto al exámen i aceptacion
del pueblo de Buenos-Aires, la base de una lei para proveer a la
educacion comun de sus hijos, que lléne todas las condiciones
requisitas para su objeto. Sin una base cierta, se pueden mejorar las
escuelas existentes, crear algunas nuevas, pero no fundar la
institucion salvadora que concluye por suprimir las plebes
ignorantes, improductoras e inmorales, cuyo número pudiera
borrarse del de los seres humanos, etc. Es inútil presentar proyectos
de lei, sin estar seguros de que serán aceptados. El Estado de
Nueva-York en 1851, al cambiar la base de la renta de las escuelas,
no obstante estar sancionada la nueva lei por la Lejislatura, la
sometió a votacion popular en las elecciones. Una gran mayoría la
aceptó; pero al ponerla en práctica fué rechazada. Revisada de
nuevo, fué segunda vez sometida a la sancion de la voluntad de los
ciudadanos, i entónces fué aceptada por una debil mayoría.
Sometido en 1849 a la Cámara de Diputados en Chile un proyecto de
educacion primaria, la Cámara compuesta de lo mas distinguido de
la juventud de Chile rechazó la base de la renta, que debia sostener
las escuelas, que estribaba en que cada uno contribuyese
directamente i en proporcion de lo que posee, a la educacion de
todos. Sometido de nuevo el mismo proyecto a la Cámara de
Senadores en 1852, compuesta de los propietarios mas acaudalados,
fué rechazada igualmente en el mismo acápite; i aun no hai lei de
instruccion pública en Chile. El hombre de estado mas influente de
Chile, el Presidente de la República, no encontró sostenedores para
hacer pasar una lei sobre instruccion pública en el seno de las
Cámaras compuestas por los hombres, que por discusiones políticas
habian votado millones i hecho derramar la sangre de los suyos i de
los contrarios en las reyertas políticas.
Sobre este punto ya no hai cuestion en Buenos-Aires. Las parroquias
se han reunido espontáneamente para votar por suscripcion los
fondos necesarios para el sosten de sus escuelas. San-Nicolas ha
imitado su ejemplo, i algunos departamentos de campaña mandado
construir cómodos edificios. La historia política de la República
Arjentina, i el fresco recuerdo de lo pasado, han aleccionado a la
opinion sobre la necesidad de educar a las muchedumbres
improductoras, mejor que lo que se ha podido en Chile, en quince
años de esposicion de principios. Chile gobernado por la clase
propietaria i educada en colejios no ha tenido ocasion de ver la
barbárie en el poder mostrándose a sus anchas.
Que la opinion pública en Buenos-Aires se uniforme pues a este
respecto, ántes de esponerse a decisiones lejislativas que pueden
ser inspiradas por preocupaciones de clase i de educacion
universitaria, los verdaderos obstáculos en todas partes para la
jeneralizacion de los conocimientos, única base del órden, de la
riqueza i de la civilizacion.
La Comision de Hacendados puede espresar oficialmente su voto.
La Comision para dictaminar sobre la lei de tierras puede aconsejar
se retengan las cincuenta cuadras pedidas, ántes de dar títulos de
propiedad a los poseedores que carecen de ellos; i como en las
tierras enfiteúticas los poseedores no tienen el dominio de la tierra,
para hacer pasar la lei no habria que discutir sino con los setecientos
poseedores con títulos.
La prensa debe consagrarse a ilustrar estas cuestiones, i formar la
opinion, en vista de las ventajas i desventajas del sistema, i los
políticos adoptar por blanco de sus esfuerzos la adopcion o el
rechazo de ideas que ofrecen asegurar el bien público, i el adelanto
del país. Las elecciones deben tener en vista llevar a la Asamblea,
sostenedores en uno de ámbos sentidos, para convertir en lei la
opinion que predomine. Este es el medio de dar vida i animacion a
las cuestiones electorales, i creando la opinion pública sobre puntos
determinados, darla representantes directos en el gobierno.
Admitida la base, el proyecto de lei es obra de ciencia profesional,
de estudio de las lejislaciones existentes, de esperiencia de sus
resultados, de aplicacion a nuestras necesidades. Para la discusion
de sus artículos, las Cámaras lejislativas son competentes. Para la
adopcion de la base propuesta, no lo serán miéntras no sean
espresion de la voluntad de los ciudadanos, a este respecto
manifestada. El público poco podrá decir con acierto sobre el efecto
práctico de tal o cual artículo de una lei; pero en cuanto a las tierras
pedidas, los que las poseen u ocupan pueden formar opinion sobre
la conveniencia pública o privada de cederlas o guardarlas.
Concluiremos este prospecto, por el anuncio de declaraciones
jenerales que la lei debe contener. No son estas principios teóricos,
ni derechos abstractos. Son simplemente los fundamentos de las
leyes modernas sobre educacion comun, deducidos del tenor literal
de sus disposiciones. Son cosas practicadas, establecidas, i pasadas
en autoridad de cosa juzgada, por mas que entre nosotros parezcan
novedades. Pueden adoptarse en toda su estension, modificarse o
limitarse en su jeneralidad, segun se juzguen aplicables al país, a la
índole de sus instituciones, costumbres, etc. Yo solo he querido al
reasumirlas en formas dogmáticas mostrar el último grado de
perfeccion que han alcanzado las leyes sobre educacion comun. La
ventaja de los pueblos nuevos de nuestra época está en encontrar
ya resueltas todas las dificultades que embarazaron por largos siglos
la marcha de los que les han precedido; i en lugar de empezar por
hacer esperimentos incompletos, o entrar en caminos que no tienen
salida, porque por ahí principiaron otros, la ciencia del estadista de
nuestra época i de nuestros países debe consistir en examinar los
progresos parcialmente hechos en diversos países i tiempos, i
deducir de ellos, razonado i sistemático, el código de las verdades
conquistadas por la humanidad i probadas i sancionadas por la
práctica. En este principio se funda la codificacion de las leyes, la
enciclopedia de las ciencias i artes, i todos los trabajos en que los
pueblos modernos reasumen las nociones exactas, apartando los
errores con que cada una vino necesariamente acompañada.
Que los propietarios, los estadistas, los letrados, la juventud, los
inmigrantes, las madres que están criando hijos para la cuchilla de
las futuras tiranías, decidan si han de vivir siempre sobre el quién
vive de un Rosas o sus imitadores, i si han de legar a sus
descendientes, por disposicion testamentaria, las alarmas i las
zozobras en que han nacido i deben morir. Si no, manos a la obra,
todos de consuno, i en diez años habremos fundado el órden de
cosas, de donde han de brotar la riqueza i la tranquilidad, la cultura i
la moralidad, la agricultura i mas ganado.
 PRINCIPIOS JENERALES
SOBRE EDUCACION COMUN
Apoyados en los recientes progresos de las Legislaciones de
varios Estados a este respecto.

Habiendo consignado en Educacion Popular, obra escrita en

1848, i posteriormente en el Monitor de las Escuelas
primarias de Chile, los principios que rijen la lejislacion de
escuelas, me limito en este trabajo, a mostrar los progresos
que ha hecho, desde entónces a acá, la lejislacion de algunos
Estados modernos, sobre todo en los Estados-Unidos.
El gobierno instituido para proveer a las necesidades jenerales de la
comunidad cuida de que la civilizacion[18] se propague por todo el
cuerpo social, i de jeneracion en jeneracion por medio de
instituciones que la difundan sobre todos los individuos de la
sociedad presente, para fundar la conservacion de la tranquilidad
pública, la seguridad de la propiedad i de la vida, i el desarrollo de la
riqueza en la estincion de la ignorancia, inmoralidad, e ineptitud de
los individuos para satisfacer honradamente sus necesidades. Este
es el oríjen de la intervencion del Estado en la educacion comun.
"Siendo esencial para la conservacion de un gobierno libre
que el saber i los conocimientos estén jeneralmente
difundidos en una sociedad, i conduciendo altamente a este
fin poner al alcance de todos los habitantes del Estado las
oportunidades i ventajas de la educacion, será del deber de la
Asamblea Jeneral dictar leyes para el aprovechamiento de las
tierras públicas concedidas a este Estado por los Estados-
Unidos, o las que hubiere de conceder en adelante para uso
 de las escuelas, i aplicar los productos de ellas, o los que
procedan de otras fuentes a los objetos a que fueron o
pueden ser destinados. La Asamblea Jeneral dictará de
tiempo en tiempo leyes, con el objeto de fomentar la mejora
intelectual, científica i agrícola, concediendo recompensas e
inmunidades por la mejora de las artes, ciencias, comercio,
manufacturas e historia natural; i fomentar i desenvolver los
principios de humanidad, industria i moralidad." (Constitucion
de Arkansas, art. IX, sec. I, 1836.)
El desarrollo i perfeccionamiento de los procederes agrícolas, como
que depende la agricultura de la aplicacion de los resultados de las
ciencias i de las artes, i es la base de la riqueza pública, debe entrar
en el número de las funciones del gobierno, fundando
establecimientos de aclimacion de plantas, de ensayo de procederes
agrícolas, i de difusion de las ciencias naturales que hoi dirijen la
fuerzas productivas de la naturaleza.
"Que Massachusetts cree justo i conveniente que el Congreso
destine una porcion de tierras públicas para establecer i dotar
un Colejio Normal de Agricultura que sea para la ciencia rural,
lo que West-Point es para la militar, con el objeto de educar
maestros i profesores para el servicio de todos los Estados de
la República."-Que se suplique a S. E. el Gobernador; que
haga llegar a manos de los Senadores del Estado una copia
de esta resolucion, así como a los Representantes de
Massachusetts en el Congreso, para que la presenten a aquel
cuerpo. (Resolucion de la lejislatura de Massachusetts, del 20
de abril de 1852).
—"El pueblo del Estado de Nueva-York, representado en
Senado i Asamblea ordena lo que sigue: (Los nombrados)
quedan por ésta constituidos en un cuerpo político
incorporado, bajo el nombre, título i descripcion de Colejio
agrícola del Estado de Nueva-York......" (Lei de la Lejislatura
de 15 de abril de 1853).
—Ordenanzas, instrucciones.—"El principal objeto de dicha
corporacion es proveer de un sistema de instruccion esencial i
prácticablemente útil a los intereses agrícolas del Estado,
combinar la teoría con la práctica, suministrar una sana
disciplina al espíritu, acumulacion de conocimientos i hábitos
de trabajo e industria.
La quinta afecta al Colejio Agrícola del Estado de Nueva-York,
conteniendo nada ménos de trescientos acres de terreno
variado, será conducida con ánimo de producir los resultados
convenientes a una industria combinada de cultivo, tan
variado como lo requieran los intereses agrícolas. "Siguen los
diversos ramos de enseñanza científica...." El Profesor de
Agricultura práctica instruirá las clases, en todas las varias
operaciones de los campos; en la económica aplicacion del
trabajo del hombre, caballos, i poder de vapor; en el valor,
adaptacion i aplicacion de los varios abonos i fertilizantes; en
la cria, cuidado, alimento i gordura del ganado; en el manejo
de la lechería; en el arreglo, construccion i usos de los
edificios de campo; en la accion i usos prácticos de todos los
elementos, maquinaria e instrumentos empleados en la
agricultura; en el sistema de drainaje, etc., etc. (Reglamento
del Colejio Agrícola del E. de N.Y.)
—"Establécese un Consejo de Agricultura, que se compondrá
de S. Exa. el Gobernador, el Teniente Gobernador, i el
Secretario de Estado ex-officiis, de un miembro de cada una
de las Sociedades Agrícolas de la República que reciben
distribucion anual de fondos públicos, i de tres miembros que
serán nombrados por el Gobernador i Consejo......" (Lei del
Estado de Massachusetts, sancionada el 22 de abril de 1852).
—"La Lejislatura fomentará el progreso de mejoras científicas
i agrícolas; i tan pronto como sea posible, proveerá al
establecimiento de una escuela de agricultura." Constitucion
del Estado de Michigan, adoptada en 1850, art. XIII, sec. II.
 —"La lejislatura fomentará por todos los medios convenientes
la mejora intelectual, moral, científica i agrícola." Constitucion
del Estado de California, sancionada en 1849, art. IX, sec. II.
—"Que se ruegue i de poder a S. Exa. el Gobernador para
nombrar cinco comisionados, a fin de considerar la
conveniencia de establecer escuelas o colejios de agricultura,
i tambien la de subministrar ausilios a los que existan, para la
instruccion de los alumnos que deseen asistir a semejantes
institutos, en todos aquellos ramos de los conocimientos
agrícolas necesarios para la mejora de los intereses de la
Agricultura, en este Estado." (Resolucion de la legislatura de
Massachusetts, mayo 3 de 1850).
Siendo las tierras públicas en los países que las poseen eriales una
propiedad perteneciente a la comunidad, su valor debe consagrarse
a la fundacion de los establecimientos de educacion comun, a fin de
que todas las clases de la sociedad, i todas las jeneraciones que se
sucedan participen de este bien comun, reservando a distancias
convenientes, ántes de enajenar las tierras, terreno para la
fundacion i sosten de las escuelas que la poblacion que las ocupe
habrá de necesitar.
"Será reservado de la venta de tierras públicas el lote número
16 (ciento cuarenta i cuatro cuadras), de cada municipio (dos
leguas cuadradas), para el sosten de las escuelas públicas
dentro de dicho municipio; i tambien una tercia parte de
todas las minas de oro, plata, cobre i plomo que hayan de
venderse o de que disponga el Congreso." Ordenanza de
1787, del Congreso de los E. U. para la venta de tierras
públicas, ratificada en todas las leyes posteriores, excepto en
la participacion de minas de oro, plata i cobre.
—"La seccion numerada diez i seis en cada municipio, i donde
tal seccion hubiere sido vendida, o se haya dispuesto de ella,
se concederán otras tierras equivalentes, i lo mas contiguas a
la misma, a los habitantes de dicho municipio para el uso de
las escuelas." Lei de Marzo de 1819.
—"Que se otorgue a cada uno de los estados especificados en
la primera seccion de esta acta (Ohio, Indiana, Illinois,
Alabama, Missouri, Mississippi, Louisiana, Arkansas i
Michigan) quinientos mil acres de tierras para mejoras
interiores....." Lei del Congreso de los E. U. 1841.
—"El producto de todas las tierras que han sido, o en
adelante fueren concedidas por los Estados-Unidos a este
estado para objetos de educacion (excepto las tierras de
antemano destinadas a una universidad), i todos los dineros i
el producto neto de toda propiedad que recaiga en el estado
por secuestro o por falta de herederos, i todos los dineros
que hayan de pagarse, como un equivalente de la excepcion
del servicio militar, i el producto neto de todas las multas
colectadas en los varios departamentos por infraccion de las
leyes penales, i el dinero proveniente de alguna concesion
hecha al Estado, cuando no se especifique el objeto de dicha
concesion, i los quinientos mil acres de tierra, a que el Estado
tiene derecho por el acta del Congreso (4 de setiembre de
1841), i tambien un cinco por ciento sobre el producto neto
de la venta de tierras públicas a que el Estado tiene derecho
por su admision en la Union, serán puestos aparte, como un
fondo separado, que se llamará el fondo de escuelas, cuyo
interes, i todas las otras rentas derivadas de las tierras
públicas, serán esclusivamente aplicadas a los objetos
siguientes, a saber: Al sosten i mantenimiento de escuelas
comunes en cada distrito de escuelas, i a la compra de
bibliotecas correspondientes i de aparatos, i el sobrante será
aplicado al sosten de colejios i escuelas normales con sus
bibliotecas i aparatos correspondientes." Const. de Wisconsin,
Cap. X, sec. 2, 1848.
(En cuanto al destino de las tierras públicas, todas las
constituciones de los Estados tienen disposiciones análogas o
idénticas).
Welcome to Our Bookstore - The Ultimate Destination for Book Lovers
Are you passionate about books and eager to explore new worlds of
knowledge? At our website, we offer a vast collection of books that
cater to every interest and age group. From classic literature to
specialized publications, self-help books, and children’s stories, we
have it all! Each book is a gateway to new adventures, helping you
expand your knowledge and nourish your soul
Experience Convenient and Enjoyable Book Shopping Our website is more
than just an online bookstore—it’s a bridge connecting readers to the
timeless values of culture and wisdom. With a sleek and user-friendly
interface and a smart search system, you can find your favorite books
quickly and easily. Enjoy special promotions, fast home delivery, and
a seamless shopping experience that saves you time and enhances your
love for reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!

ebookgate.com