![3
This chapter begins by analyzing some of the problems facing the software
industry. It then briefly chronicles certain aspects of the industry’s history.
Much of this history will already be familiar to many readers, but I present it
here in order to identify advances that MDA builds upon.
Challenges Facing the Software Industry
It’s common knowledge that difficult challenges confront the IT managers and
entrepreneurs who develop the software that is increasingly critical to the
functioning of the modern enterprise. Producing these systems involves pains-
taking, detailed work by highly skilled programmers. The recent contraction
of the high-tech economy hasn’t changed the fact that skilled software devel-
opers are expensive resources, making it a very costly proposition to staff
enterprise software development projects.
Furthermore, many software development investments yield disappointing
results. Some ambitious projects result in failure.1
Others go so far over budget
that management eventually kills them, which is another form of failure. Some
systems that initially succeed prove to be unstable or inflexible over time.
Pressure and Progress:
How We Arrived at This Point
C HAPTE R
1
1
“85% of IT departments in the U.S. fail to meet their organizations’ strategic business needs.”
[CW 1999]](https://image.slidesharecdn.com/1267584-250525150207-8716c8a1/85/Model-Driven-Architecture-Applying-Mda-To-Enterprise-Computing-1st-Edition-David-S-Frankel-32-320.jpg)
![There isn’t complete agreement in the software industry on the exact defini-
tion of component, but usually the term refers to a software module that can be
packaged in compiled form so that it can be independently deployed as part of
applications or assembled into larger components.
In manufacturing industries, manufacturers of finished products produce
required components or purchase them from a third party. The ability to use
standardized components in different products was one of the prime drivers
of the industrial revolution.
CBD, which is still maturing, presages another kind of industrial revolution,
one that applies to the production of software. Large companies can afford to
build some components themselves while purchasing some from component
vendors, while smaller companies are more apt to purchase all or most of the
components they use.
A detailed discussion of CBD is beyond the scope of this book. An important
book by Peter Herzum and Oliver Sims, entitled Business Component Factory,2
defines many important CBD concepts that I leverage in this book. I refer to
their approach as Herzum-Sims.
Design Patterns
The concept of design patterns, which is also a key element of industrial pro-
duction processes, has made an important contribution to improving software
development productivity and quality. Programmers can reuse common design
patterns that others have thought through and validated.
Generic reusable patterns have been published3
as well as patterns specific
to certain platforms such as Java 2 Platform Enterprise Edition (J2EE).4
For example, the J2EE BluePrints Value Object pattern5
supports efficient
information exchange with distributed components. Imagine a distributed
component that has multiple attributes including the customer ID, first name,
last name, address, Social Security number, and so on. Because remote invoca-
tion over a network is expensive, it’s inefficient to simply provide remote get
and set operations for each property. The Value Object pattern uses a Value
Object that contains get and set operations for each attribute and a façade object
that provides a remote operation to get a Value Object, thus making it possible
to retrieve the values of all of the properties with one remote call. The façade
object also provides a remote operation to set—that is, to pass in—a Value
Object, thus making it possible to set the values of all of the properties with
one remote call (see Figure 1.5).
10 Chapter 1
2
[HS 2000]
3
[GHJV 1995]
4
[ACM 2001]
5
[JVO]](https://image.slidesharecdn.com/1267584-250525150207-8716c8a1/85/Model-Driven-Architecture-Applying-Mda-To-Enterprise-Computing-1st-Edition-David-S-Frankel-39-320.jpg)
![dialog, whereupon the tool would generate the bulk of the code for displaying
and managing the dialog, with the programmer enhancing the generated code
to produce the finished product. The tools for drawing the GUIs were called
WYSIWYG (What You See Is What You Get) editors.
With EJB, .NET, and the CORBA Component Model, a descriptor contains
declarations of various properties of a component. The middleware acts in
accordance with the property declarations. For example, in order for a compo-
nent to support ACID6
transactions, a programmer need only declare such
support in the descriptor, rather than write a set of procedural instructions to
support transactional behavior. The middleware takes care of the rest.
We can classify two basic modes for processing declarations:
Code generation. In this mode, the declarations drive a 3GL code
generator. GUI development environments that generate code from a
WYSIWYG declaration of GUI properties are an example.
Runtime interpretation. In this mode, precompiled, predeployed
executable code interprets the declarations at runtime. For example, a
database engine does not generate new 3GL code when handed a new
declarative data model. Instead, the database engine more or less
interprets the model at runtime.
Enterprise Architecture and Separation of Concerns
Software architecture seeks to organize complex systems by separating con-
cerns. Separating concerns tends to localize changes to one aspect of a system.
When changes to one aspect do impact other aspects, separation of concerns
makes it easier to trace the impact.
Separating concerns tends to have a positive effect on the viability variables.
The localization of changes makes systems less brittle and thus improves their
longevity. Once an architecture and a supporting infrastructure are in place,
such localization also improves productivity because change can be effected
more rapidly. Traceability tends to improve quality.
Multitiered architecture is one of the most well-known and widely accepted
architectural approaches for distributed enterprise systems. Nevertheless,
there is some variance in the industry with regard to the number of tiers, and
the names and roles of the tiers. Since I use the concepts of multitiered archi-
tecture later in the book, it’s worth spelling out the concepts and terminology
that I employ.
14 Chapter 1
6
ACID transactions are atomic, consistent, isolated, and durable. See [GR 1993] for a definitive
work on the subject.](https://image.slidesharecdn.com/1267584-250525150207-8716c8a1/85/Model-Driven-Architecture-Applying-Mda-To-Enterprise-Computing-1st-Edition-David-S-Frankel-43-320.jpg)
![Through the lessons of experience, architects began to realize that systems
would be more scalable if the business logic that involves user interaction
were separated from other business logic. Thus the mid tier was split into two
tiers that separated these concerns: the workspace tier and the enterprise tier. The
workspace tier is responsible for executing the logic of the pattern of inter-
action with the user. The interaction logic accesses the enterprise tier rather
than going directly to the database.
Oliver Sims has been advocating four-tier architecture for the better part of
a decade.7
Herzum-Sims calls the four tiers user tier, workspace tier, enterprise
tier, and resource tier, as Figure 1.10 illustrates. The figure also points out alter-
nate names that some practitioners use for the tiers.
Figure 1.10 Four-tier enterprise architecture.
A B Means A accesses B
USER TIER (a.k.a. Client Tier)
User Presentation
WORKSPACE TIER (a.k.a. Interaction Tier)
User Interaction Logic
Servers
ENTERPRISE TIER (a.k.a. Business Tier)
Encapsulated Business Logic
Servers
RESOURCE TIER (a.k.a. Integration Tier)
Mainframe DBs DBs on other servers
Resource Adapters (e.g. Object-Relational Mappings)
Pressure and Progress: How We Arrived at This Point 19
7
See [HS 2000] for his most recent work on this subject.](https://image.slidesharecdn.com/1267584-250525150207-8716c8a1/85/Model-Driven-Architecture-Applying-Mda-To-Enterprise-Computing-1st-Edition-David-S-Frankel-48-320.jpg)
![Figure 1.11 Above and below the line.
The notion of viewpoints is another enterprise computing concept that sup-
ports the idea of separation of concerns. Aviewpoint is a projection of a system
that filters out aspects of the system not relevant to that viewpoint. For exam-
ple, we could define an application engineer’s viewpoint of a system as reveal-
ing only the above-the-line aspects of the system. An infrastructure engineer’s
viewpoint, on the other hand, reveals the below-the-line aspects. The Interna-
tional Organization for Standardization’s (ISO) RM-ODP makes a contribution
to enterprise architecture by exploring the nature and ramifications of view-
points. Each viewpoint is an abstraction of the system. RM-ODP defines
abstraction as the suppression of irrelevant detail.8
Enterprise architecture also defines the separation of entity and process,
defines levels of granularity of the various components of a system, and more.9
Multitiered architecture, granularity management, middleware layering,
and so on are a common basis for enterprise architecture that most companies
can adopt. However, it is always necessary for a business to customize these
common contours to meet its own unique requirements.
Enterprise Application Integration (EAI)
Enterprise architecture makes it possible to design enterprise systems that by
nature are well integrated. However, legacy systems and packaged applica-
tions are part of the IT landscape that cannot be ignored. By using enterprise
architecture to develop new software, you can avoid creating more discon-
nected islands of automation, but existing islands need to be brought into the
enterprise architecture as well.
Middleware
Service
APIs
"Above the Line"
Middleware
Implementations
3GL Languages
Compiler Implementations
"Below the Line"
Applications
Middleware
Configuration Languages
e.g., EJB Deployment
Descriptor DTD
3GL Languages
• Editors
• Programmatic and
user interfaces to
compilers
Pressure and Progress: How We Arrived at This Point 21
8
[RMODP]
9
For an excellent treatment of enterprise architecture see [HRG 2000].](https://image.slidesharecdn.com/1267584-250525150207-8716c8a1/85/Model-Driven-Architecture-Applying-Mda-To-Enterprise-Computing-1st-Edition-David-S-Frankel-50-320.jpg)
![EAI is an approach to knitting preexisting islands of automation together
within enterprise systems. Quite a few IT shops today are applying more
resources to EAI than to development of new enterprise applications and
components.
EAI adds the notion of application adapters to the resource tier. Application
adapters wrap functionality islands such as packaged applications and other
legacy systems. EAI systems support event-based communication among
adapters, which promotes loose coupling among the disparate islands. Enter-
prise architects understand that loose coupling is the preferred way to inte-
grate parts that were not designed to work with each other.10
Therefore, most EAI systems work by enabling disparate modules to send
asynchronous messages when they complete various tasks and to handle mes-
sages sent by other modules that they receive from an event queue. Messages
often consist of data that needs to be transformed, filtered, and/or routed to
multiple destinations.
Figure 1.12 depicts the addition of adapters to the resource tier and the
management of messages that flow among them.
There are a number of messaging-oriented middleware (MOM) platforms,
including IBM’s WebSphere MQ Integrator (formerly called MQSeries),
Microsoft’s MSMQ, and the Java Messaging Service (JMS).
Design by Contract
Design by Contract (DBC) is an approach to building reliable software that
focuses on making the contract of a software module explicit and formal. It
thus directly addresses the quality variable in the viability equation. E. W.
Dijkstra formulated the basic foundations of Design by Contract in the 1970s.11
Later advocates, such as Bertrand Meyer12
and Haim Kilov,13
built upon his
work. Meyer’s work laid the foundation for the Eiffel language.
DBC is based on a recognition that formal contract expression should go
beyond merely the expression of the signatures of the operations that a mod-
ule supports.
Design by Contract involves writing two kinds of formal constraints:
Pre-conditions and post-conditions. Pre-conditions and post-conditions
are assertions about operations. A pre-condition for an operation must
be true when the operation begins executing. A post-condition must be
true when the operation is finished executing.14
22 Chapter 1
10
In certain circumstances loose coupling can also be useful for integrating less disparate parts.
11
[DIJK 1976]
12
[MEYER 1997]
13
[KR 1994]
14
Some Design by Contract practitioners argue that it’s more correct to say that if a pre- or post-
condition isn’t satisfied, then the behavior of the operation is undefined, rather than to say that
the conditions must not be violated.](https://image.slidesharecdn.com/1267584-250525150207-8716c8a1/85/Model-Driven-Architecture-Applying-Mda-To-Enterprise-Computing-1st-Edition-David-S-Frankel-51-320.jpg)
Model Driven Architecture Applying Mda To Enterprise Computing 1st Edition David S Frankel
- 1. Model Driven Architecture Applying Mda To Enterprise Computing 1st Edition David S Frankel download https://ebookbell.com/product/model-driven-architecture-applying- mda-to-enterprise-computing-1st-edition-david-s-frankel-2535168 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Model Driven Architecture And Ontology Development 1st Edition Dragan Gasevic https://ebookbell.com/product/model-driven-architecture-and-ontology- development-1st-edition-dragan-gasevic-2163992 Model Driven Architecture Foundations And Applications 5th European Conference Ecmdafa 2009 Enschede The Netherlands June 2326 2009 Proceedings 1st Edition Tim Trew Auth https://ebookbell.com/product/model-driven-architecture-foundations- and-applications-5th-european-conference-ecmdafa-2009-enschede-the- netherlands-june-2326-2009-proceedings-1st-edition-tim-trew- auth-2535558 Model Driven Architecture In Practice Oscar Pastor Juan Carlos Molina https://ebookbell.com/product/model-driven-architecture-in-practice- oscar-pastor-juan-carlos-molina-4104662 Model Driven Architecture European Mda Workshops Foundations And Applications Mdafa 2003 And Mdafa 2004 Twente The Netherlands June 2627 2003 And Linkping Sweden June 1011 2004 Revised Selected Papers 1st Edition Liping Zhao Auth https://ebookbell.com/product/model-driven-architecture-european-mda- workshops-foundations-and-applications-mdafa-2003-and- mdafa-2004-twente-the-netherlands-june-2627-2003-and-linkping-sweden- june-1011-2004-revised-selected-papers-1st-edition-liping-zhao- auth-4604386
- 3. Model Driven Architecture Foundations And Applications First European Conference Ecmdafa 2005 Nuremberg Germany November 710 2005 Proceedings 1st Edition Maria Jos Presso https://ebookbell.com/product/model-driven-architecture-foundations- and-applications-first-european-conference-ecmdafa-2005-nuremberg- germany-november-710-2005-proceedings-1st-edition-maria-jos- presso-4604530 Model Driven Architecture For Reverse Engineering Technologies Strategic Directions And System Evolution 1st Edition Liliana Favre https://ebookbell.com/product/model-driven-architecture-for-reverse- engineering-technologies-strategic-directions-and-system- evolution-1st-edition-liliana-favre-1527516 Model Driven Architecture Foundations And Applications Second European Conference Ecmdafa 2006 Bilbao Spain July 1013 2006 Proceedings 1st Edition Vinay Kulkarni https://ebookbell.com/product/model-driven-architecture-foundations- and-applications-second-european-conference-ecmdafa-2006-bilbao-spain- july-1013-2006-proceedings-1st-edition-vinay-kulkarni-1548980 Model Driven Architecture Foundations And Applications 4th European Conference Ecmdafa 2008 Berlin Germany June 913 2008 Proceedings 1st Edition Louis M Rose https://ebookbell.com/product/model-driven-architecture-foundations- and-applications-4th-european-conference-ecmdafa-2008-berlin-germany- june-913-2008-proceedings-1st-edition-louis-m-rose-1548982 Model Driven Architecture Foundations And Applications Third European Conference Ecmdafa 2007 Haifa Israel June 1115 2007 Proccedings 1st Edition Achilleas Achilleos https://ebookbell.com/product/model-driven-architecture-foundations- and-applications-third-european-conference-ecmdafa-2007-haifa-israel- june-1115-2007-proccedings-1st-edition-achilleas-achilleos-1548984
- 6. David S. Frankel Model Driven Architecture Applying MDA to Enterprise Computing
- 8. Model Driven Architecture Applying MDA to Enterprise Computing
- 10. David S. Frankel Model Driven Architecture Applying MDA to Enterprise Computing
- 11. Publisher: Joe Wikert Editor: Theresa Hudson Assistant Development Editor: James H. Russell Editorial Manager: Kathryn A. Malm Associate Managing Editor: Angela Smith Text Design & Composition: Wiley Composition Services This book is printed on acid-free paper. ∞ Copyright © 2003 by David S. Frankel. All rights reserved. Published by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rose- wood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4470. Requests to the Pub- lisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4447, E-mail: [email protected]. Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, inci- dental, consequential, or other damages. For general information on our other products and services please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. Trademarks: Catalysis is a service mark of ICON Computing. CORBA is a registered trade- mark of the Object Management Group. “Design by Contract” is a trademark of Interactive Software Engineering. EJB, J2EE, and Java are trademarks of Sun Microsystems. Model Driven Architecture, MDA, MOF, Unified Modeling Language, UML, IIOP, and XMI are trademarks of the Object Management Group (OMG). MQSeries is a registered trademark of International Business Machines. Visual Basic is a registered trademark of Microsoft Corporation. Library of Congress Cataloging-in-Publication Data: ISBN: 0-471-31920-1 Printed in the United States of America 10 9 8 7 6 5 4 3 2 1
- 12. To my mother and my late father, who taught me to value learning and truth. To my wife Janice, my loving partner during all the ups and downs of life. To my children, Rafi and Ari, my connection to the future.
- 14. Contents vii Preface xv Foreword xix Part One Introducing MDA 1 Chapter 1 Pressure and Progress: How We Arrived at This Point 3 Challenges Facing the Software Industry 3 The Viability Variables 4 Machine-Centric Computing 5 Application-Centric Computing 6 From Assembly to 3GLs 6 Operating Systems and the Abstraction Gap 8 Object-Oriented Languages and Virtual Machines 8 Enterprise-Centric Computing 9 Component-Based Development 9 Design Patterns 10 Distributed Computing 11 Middleware: Raising the Platform Abstraction Level 12 Middleware: Raising the Programming Abstraction Level 13 Declarative Specification 13 Enterprise Architecture and Separation of Concerns 14 Enterprise Application Integration (EAI) 21 Design by Contract 22 Other Enterprise-Centric Technologies 25 Pressures on Enterprise-Centric Computing 25 Pressure on Production Costs 26 Pressure on Quality 27 Pressure on Longevity 28 A Modern Day Sisyphus 30 Summary 30
- 15. Chapter 2 Model Driven Enterprise Computing 31 Bringing Model-Centrism to Intermediate Tiers, EAI, and B2Bi 31 Models as Development Artifacts 32 Syntactic Abstraction versus Semantic Abstraction 32 B2Bi and MDA 35 First- and Second-Generation Web Services Integration 36 Web Services and Enterprise Architecture 38 Defining Abstract Business Services 39 Mapping Business Information Models to XML 41 Parameterized Mappings 41 Mapping Business Service Models to WSDL 42 Automating Business Processes and B2B Collaborations 43 Flexibility in Choosing the Abstraction Level 45 Modeling Language Extensibility 46 Platform Independence: A Relative Concept 48 EAI and MDA 50 The Limits of Declarative Specification 52 Metadata Integration 52 MDA and Component-Based Development 54 Automatic Pattern Replication 54 A J2EE Example 55 Architectural Styles 56 Pushing More below the Line 57 Model Driven Enterprise Architecture 58 Standardized MDA-Based Modeling Languages 59 Synchronizing among Multiple Tiers 60 Middleware and the Abstraction Gap 60 Design by Contract Revisited 61 MDA and Other New Development Approaches 62 Interactive Design 62 Extreme Programming 63 Summary 64 Part Two The Base MDA Technologies 65 Chapter 3 The Role of UML in MDA 67 Origins and Evolution 67 Strengths 68 Separation of Abstract Syntax from Concrete Syntax 68 Extensibility 70 Support for Platform-Independent Modeling 71 Maintained by a Standards Organization 72 Weaknesses 73 Large and Poorly Partitioned 73 Weak Support for Viewpoints 74 Not Current with Industry Developments in Components and Patterns 74 Vagueness about Relationships 74 viii Contents T E A M F L Y Team-Fly®
- 16. Limitations of Profiling 74 Misalignment of UML and MOF 75 Lack of Standard Diagram Interchange 75 Lack of a Metamodel for Object Constraint Language 75 Future Directions 76 UML 2.0 76 Expected Outcomes 76 What You Can Do Now 77 Summary 77 Chapter 4 Beyond Basic Class Modeling 79 Design by Contract 79 The Basics 79 An Example 80 Contracts, Reuse, and Interoperability 83 As Precise as Programming3 85 Constraints and Exceptions 86 A Framework for Quality 86 DBC and UML Tools 87 Overcoming Barriers to Use 87 Another Look at Constraints 87 Behavioral Modeling 88 State Machines 88 Activity Models 91 Interaction Models 92 Use Case Models 93 Action Semantics 93 What You Can Do Now 94 Summary 94 Chapter 5 The Meta Object Facility (MOF) 95 A Key MDA Foundation 95 A Basic Premise 97 Borrowing from UML 98 MOF Isn’t Just for OO 101 Abstract Syntax Trees 103 Metalevels 105 Level M3 105 Level M2 106 Level M1 106 Level M0 107 How Meaningful Are Metalevels? 107 Self-Description 108 Metalevels and Abstract Syntax 109 Model Driven Metadata Management 110 What Is Metadata? 110 Volume and Value 111 Previous Attempts at Metadata Integration 111 Contents ix
- 17. An Additional Premise 112 What Is the Benefit? 113 Platform Independence 113 Enforcing Semantics 115 Metadata Management Scenarios 115 Generic MOF Code 118 MOF Is Not CORBA-Based 119 Appearances versus Intent 120 Mapping beyond Syntax 120 Applying the MOF-CORBA Mapping 120 A Closer Look at XMI 122 Return on Investment 122 XMI and XML Schema 124 A Common Misconception about XMI 124 Hand-Coded DTDs and Schemas 124 XMI Complexity versus UML Complexity 125 XMI as Input to Generators 126 XMI and UML Diagram Interchange 127 A Closer Look at JMI 128 A MOF-Java Mapping 128 Aren’t XML and DOM Enough? 129 Another Look at MOF Self-Description 131 Additional Applications 135 Human Usable Textual Notations 135 XMI’s Reverse Mapping 136 Weaknesses 138 Lack of Coverage of Graphical Notation 138 Lack of Support for Versioning 138 Misalignment with UML 139 MOF-CORBA Mapping Problems 139 Interoperability Problems Due to Immaturity 139 Future Directions 140 Interoperability Testing 140 MOF 2.0 140 MOF in the Computer Industry 140 MOF and Enterprise Software 141 MOF and the Resource Description Framework (RDF) 142 What You Can Do Now 142 Summary 143 Chapter 6 Extending and Creating Modeling Languages 145 Extending UML via Profiles 145 A Family of Languages 145 Stereotypes 146 Tagged Values of Stereotypes 147 Standalone Tagged Values 148 x Contents
- 18. Can’t We Do This at M1? 149 Defining a Profile Formally 150 Extending UML via MOF 153 Anatomy of a Heavyweight UML Metamodel Extension 153 Profiles versus Heavyweight Extensions 154 Creating New Modeling Languages 155 Tight Domain Focus 155 The Metamodel + Profile Strategy 156 Heavyweight + Lightweight Extension Strategy 158 UML Tools versus MDA Tools 158 UML Modeling versus MOF Metamodeling 159 UML Constructs That MOF Does Not Support 159 What You Can Do Now 161 Summary 161 Chapter 7 Building Compilable Class Models 163 The Scope of the Guidelines 163 Class Modeling versus Behavioral Modeling 164 Level of Abstraction 164 What the Standard MDA Mappings Produce 164 UML versus MOF 165 Purposes of the Guidelines 165 Don’t Define Accessor and Mutator Operations for Attributes 166 Use Association End Navigability Judiciously 167 Navigable versus Non-Navigable Association Ends 168 Navigability and Contracts 168 Redundancy and Navigable Association Ends 170 Generating Read-Only APIs 170 Navigability and Information Formats 171 Avoiding Name Clashes 172 Navigability and Modularity 172 A MOF Complication 174 Use Care in Specifying Multivalued Properties 176 Ordering 176 Uniqueness 176 Use Aggregation . . . Properly 177 Aggregation Properties of Association Ends 177 Composite Aggregation 178 Shared Aggregation 180 Use Abstract Classes 181 Distinguish “Interesting” versus “Uninteresting” Operations 183 Strive for Computational Completeness 185 Syntactic Completeness 185 Semantic Completeness 187 Contents xi
- 19. Special Concerns with M1 Models 188 Use of Deferred Constraints 188 Need for Lower-Level Models 188 What You Can Do Now 189 Summary 189 Chapter 8 Modeling at Different Abstraction Levels 191 A Basic Model Taxonomy 192 Iterative Development 193 How the Models Fit Together 193 MDA Personas 194 Business Analyst 195 Requirements Analyst 195 Application Engineer 195 Middleware Engineer 195 Quality Assurance Engineer 196 Deployment Engineer 196 Network Administrator 196 Architect 196 Infrastructure Engineer 197 Persona Synopsis 197 Introduction to the Examples 197 Business Models 198 Requirements Models 200 Platform-Independent Models (PIMs) 203 Platform-Specific Models (PSMs) 207 An EJB-Specific Model 207 Java Plus Semantics 208 Tracing between Abstraction Levels 209 Limitations of Declarative Models 210 Parameterizing a PIM-PSM Mapping 210 Mapping PIM Collections 210 JMI’s Approach 213 Defining a Parameterization Language 214 Searching for an Abstraction 214 Parameterizing a PSM-Code Mapping 217 Selecting Implementations 218 Elements That Are Less Traceable to the PIM 220 Benefits of Read-Only PSMs 221 PIM Typing Issues 222 Multiple Parameterizations 224 Multiple Parameter Sets in the PIM 224 Multiple Parameter Sets in the PSM 225 Language Definition Strategies 226 Component Descriptors 228 xii Contents
- 20. Synchronizing Models and Code 230 The “Forward Engineering Only” Approach 230 Partial Round-Trip Engineering 233 Full Round-Trip Engineering 235 Round-Tripping and Tools 237 Round-Tripping and Architectural Enforcement 237 Inter-Tier Synchronization 238 The Impact of PSMs 241 Dimensional Flexibility 243 Synchronization Synopsis 243 Physical Models and Deployment Automation 244 What You Can Do Now 245 Summary 245 Part Three Advanced Topics 247 Chapter 9 Modeling Transformations with CWM 249 More Than a Database Metamodel 249 Implementation Strategies 251 The Inner Workings 254 Common Superclasses 254 Mapping Expressions 257 UML Models as Sources and Targets 260 Metamodel-to-Metamodel Mappings 262 MOF Mappings 266 Completing the Picture 268 Limitations 270 What You Can Do Now 271 Summary 271 Chapter 10 Additional Advanced Topics 273 Generating Declarative versus Imperative Code 273 APIs 273 Information Formats 274 The Role of Standards 274 Green Fields versus Legacy 275 Metadata Management Revisited 276 Metadata Management as a Green Field 276 Implementing Interesting Operations 276 Implementing Derived Attributes and Associations 278 Synopsis 279 Generating Bridges 280 Mappings—The Essential Knowledge 280 Generalizing the Bridging Problem 282 Standards and Bridges 285 Contents xiii
- 21. Executable Models and Virtual Machines 286 Examples from Industry 286 Correctness 287 Performance 287 Dynamism at the Lower Level 288 Reflection 290 Reflection and Metadata Fragmentation 290 Drawing Conclusions 291 A Middle Way 292 Raising the Platform Revisited 292 MDA and Systems Engineering 293 What You Can Do Now 293 Summary 294 Epilogue A Reality Check 295 Appendix A Sample Transaction Metamodel 297 ModelElement 297 Tx 297 ACIDTx 297 BusinessTxUnit 298 CompensatableUnit 299 ReversableUnit 299 BusinessTx 299 Appendix B Options Trading Concepts 301 Basic Concepts 301 Examples 302 References 305 Glossary 309 Index 313 xiv Contents
- 22. Preface xv The computer industry is always looking for ways to improve software devel- opment productivity as well as the quality and longevity of the software that it creates. Object-orientation, component-based development, patterns, and distributed computing infrastructures are examples of new approaches that have aided in this quest. Model Driven Architecture (MDA) can make an important contribution as well. It does not eclipse the other approaches. Rather, it works with them syn- ergistically to further improve the way we develop software. What Is Model Driven Architecture? MDA is about using modeling languages as programming languages rather than merely as design languages. Programming with modeling languages can improve the productivity, quality, and longevity outlook. This book explains why this is so, and introduces the technologies that underlie MDA. Who Is Using MDA? MDA has been used for years to generate real-time and embedded systems, even though the term MDAwas coined later. Now IBM, Oracle, Unisys, IONA, and other vendors are weaving MDA-based technology into their enterprise software offerings.
- 23. A Long-Term Transition In the early days of distributed object computing, one of the fathers of CORBA, Mike Guttman, was asked to give a talk to an industry gathering to share his vision of where the technology was headed. He showed a slide projecting that there would be a point in the future when distributed object infrastructures and libraries of components that ran on those infrastructures would be mainstream. An audience member asked him when he thought that would happen. He said that he thought it could easily take 10 to 15 years. He hastened to add that substantial business value would be gained at each stage of the transition, but that did not seem to stick in the minds of the sponsors, who were somewhat chagrined. They took the remark to mean that he was suggesting that nobody should invest in such technology for another decade. I take a similar risk in presenting this book on MDA. To be sure, MDA prin- ciples can be put to good use now. There are specific technologies already in place based on MDA and a number of others are emerging as I write these words. Tools that automate some aspect of software development using mod- els constitute at least a $500 million industry. Nevertheless, I stress that MDA is a budding technology that has years of work ahead before it can realize its full potential. MDA and the Object Management Group (OMG) Early in 2002 the OMG announced Model Driven Architecture as its strategic direction. The OMG is in the early stages of defining this course, and I have been deeply involved in the effort. I hope that this book will help guide this ini- tiative, but I don’t guarantee that my ideas entirely coincide with the OMG’s. As the steward of several modeling language standards, the OMG is posi- tioned to play a pivotal role supporting the growth of this new industry. But other standards bodies such as the Java Community Process, ebXML, and RosettaNet are producing specifications that apply MDA principles to various technologies and application domains. As the industry gains experience, stan- dards bodies will issue additional MDA-based standards. This book suggests some directions that these standards should take as they evolve. It also points out some deficiencies of the standardized modeling languages that must be rectified in order to fully realize the vision of MDA. Goals of This Book Despite MDA’s successes in the real time and embedded systems world, until recently few had applied it comprehensively to the development and xvi Preface
- 24. integration of enterprise systems that manage things like customers, accounts receivable, and supply chains and business-to-business integration. This book focuses on MDA in the context of enterprise systems. I want the builders of enterprise systems to understand MDA accomplishments to date and the potential that MDA offers for improving software development. I also want tool builders to understand what they can do to tap the potential. I want both audiences to be aware of the kinds of issues they will face in trying to scale MDA up to where it can consistently support the development and inte- gration of enterprise systems. Non-Goals of This Book In order for MDA to become a mature technology, one of the tasks that must be completed is the definition of a comprehensive conceptual framework for MDA. In this book I do not undertake to define such a framework, which would tie in conceptual advances in such areas as Aspect-Oriented Program- ming and Intentional Programming. Furthermore, although the book explains what the general shape of a com- prehensive MDA-based enterprise architecture would be, it does not actually define such an architecture. In concentrating on the base MDA technologies, I don’t intend to imply that the kind of comprehensive treatment this book does not supply is not impor- tant. I hope that others will find this basic work helps them to tackle these more ambitious tasks. Organization of the Book This book is organized into parts, each of which consists of a number of chapters. Part One: Introducing MDA establishes the motivation for MDA and pro- vides an overview of the subject. Part Two: The Base MDA Technologies is a hands-on tour through the technologies that constitute MDA’s foundation. This is the heart of the book, containing a large majority of the material. Part Three: Advanced Topics outlines some of MDA’s more ambitious medium- to long-range possibilities. Epilogue is a reality check about the future of MDA. A reader looking for an executive overview of MDA should read this Pref- ace, Part One, and the Epilogue. More technically oriented readers should also read Parts Two and Three. Preface xvii
- 25. Acknowledgments Most of the content of this book synthesizes work done by others. In particu- lar I wish to thank Mike Guttman, my mentor and friend for over 30 years, who helped me edit the final manuscript, provided important suggestions and feedback, and of course wrote the Foreword. I also recognize the contributions of Jack Greenfield, a pioneer in this field from whom I have learned a great deal. Special thanks go to Scott Ambler, Grady Booch, Steve Brodsky, Steve Cook, Philippe Kruchten, Scott Markel, David Mellor, Steve Mellor, Mike Rosen, Bran Selic, Oliver Sims, and Jos Warmer for their reviews of the manuscript. I would also like to acknowledge some other people who helped me develop my ideas on MDA. These include Don Baisely, Conrad Bock, Cory Casanave, Desmond D’Souza, Simon Johnston, Sridhar Iyengar, Haim Kilov, Cris Kobryn, Wojtek Kozaczynski, Jason Matthews, Guus Ramackers, Jim Rumbaugh, Ed Seidewitz, and Richard Soley. About the Author DAVID S. FRANKEL has held senior positions at QuarterSoft, Inc., IONA Technologies, and Genesis Development Corporation. He is a renowned expert in the architecture and development of complex, large-scale distributed computing systems. He has served several terms on the OMG Architecture Board. David Frankel’s contact information: Email: [email protected] (or [email protected]) Tel: +1 530 893-1100 T E A M F L Y Team-Fly®
- 26. On June 14, 1951—shortly after I was born—the U.S. Census Bureau bought the very first UNIVAC computer. This was arguably Sale #1 for the now-behe- moth commercial computing industry. That UNIVAC, the first mainframe, was about the size of a one-car garage, and required a 125-kilowatt power sup- ply to both heat and cool its 5200 vacuum tubes. For the UNIVAC’s million-dollar price tag (worth about seven times that at this writing), the Bureau’s programmers got a whopping 1000 words of pro- gram memory to play with. Nonetheless, compared to any then-available alternative, this was powerful enough to drive the sales of no less than forty- five more UNIVACs over the next five years. It also spawned a slew of com- petitors. One of these, IBM, became the largest corporation on earth, largely on the back of its computer mainframe business. In any event, the first programmers had their work cut out for them. Obvi- ously, starting with just 1000 words of memory, they focused largely on opti- mizing the use of memory and the speed of calculations for a specific machine. For many years, software engineering was driven almost entirely by the requirements—and limitations—of the available hardware. This strongly influenced both the types of computing problems that were selected, and the specific way in which software was developed. Amazingly—and despite Moore’s much-vaunted law governing the expo- nential growth of hardware power—many aspects of this kind of platform- centric thinking about software have persisted up to the present. In 1970, I was cramming bytes into an IBM 360 MVS partition. In 1980, I was juggling to keep my programs within 64K on an HP 2100MX minicomputer. In 1990, I was still worrying about whether my code would compile into a DLL small enough to load efficiently on a PC, and whether I was using up too many Windows Foreword xix
- 27. “handles.” In 1995, when I worked on the CORBA Internet Interoperability (IIOP) standard, I found myself yet again twiddling bits to minimize the size of messages going out over the wire. Nevertheless, there is a really big qualitative difference between 1951 and today. Today a steadily increasing percentage of the typical IT department’s software development process revolves around issues related to modeling the business problems to be solved, rather than the details of writing code. This is true not because individual developers necessarily really want to move in this direction, but simply because the increasing complexity of the business prob- lems that need to be solved demands such a requirements-driven approach. Perhaps reluctantly, some developers are now spending almost as much time fumbling with modeling languages like UML as they are fiddling with tradi- tional programming languages like Java and XML. This approach was presaged as early as 1960, when COBOL, the first plat- form-neutral business-oriented programming language, was introduced. The COBOL programming paradigm explicitly separated the software from the hardware, allowing programmers to think a lot more about business logic and a lot less about machine-level bit-twiddling. COBOL also introduced a signifi- cant amount of structure into software development, forcing its users to at least separate program flow logic from data descriptions and environment specifications. Over the next twenty years, COBOL’s increasing hegemony in the main- frame software market helped to foster an immense amount of de facto stan- dardization of architecture and design across the entire computing industry. This was the first “Golden Age” of software development, and many of the systems created during that period remain the data processing workhorses of major corporations today. Remarkably, they still tower like Gothic cathedrals over the tenements of software bubble-gum and baling wire that characterize so many subsequent systems. Ironically, it was the introduction of the PC—a great boon to computing in most respects—that brought the end of this Golden Age. The PC unintention- ally ushered in a new period of chaos for software development. By historical accident, the structured, platform-neutral languages like COBOL were slow to move over to the PC, and a Babel of other programming languages and devel- opment tools emerged to fill the vacuum. To accommodate the new blend of hobbyist-programmer that gravitated to the early PCs, these languages toler- ated—and even encouraged—low-level, platform-specific bit-twiddling. So, in one sense, the PC era, which started in the 1980s and exploded in the 1990s, was a second great renaissance for computing, pushing software into areas—and in front of users—where it had never been before. At the same time, however, the resulting tidal wave of polyglot software pretty much overwhelmed the traditional IT software development community and, in many ways, actually pushed back the clock in terms of systematic software xx Foreword
- 28. architecture and design. A similar discombobulating tsunami struck again with the commercialization of the Internet. Of course, all during the PC and Internet eras, many industry pundits have continued to advise developers to “design before you code” and—more recently— “to architect before you design.” In fact, there have been many pos- itive innovations in this direction over the last twenty years. But, for the mass of developers who grew up during code-centric PC era, old habits and atti- tudes die hard. To these developers, abstracting design (much less architec- ture) from programming can seem an innately uncomfortable experience that simply “delays coding.” Because of this discomfort, they frequently (if unwit- tingly) sabotage whatever design process is attempted, thereby “proving once again”—at least to themselves—that they would have been much better off to have simply started coding as early as possible. As a result, it has taken almost twenty years to reach the point where we can start recreating a level of rigor in IT software development that approaches that of the previous Golden Age of software. In the last decade or so, the idea that implementation-independent design and architecture have real intrinsic value to the development process quietly seems to be making a comeback. Sometimes this voice of reason can barely be heard above the incessant drum- beat of vendor hype and techno-babble that characterizes much of the soft- ware industry. Nonetheless, a new approach seems to be gaining critical mass in the developer and vendor community, reconstructing the best practices of the first Golden Age, while still incorporating the innovations in software engineering that came about during the PC and Internet revolutions. Model Driven Architecture (MDA), which this book describes, is a major step in this direction. What makes MDA different from any of the myriad other TLAs (three letter acronyms) that constantly flood the software community? Well, first of all, the development of MDA is being driven by the OMG, the largest software industry consortium. OMG has an enviable track record for promulgating and maintaining some of the industry’s most successful stan- dards, such as CORBA and UML. In addition, within OMG, MDA has enjoyed unusually strong backing from the systems and software vendor community. Usually initiatives of this kind take years to develop this level of consensus and support. However, even die- hard rivals such as IBM, Sun, and Microsoft are already strongly behind MDA and actively support the major standards —UML, XMI, MOF, CWM, JMI, and so on—that MDA encompasses. They will no doubt argue incessantly about the details, but they are solidly behind the approach. This means that the sup- porting mainstream tools and platforms MDA needs to grow and prosper are certainly well on the way. Finally, MDA does not purport to wholesale replace previous computing paradigms, languages, or tools. Instead, it attempts to harmonize them, allow- ing everyone to migrate gracefully to the MDA vision at their own pace, and in Foreword xxi
- 29. xxii Foreword response to their real need to do so. MDA is also specifically designed to be flexible enough to adapt to the inevitable—new software technologies that, like the PC and the Internet, will soon emerge to upend all our previous assumptions about computing. As a result, I believe that MDA actually stands a pretty good chance of revi- talizing the practice of software architecture and helping to usher in another Golden Age of software development. This is none too soon, because, as the book suggests, the rising complexity of business problems to be computerized is currently testing the limits of the last generation of development paradigms. As this book cogently argues, to deal with this complexity, design and archi- tecture standards like MDA are needed now to supplant earlier approaches as the focal point in the overall enterprise software development process. This clearly hearkens back to thirty years ago when COBOL and 3GL languages were sorely needed to replace machine code and assembly language as the principal programming tools for business applications. Nonetheless, some developers will undoubtedly try to ignore developments like MDA, and shoulder on as before, milking their existing code-centric development skills for as long as they can. In the near future, however, the most successful and productive developers will certainly be those who are willing to move aggressively to embrace the kind of design- and architecture- centric paradigms that MDA represents. That’s why this book is so important. As the first comprehensive book on MDA, it has the opportunity to set the standard for how MDA is received by the overall software development community. Fortunately, the author, David Frankel, is not just a good technical writer, but also a recognized authority on MDA and one of the driving forces behind the strategic and technical devel- opment of MDA at OMG. Just as importantly, I can tell you from personal experience that David is an accomplished developer and development manager who understands what it means to get real systems out the door. As a result, while this is not a cook- book, it is peppered with examples that show how MDA can be applied to real problems faced by real developers today. In short, I can think of no better person to clearly explain both the concepts and details behind MDA to software technicians and industry technologists alike. So, if you are new to MDA, or having any trouble understanding it, my advice is simple—start by reading this book. It will give you exactly the foun- dation you need to start mastering MDA and immediately applying its con- cepts directly and effectively to your own environment and problems. —Michael Guttman
- 30. PART One Introducing MDA MDA is not a radical departure in the way we have gone about improving software development over the years. Rather, it is an evolutionary step that consolidates a number of trends that have gradually improved the way we produce software. This part of the book positions MDA on that evolutionary path.
- 32. 3 This chapter begins by analyzing some of the problems facing the software industry. It then briefly chronicles certain aspects of the industry’s history. Much of this history will already be familiar to many readers, but I present it here in order to identify advances that MDA builds upon. Challenges Facing the Software Industry It’s common knowledge that difficult challenges confront the IT managers and entrepreneurs who develop the software that is increasingly critical to the functioning of the modern enterprise. Producing these systems involves pains- taking, detailed work by highly skilled programmers. The recent contraction of the high-tech economy hasn’t changed the fact that skilled software devel- opers are expensive resources, making it a very costly proposition to staff enterprise software development projects. Furthermore, many software development investments yield disappointing results. Some ambitious projects result in failure.1 Others go so far over budget that management eventually kills them, which is another form of failure. Some systems that initially succeed prove to be unstable or inflexible over time. Pressure and Progress: How We Arrived at This Point C HAPTE R 1 1 “85% of IT departments in the U.S. fail to meet their organizations’ strategic business needs.” [CW 1999]
- 33. The booming economy of the 1990s covered up many of the ramifications of frequent failure. Corporate earnings were so high that investors often ignored the schedule delays, cost overruns, and disappointing quality of business soft- ware systems built by high-tech startups and Global 1000 companies. A frequent comment from investment analysts who were surprised by the steepness of the NASDAQ’s decline is that they never expected such a drastic shutdown of technology spending. In a tighter economic environment, enter- prise software development must prove its business merit. Corporate man- agers are unlikely to expend precious capital on projects and products that don’t demonstrate compelling value. This kind of pressure is not new. The computer industry has gone through repeated cycles of pressure followed by advances that relieve the pressure and open up new possibilities, whereupon pressure starts building again. The Viability Variables Our industry’s economic viability is determined by the extent to which we can produce systems whose quality and longevity are in line with their cost of production. Building high-quality, long-lasting business software is expensive. As a result, sometimes we are forced to make unacceptable trade-offs among quality, longevity, and the cost of production, which I define as the software develop- ment viability variables (see Figure 1.1). It’s difficult to increase viability by addressing just one of the variables in the equation without considering the impact on the others. To promote eco- nomic viability, we must reduce the cost of production without sacrificing the quality or longevity of the software. Interestingly, we can view the history of the software industry as a series of improvements that rebalanced the viability equation at junctures where grow- ing demands pushed the limits of current approaches to development. New approaches arose each time to replace or augment current ones, slowly at first, then with increasing momentum, helping to align quality and longevity with the cost of production. Figure 1.1 The viability variables. Cost of Production Viability Quality Longevity 4 Chapter 1
- 34. Machine-Centric Computing Early programmers literally coded instructions to the computer in 1s and 0s, laboriously writing out the bit patterns that corresponded to the native CPU instructions. That seems strangely inefficient today, but for some applications the rapid calculations that the computer could perform made this kind of cod- ing economically sound. It also allowed programmers to optimize available memory and processor speed. However, the high costs inherent in labor- intensive 1s and 0s coding, coupled with high hardware costs, sharply limited the number of tasks amenable to computerization. An important software innovation—assembly language—extended the ser- viceable lifetime of machine-centric computing. Assembly language allowed programmers to use simple mnemonics to represent the native instructions that the computer understands. The programmer could write MOV AX,DX to move data from the D register to the A register, instead of writing out the binary code for the move instruction. The programmer could also give a mem- ory location a name and then address the location by that name instead of always having to refer to it by its binary address. The mnemonics and names were abstractions of the binary instructions and memory locations. An assem- bler translated the mnemonics and names into the 1s and 0s that constitute the binary representations of the native processor instructions and memory locations. Many programmers in the industry today have only used assembly lan- guage in their college courses. But, in their day, assemblers significantly changed the economic viability equation. Writing a program became much less time-consuming, thus lowering production costs. Furthermore, it turned out that programmers were less prone to error when using mnemonics than when tediously hand-coding 1s and 0s. Therefore, the level of quality rose. Finally, programs coded with assembly language were less sensitive to incremental changes made to the patterns of 1s and 0s that constituted each of the native instructions. For instance, if a change in the 1s and 0s pattern for MOV instructions occurred from one version of the processor to another, a revised assembler could assemble the programmer’s MOV instruction into the different bit pattern. The old assembly language program source code grace- fully survived the change to new patterns of 1s and 0s. Therefore, the longevity of programs tended to increase. Thus, raising the abstraction level above 1s and 0s favorably changed all three variables in the viability equation. Assemblers made it practical for large companies and government institutions to computerize certain aspects of their operations, such as payroll and billing, which consisted of relatively simple, repetitive tasks. See Figure 1.2. Pressure and Progress: How We Arrived at This Point 5
- 35. Figure 1.2 Raising the level of abstraction. Application-Centric Computing The success of assemblers pointed the way toward an application-centric world, where more complex applications solve a wider range of business problems that entail multiple steps, richer data structures, and human inter- faces. Order entry applications are a prime example of such applications. However, the demand for more complex computing strained the economic viability of machine-centric computing. From Assembly to 3GLs Assembly language programmers, although freed from the tedium of 1s and 0s, still programmed directly in terms of the native instruction set of the processor. The native instruction set is a very low-level set of concepts. A rou- tine to simply read an employee’s monthly salary from a table, read a few tax percentages from another table, and calculate the amount of the check to be issued could require hundreds of instructions, each a separate line in a hand- coded assembly language program. The advent of third-generation languages (3GLs) enabled a big productivity jump. Even the earliest 3GLs, such as FORTRAN and COBOL, raised the abstraction level far above the concepts of the processor instruction set. The developer now programmed with much higher-level constructs. A simple PRINT instruction in FORTRAN replaced tens or even hundreds of lines of assembly code. Language compilers translated the higher-level instructions into native processor instructions, which were now informally called machine code. The ability to program a piece of logic by writing a few instructions instead of dozens dramatically increased programmer productivity, and thus drove down production costs. It also allowed “mere mortals,” such as certain classes of business analysts, to migrate into programming. Assembly Language 1s and 0s Raising the abstraction level improves the viability variables • Cost of Production • Longevity • Quality 6 Chapter 1 T E A M F L Y Team-Fly®
- 36. Initially some programmers legitimately complained that, when the com- piler translated 3GL constructs into machine code, the result was less optimal than the machine code they could write by hand. In addition, early compilers occasionally introduced errors when translating 3GL code into machine code. Over time, though, the productivity improvement more than offset these prob- lems. Machine cycles were becoming cheaper. Programmer labor was, if any- thing, becoming more expensive. The use of 3GLs to produce somewhat less optimal programs essentially offloaded some of the computing burden from expensive programmers to inexpensive machine resources. Improvements in compiler technology also gradually made it possible to generate more reliable and more optimal machine code. New structured 3GLs, such as C and Pascal, introduced even more power- ful programming models. System vendors began to use 3GLs instead of assembly language even to define operating system services. Source-level debuggers were particularly important in promoting the transition to 3GLs because they made it possible for programmers to think entirely in terms of the programming models defined by the 3GLs. Gradually, programmers let go of their reliance on assembly language. The big reduction in the number of lines of handwritten code required to automate business functions also improved the quality of computer programs. They became more intellectually manageable. The opportunity for subtle error is greater when you have to write dozens of instructions for some purpose, as opposed to just a few. 3GLs also increased program longevity. The instructions used in 3GL pro- grams were far removed from the minutiae of the native processor instruction set. If a change in hardware brought in a new processor with a different instruction set, a new compiler could process an unchanged (or minimally changed), preexisting 3GL program and generate machine code targeted to the new hardware. Changes in processor architecture no longer made programs obsolete. The ability to retarget 3GL programs to different processors became known as portability. At first portability, while nice in theory, was shaky in practice. However, over time, 3GL standards and tools matured and port- ability became a practical—if somewhat imperfect—reality. Once again, all three of the viability variables changed in the right direction. A large reservoir of pent-up demand for application development was tapped. Whole new classes of applications became economically viable. It was possible to write more ambitious programs that would have been prohibitively mas- sive in assembly language. Companies below the top tier could now comput- erize some of their operations, a trend that was reinforced by plunging hardware costs. Well before the end of the twentieth century, most, if not all, medium and large businesses had software applications managing at least some of their basic business operations and providing management decision support. Many small businesses were computerized as well. See Figure 1.3. Pressure and Progress: How We Arrived at This Point 7
- 37. Figure 1.3 3GLs further raised the level of abstraction. Operating Systems and the Abstraction Gap Whereas 3GLs raised the level of abstraction of the programming environment, operating systems raised the level of abstraction of the computing platform. If a 3GL compiler has to produce detailed machine code for routine functions such as disk and display manipulation, its job is harder than if it can simply generate machine code that invokes operating system disk and display services. Thus, by raising the level of abstraction of the computing platform, operat- ing systems reduced the abstraction gap between 3GLs and the platform, as Figure 1.4 depicts. Object-Oriented Languages and Virtual Machines Inevitably, as demand for complex features and quick time to market increased, viability problems began to surface with application-centric com- puting, spurring efforts to improve development methods. The result was sev- eral important incremental improvements that extended the lifetime of application-centric computing. Structured 3GLs evolved into object-oriented 3GLs, including Smalltalk and C++. These new languages make it easier to reuse parts of programs in differ- ent contexts. Some object-oriented languages introduce an interpreter called a virtual machine that executes intermediate code generated by the language compiler. Smalltalk, Java, and C# are the prime examples of such languages. The intermediate code is processor- and operating-system-independent. Thus, implementing the virtual machine over different processors and operating systems makes it possible to port even the compiled form of applications to different computing environments. The greater portability improves application longevity. Assembly Language 3GLs 1s and 0s Level of Abstraction 8 Chapter 1
- 38. Figure 1.4 Operating systems narrowed the abstraction gap. Enterprise-Centric Computing Over time the expectations of the degree of automation that computing could achieve continued to increase. It was no longer enough to have islands of automation within the enterprise. The various islands had overlapping func- tionality that duplicated information and applied scarce resources to solve similar problems multiple times. It became necessary to integrate the islands across the enterprise. Component-Based Development Component-Based Development (CBD) draws on lessons learned from indus- trial production processes, promoting a world where applications are assem- bled from interchangeable components. Componentization moves the production process away from reinventing the same solution in different applications, thus improving productivity and decreasing the cost of production. Componentization also tends to improve quality because it isolates functionality, allowing a team to debug and upgrade the functionality in one place. Machine Code //3GL Source Code ... ... ... Machine Code with Operating System Level of Abstraction Compiler Pressure and Progress: How We Arrived at This Point 9
- 39. There isn’t complete agreement in the software industry on the exact defini- tion of component, but usually the term refers to a software module that can be packaged in compiled form so that it can be independently deployed as part of applications or assembled into larger components. In manufacturing industries, manufacturers of finished products produce required components or purchase them from a third party. The ability to use standardized components in different products was one of the prime drivers of the industrial revolution. CBD, which is still maturing, presages another kind of industrial revolution, one that applies to the production of software. Large companies can afford to build some components themselves while purchasing some from component vendors, while smaller companies are more apt to purchase all or most of the components they use. A detailed discussion of CBD is beyond the scope of this book. An important book by Peter Herzum and Oliver Sims, entitled Business Component Factory,2 defines many important CBD concepts that I leverage in this book. I refer to their approach as Herzum-Sims. Design Patterns The concept of design patterns, which is also a key element of industrial pro- duction processes, has made an important contribution to improving software development productivity and quality. Programmers can reuse common design patterns that others have thought through and validated. Generic reusable patterns have been published3 as well as patterns specific to certain platforms such as Java 2 Platform Enterprise Edition (J2EE).4 For example, the J2EE BluePrints Value Object pattern5 supports efficient information exchange with distributed components. Imagine a distributed component that has multiple attributes including the customer ID, first name, last name, address, Social Security number, and so on. Because remote invoca- tion over a network is expensive, it’s inefficient to simply provide remote get and set operations for each property. The Value Object pattern uses a Value Object that contains get and set operations for each attribute and a façade object that provides a remote operation to get a Value Object, thus making it possible to retrieve the values of all of the properties with one remote call. The façade object also provides a remote operation to set—that is, to pass in—a Value Object, thus making it possible to set the values of all of the properties with one remote call (see Figure 1.5). 10 Chapter 1 2 [HS 2000] 3 [GHJV 1995] 4 [ACM 2001] 5 [JVO]
- 40. Figure 1.5 Using the Value Object design pattern to set attributes. Distributed Computing The earliest computers could run only a single job at a time, with any given job single-handedly controlling all of the resources of the computer. Soon multi- tasking operating systems were invented that allowed multiple jobs to run concurrently, each job running in a separate partition. These partitions evolved to provide each job with the illusion that it controlled a whole logical com- puter, a precursor to the virtual machine notion described earlier. This allowed many programs to time-share expensive hardware resources cost-effectively, without generating direct conflicts. A related approach, multiuser computing, allowed the computer to simultaneously control many input-output devices, and to manage the interaction of such devices with the time-sharing programs. Initially, the management of multitasking and multiuser configurations, no matter how complex or physically distributed, was under the total control of a single operating system on a central computer—the master—while all other processing nodes acted as slaves. However, over time it became clear that much of this processing could be off-loaded to satellite processors closer to the user, allowing for a more efficient use of computing resources and communication bandwidth. This approach, generally called distributed computing, became even more attractive with the advent of the personal computer, which brought cheap processing power right to the desktop of the user. A particular form of distributed computing called client-server computing allowed the central computer to act as a server to a PC client. Most early client-server systems perpetuated the master-slave relationship, with the server acting as master, and the PC as a very smart slave terminal. Over time, client- server computing has gradually been evolving towards a more peer-to-peer Client ‚ ‚ 1. Client sets attribute values on value object via local invocations 2. Client passes value object to facade object via remote invocation 1. Local Invocations 2. Remote Invocation Facade Object Value Object Pressure and Progress: How We Arrived at This Point 11
- 41. paradigm, allowing any node to act as either a client or server, depending on the context. Middleware: Raising the Platform Abstraction Level Initially, distributed computing of all kinds was mostly handled on a propri- etary or custom basis, using private messaging systems to communicate between processors over low-level network protocols. Gradually, many of these proprietary systems were replaced by general-purpose systems gener- ally known as middleware, so named because it sat in the middle, transparently connecting a variety of different platforms and operating systems. Initially, middleware was viewed as just a way to generalize communica- tions at a logical level a bit above low-level network protocols, a system totally subservient to the operating systems and applications running on the plat- forms it connected. However, it soon became clear that middleware could also take over many of the functions of coordinating the activities among proces- sors that previously had to be handled ad hoc by each application. As distrib- uted computing has become more important, especially with the advent of the Internet, middleware has gradually been assuming the role of a distributed operating system that controls many of the activities of the computers it con- nects. As such, it now provides a computing abstraction level well above that of traditional operating systems. CORBA, J2EE, .NET, and message-oriented middleware (MOM) are impor- tant examples of middleware platforms that provide services more powerful than those of any particular computer’s operating system. Middleware makes it possible for application programmers to concentrate more on business logic and less on the details of how to provide capabilities such as messaging, trans- action control, security, and so on. Two important ways that applications leverage middleware are: Invoking services directly via middleware APIs. For example, the Java Authentication and Authorization Service provides services that applica- tions can invoke to authenticate a user. Using code generators that middleware platforms provide. For example, CORBA products generate code from declarations of object interfaces expressed in Interface Definition Language (IDL). The generated code supports distribution but does not constitute complete applications. Some middleware supports component-based development by providing an infrastructure and development approach for producing components. Enterprise Java Beans (EJB), .NET, and the CORBA Component Model fall into this category and specifically support developing distributed components. 12 Chapter 1
- 42. Middleware: Raising the Programming Abstraction Level Some middleware has an additional function, namely to provide services that are not dependent on any particular operating system or programming lan- guage. Indeed this was one of the purposes of CORBA. For example, the CORBA Concurrency Service provides an API that appli- cations can invoke in order to obtain and release a lock on a resource. The Con- currency Service is not more powerful than similar services that operating systems supply, but it can be implemented over a variety of operating systems. Applications that use the Concurrency Service are more portable—and thus potentially have greater longevity—than ones that use operating-system- specific concurrency services. CORBA provides a measure of programming language independence by allowing two programs written in different 3GLs, such as Java and C++, to communicate with each other in a well-defined manner. The degree of inter- operability thus achieved also tends to improve longevity because it lowers the likelihood that an object developed in one language will have to be rewrit- ten in order to function in an environment dominated by objects developed in other languages. By raising the level of abstraction above the 3GL and operating system, CORBA made a modest but tangible improvement in the longevity variable. Microsoft’s COM middleware also provided a measure of language indepen- dence via its own interface definition language, Microsoft IDL, but it was not operating-system-independent. Declarative Specification Declarative specification involves programming a system by setting the values of properties. It contrasts with imperative specification, which involves pro- gramming a system via sequential, procedural instructions. Declarative programming improves productivity and quality because it is another form of reuse of preprogrammed, prevalidated logic. It has been in use for some time to reduce the labor intensiveness of producing database systems and graphical user interfaces (GUIs). Sophisticated database systems are an integral part of enterprise computing. When we need a new database, we no longer code all of the logic of the data- base imperatively. Instead, we declaratively describe the formats of the various records. The database system uses these declarations to manage the database, allowing us to fine-tune the database via stored procedures and triggers. Similarly, there was a time when a programmer had to code a graphical user interface (GUI) dialog entirely via laborious procedural instructions. Tools came along that allowed the programmer to simply draw a picture of the Pressure and Progress: How We Arrived at This Point 13
- 43. dialog, whereupon the tool would generate the bulk of the code for displaying and managing the dialog, with the programmer enhancing the generated code to produce the finished product. The tools for drawing the GUIs were called WYSIWYG (What You See Is What You Get) editors. With EJB, .NET, and the CORBA Component Model, a descriptor contains declarations of various properties of a component. The middleware acts in accordance with the property declarations. For example, in order for a compo- nent to support ACID6 transactions, a programmer need only declare such support in the descriptor, rather than write a set of procedural instructions to support transactional behavior. The middleware takes care of the rest. We can classify two basic modes for processing declarations: Code generation. In this mode, the declarations drive a 3GL code generator. GUI development environments that generate code from a WYSIWYG declaration of GUI properties are an example. Runtime interpretation. In this mode, precompiled, predeployed executable code interprets the declarations at runtime. For example, a database engine does not generate new 3GL code when handed a new declarative data model. Instead, the database engine more or less interprets the model at runtime. Enterprise Architecture and Separation of Concerns Software architecture seeks to organize complex systems by separating con- cerns. Separating concerns tends to localize changes to one aspect of a system. When changes to one aspect do impact other aspects, separation of concerns makes it easier to trace the impact. Separating concerns tends to have a positive effect on the viability variables. The localization of changes makes systems less brittle and thus improves their longevity. Once an architecture and a supporting infrastructure are in place, such localization also improves productivity because change can be effected more rapidly. Traceability tends to improve quality. Multitiered architecture is one of the most well-known and widely accepted architectural approaches for distributed enterprise systems. Nevertheless, there is some variance in the industry with regard to the number of tiers, and the names and roles of the tiers. Since I use the concepts of multitiered archi- tecture later in the book, it’s worth spelling out the concepts and terminology that I employ. 14 Chapter 1 6 ACID transactions are atomic, consistent, isolated, and durable. See [GR 1993] for a definitive work on the subject.
- 44. As discussed above, corporate computing systems were originally located entirely on centralized mainframe computers. The terminals on users’ desk- tops were dumb slaves; that is, they had only the minimal processing power necessary to support display and entry functions (see Figure 1.6), under the strict control of the central master. Client-server architects separated concerns by relegating mainframes to database management while shifting display of the data—and business logic using the data—to client PCs, as illustrated by Figure 1.7. Local servers con- nected to groups of PCs via LANs held client-side code files and even some databases that were special to the concerns of local groups. The industry began moving from two-tier client-server architecture to three- tier architecture because it recognized that programmers were coding similar business logic in multiple clients. For example, consider a client-server order entry system in which the client calls to a back-end order, inventory, and gen- eral ledger database. When the client software completes an order, it executes the following steps: 1. Add order record to the order table. 2. Relieve inventory table for the inventory items ordered. 3. Post credits to payables accounts in the general ledger table. 4. Post debits to inventory accounts in the general ledger table. Figure 1.6 One-tier architecture—all processing on centralized mainframe. Dumb Terminal Mainframe Database and Business Logic A B Means A accesses B Pressure and Progress: How We Arrived at This Point 15
- 45. Figure 1.7 Two-tier architecture—some processing off-loaded to client. Gradually the industry realized that it was inefficient to program this kind of logic over and over again for the same database tables in many different client software modules. The inefficiency was due to a failure to separate the concerns of business logic and user presentation. Business logic needed to be encapsulated so many client modules could reuse it for various business use cases. Architects started creating a new tier between the database and the client that encapsulated this kind of business logic. They called this layer by various names, including business tier, enterprise tier, and middle tier, or mid tier for short. The other tiers were called the client tier or front end and the database tier or back end. Thus, while two-tier architecture moved business logic from the mainframe to the client, three-tier moved business logic from the client to the mid tier (see Figure 1.8). Tier separation is logical separation, not necessarily physical separation. It might make sense tactically in some cases to push middle-tier objects and com- ponents to client PCs for performance reasons. However, it became increas- ingly typical to place the middle tier on a separate server machine or set of machines. The advent of the Web solidified this trend because the Web demands that all logic except the basics of user presentation be off-loaded to a remote server. Client Workstation PC CLIENT TIER User Presentation and Business Logic A B Means A accesses B SERVER TIER Database Management Mainframe DBs 16 Chapter 1 T E A M F L Y Team-Fly®
- 46. Figure 1.8 Three-tier architecture. The thin client that thus became de rigueur for Web-based Internet and intranet applications spawned a variation of three-tier architecture in which the presentation facilities of the client machine were limited to a Web browser. Some of the user interaction and presentation facilities ran on remote Web servers, which dynamically generated HTML and sent it to the client; in that sense, Web servers spanned the client tier and mid tier, as illustrated by Figure 1.9. Well-architected systems carefully separated the Web server’s GUI- oriented facilities from the mid tier’s business logic, so that many user scenarios could use the business logic. Three-tier architecture’s concept of the database tier also evolved to include various enterprise information servers that are not mainframe-based. Client Workstation PC CLIENT TIER (a.k.a. Front End) User Presentation A B Means A accesses B ENTERPRISE TIER (a.k.a. Mid Tier) Encapsulated Business Logic Servers DATABASE TIER (a.k.a. Back End) Mainframe DBs DBs on other servers Pressure and Progress: How We Arrived at This Point 17
- 47. Figure 1.9 Three-tier architecture—thin client. Three-tier architecture was a significant improvement over two-tier. How- ever, architects and developers began to recognize that it had a limitation, namely its failure to separate business logic that involves interaction with the end user from business logic that is independent of user interaction. Consider, for example, our order/inventory system now converted to three- tier architecture. The logic of interaction with the end user for one line item of an order might be: 1. Ask user to specify item desired. 2. Access database to get availability and price. 3. If unavailable, tell user. 4. If available, show user the price and give user the option to accept or reject. 5. If user accepts, call database to add a line item to the order. Client Workstation CLIENT TIER User Presentation A B Means A accesses B ENTERPRISE TIER Encapsulated Business Logic Servers DATABASE TIER Mainframe DBs DBs on other servers Web Servers (Including Servlets) Internet or Intranet 18 Chapter 1
- 48. Through the lessons of experience, architects began to realize that systems would be more scalable if the business logic that involves user interaction were separated from other business logic. Thus the mid tier was split into two tiers that separated these concerns: the workspace tier and the enterprise tier. The workspace tier is responsible for executing the logic of the pattern of inter- action with the user. The interaction logic accesses the enterprise tier rather than going directly to the database. Oliver Sims has been advocating four-tier architecture for the better part of a decade.7 Herzum-Sims calls the four tiers user tier, workspace tier, enterprise tier, and resource tier, as Figure 1.10 illustrates. The figure also points out alter- nate names that some practitioners use for the tiers. Figure 1.10 Four-tier enterprise architecture. A B Means A accesses B USER TIER (a.k.a. Client Tier) User Presentation WORKSPACE TIER (a.k.a. Interaction Tier) User Interaction Logic Servers ENTERPRISE TIER (a.k.a. Business Tier) Encapsulated Business Logic Servers RESOURCE TIER (a.k.a. Integration Tier) Mainframe DBs DBs on other servers Resource Adapters (e.g. Object-Relational Mappings) Pressure and Progress: How We Arrived at This Point 19 7 See [HS 2000] for his most recent work on this subject.
- 49. The Herzum-Sims notion of a business component is a component com- posed of smaller components that are specific to individual tiers. A business component thus spans one or more tiers and can cover presentation, inter- action, business logic, and data. An order entry component, for example, contains components that handle presentation, interaction, and so on for order entry. Note that the Herzum-Sims resource tier is not quite the same as the data- base tier from three-tier systems. Instead, it represents the logic that provides the bridge between the enterprise tier and databases. Business components interact with but don’t include databases, which is why Herzum-Sims does not define a tier to encompass databases. However, some enterprise architec- tures define the resource tier as including databases, while calling the tier that contains adapters the integration tier. Some practitioners define distinct tiers that separate client-side user interaction logic from server-side interaction logic handled by technology such as Java servlets. In any case, multitiered enterprise architecture plays an important role in managing the complexity of distributed enterprise systems. The separation of different concerns in logical tiers promotes the reuse of data and logic and thus improves development productivity and quality. There is more to enterprise architecture than organization by logical dis- tribution tiers. For example, enterprise architecture also leverages middle- ware, layering the various tiers over middleware so as to minimize the degree to which basic functionality required by the tiers has to be pro- grammed over and over again. There is middleware that supports GUI development, such as windows frameworks. There is middleware that sup- ports the development of the workspace tier, such as J2EE servlets and analogous .NET technology. There is middleware that supports ACID trans- actions in the enterprise tier, such as the Java Transaction Service and .NET transaction support. There is also middleware that supports object-relational mapping for the resource tier. Layering the tiers over middleware separates concerns into (1) aspects of the system that application programmers must deal with and (2) aspects that infrastructure handles. Oliver Sims uses the analogy of a water line to describe this separation of concerns, designating the aspects of a system that the pro- grammer sees as above the line and aspects that the middleware infrastructure handles as below the line. In Figure 1.11 you can see that middleware implementations that do much heavy lifting for the application programmer are below the line, while only the APIs to middleware services and middleware configuration languages surface above the line. 3GLs have aspects above and aspects below the line. Figure 1.11 does not exhaustively categorize all of the elements of an enterprise system along the water line. Other development tools have above- and below-the-line aspects, and development methodologies do as well. 20 Chapter 1
- 50. Figure 1.11 Above and below the line. The notion of viewpoints is another enterprise computing concept that sup- ports the idea of separation of concerns. Aviewpoint is a projection of a system that filters out aspects of the system not relevant to that viewpoint. For exam- ple, we could define an application engineer’s viewpoint of a system as reveal- ing only the above-the-line aspects of the system. An infrastructure engineer’s viewpoint, on the other hand, reveals the below-the-line aspects. The Interna- tional Organization for Standardization’s (ISO) RM-ODP makes a contribution to enterprise architecture by exploring the nature and ramifications of view- points. Each viewpoint is an abstraction of the system. RM-ODP defines abstraction as the suppression of irrelevant detail.8 Enterprise architecture also defines the separation of entity and process, defines levels of granularity of the various components of a system, and more.9 Multitiered architecture, granularity management, middleware layering, and so on are a common basis for enterprise architecture that most companies can adopt. However, it is always necessary for a business to customize these common contours to meet its own unique requirements. Enterprise Application Integration (EAI) Enterprise architecture makes it possible to design enterprise systems that by nature are well integrated. However, legacy systems and packaged applica- tions are part of the IT landscape that cannot be ignored. By using enterprise architecture to develop new software, you can avoid creating more discon- nected islands of automation, but existing islands need to be brought into the enterprise architecture as well. Middleware Service APIs "Above the Line" Middleware Implementations 3GL Languages Compiler Implementations "Below the Line" Applications Middleware Configuration Languages e.g., EJB Deployment Descriptor DTD 3GL Languages • Editors • Programmatic and user interfaces to compilers Pressure and Progress: How We Arrived at This Point 21 8 [RMODP] 9 For an excellent treatment of enterprise architecture see [HRG 2000].
- 51. EAI is an approach to knitting preexisting islands of automation together within enterprise systems. Quite a few IT shops today are applying more resources to EAI than to development of new enterprise applications and components. EAI adds the notion of application adapters to the resource tier. Application adapters wrap functionality islands such as packaged applications and other legacy systems. EAI systems support event-based communication among adapters, which promotes loose coupling among the disparate islands. Enter- prise architects understand that loose coupling is the preferred way to inte- grate parts that were not designed to work with each other.10 Therefore, most EAI systems work by enabling disparate modules to send asynchronous messages when they complete various tasks and to handle mes- sages sent by other modules that they receive from an event queue. Messages often consist of data that needs to be transformed, filtered, and/or routed to multiple destinations. Figure 1.12 depicts the addition of adapters to the resource tier and the management of messages that flow among them. There are a number of messaging-oriented middleware (MOM) platforms, including IBM’s WebSphere MQ Integrator (formerly called MQSeries), Microsoft’s MSMQ, and the Java Messaging Service (JMS). Design by Contract Design by Contract (DBC) is an approach to building reliable software that focuses on making the contract of a software module explicit and formal. It thus directly addresses the quality variable in the viability equation. E. W. Dijkstra formulated the basic foundations of Design by Contract in the 1970s.11 Later advocates, such as Bertrand Meyer12 and Haim Kilov,13 built upon his work. Meyer’s work laid the foundation for the Eiffel language. DBC is based on a recognition that formal contract expression should go beyond merely the expression of the signatures of the operations that a mod- ule supports. Design by Contract involves writing two kinds of formal constraints: Pre-conditions and post-conditions. Pre-conditions and post-conditions are assertions about operations. A pre-condition for an operation must be true when the operation begins executing. A post-condition must be true when the operation is finished executing.14 22 Chapter 1 10 In certain circumstances loose coupling can also be useful for integrating less disparate parts. 11 [DIJK 1976] 12 [MEYER 1997] 13 [KR 1994] 14 Some Design by Contract practitioners argue that it’s more correct to say that if a pre- or post- condition isn’t satisfied, then the behavior of the operation is undefined, rather than to say that the conditions must not be violated.
- 52. Invariants. An invariant is an assertion about the state of a system that must always be true, except during the execution of an operation. In a sense, an invariant can be viewed as a universal pre- and post-condition for all operations. Invariants are generally stated as rules about classes or interfaces. Figure 1.12 Multitiered architecture with EAI adapters and message management. Mainframe DBs Other Legacy Systems Packaged Applications DBs on other servers A B Means A accesses B USER TIER (a.k.a. Client Tier) User Presentation WORKSPACE TIER (a.k.a. Interaction Tier) User Interaction Logic Servers ENTERPRISE TIER (a.k.a. Business Tier) Encapsulated Business Logic Servers RESOURCE TIER (a.k.a. Integration Tier) Resource Adapters (e.g., Object-Relational Mappings) Application adapters, message routers, filters, and transformers Pressure and Progress: How We Arrived at This Point 23
- 53. For example, consider the following Java interfaces: Interface Customer { String id; ... } interface Account { double balance; Customer customer; ... } interface CheckingAccount extends Account { double minBalance; ... } interface SavingsAccount extends Account { ... } interface FundsTransfer { transferFromChecking(CheckingAccount fromAcct, SavingsAccount toAcct, double amount); ... } An invariant for the CheckingAccount interface might be expressed infor- mally in English as “the balance may not go below the minimum balance.” A formal expression of this invariant would be: balance >= minBalance The formal invariant is in the form of a Boolean assertion written in some unspecified formal expression language. The ability to formally express and evaluate invariants is built into the Eiffel language. However, mainstream 3GL, 4GL, and interface definition languages do not support formal expres- sion of invariants. Now consider the FundsTransfer interface, which has an operation that moves a specified amount of money from a checking account to a savings account. An example of an informally expressed pre-condition for this 24 Chapter 1
- 54. operation would be “the checking and savings accounts must have the same customer.” It could be expressed formally as: fromAcct.customer = toAcct.Customer An informal post-condition for the operation is that the balance of the sav- ings account is greater than its previous balance by the amount of the transfer. A formal expression of the post-condition might be: toAcct.balance = toAcct.balance + amount Where toAcct.balance on the left side of the equal sign refers to the bal- ance after the operation executes, while on the right side it refers to the balance before it executes. Mainstream languages do not support pre- and post-conditions any more than they support invariants. Therefore, most development organizations view invariants and pre- and post-conditions strictly as elements of design. Nevertheless, adherence to Design by Contract can have a significant impact on software quality. Other Enterprise-Centric Technologies 4GLs such as Visual Basic are very popular. They provide higher-level envi- ronments for programming database-oriented functions and user interfaces. In order to provide this leverage, they restrict the range of problems that can be solved by the programmer. XML supports interoperability between programs written in different 3GLs, so, like CORBA, it facilitates distribution. Pressures on Enterprise-Centric Computing Enterprise-centric computing advances made it possible to build new kinds of applications and to create true enterprise systems that are more than an amal- gam of disconnected parts. However, the demands on enterprise software have continued to intensify (see Figure 1.13). In the era that is now drawing to a close, companies expected enterprise software to manage information inside the business and to support end users on fairly uniform display devices. Now enterprise software is being pushed to also manage customer-to-business and business-to-business transactions over the Internet, accompanied by a wide array of end-user systems and devices, including fat clients, Web clients, telephone keypads, and wireless handhelds. Pressure and Progress: How We Arrived at This Point 25
- 55. Other documents randomly have different content
- 56. hän ystävänsä Sprengtportin neuvosta lähtenyt itse persoonallisesti Tukholmaan. »Hallitusherroilla on siellä tärkeämpääkin tehtävää kuin muistaa meitä maan matosia täällä Suomen puolella», jatkoi Löfving. »Siellä käy muuten kaikki entiseen tapaan. Hatut taistelevat myssyjä ja myssyt hattuja vastaan ja vastapuoluelaisen kunnia ei siellä paljon paina. Myssyihin sitä mekin luimme itsemme takavuosina, he kun vastustivat sen järjettömän viime sodan alkamista, mutta tällä matkallani tulin huomaamaan, että samanlaisia juonimaakareita ne ovat molemmat, niin että tästä puolin minä en aio pitää suden paremmin kuin lampaankaan puolta.» »Hm, hm, saattaapa niin olla», hymähteli Sprengtport, siivilöiden savuja tupakasta kellastuneiden viiksiensä läpi. »Mutta etkö kääntynyt itse hänen majesteettinsa puoleen?» »Mitäpä se olisi hyödyttänyt, sillä hänen majesteettinsa on kuningas ilman valtaa. Säätyjen riidellessä ja valtaneuvosten hallitessa ei hän tee muuta kuin syö ja lihoo. Tukholmalaiset kertoivat hänen kuluttavan päiviään siten, että hän aamupuolen päivää istuu ikkunan ääressä ja katsoo torille. Siihen kyllästyttyään siirtyy hän peremmäksi huonetta, ja kun yksi tuoli liiaksi lämpenee, muuttaa hän toiselle tuolille. Siihen menee häneltä muu osa päivää. Sitten hänellä on ne omat naisvehkeensä. Viimeksi kuuluu hän pitäneen yhteyttä muutaman huonomaineisen kamarineitsyen kanssa ja sanoivat kreivitär Tauben sen johdosta surreen itsensä kuoliaaksi.» Löfving ruiskautti pitkän syljen uunin alle ja irvisti halveksivasti.
- 57. »Onpas sitä, onpas sitä», sanaili Sprengtport harvakseen. »Suuresti ovat ajat muuttuneet siitä kun me olimme nuoria.» He maistoivat olutta, jota vanha palvelijatar oli tuonut, sytyttivät jälleen pitkävartiset piippunsa ja savurenkaita puhallellen keinahtelivat hetken ääneti. »Suuresti ovat muuttuneet ajat ja olot, niin ettei kaikiste tahtoisi silmiään uskoa», tarttui Löfving ystävänsä sanoihin. »Kuinka mahtava olikaan Ruotsi meidän lapsuutemme aikana ja mitä siitä on nyt enää jälellä! Ainoastaan varjo entisestä. Kuinka siellä nyt esimerkiksi peljätään Venäjää, jota ennen kohdeltiin ylimielisellä halveksunnalla. Sain muun muassa kuulla, että hallitus, ja varsinkin kruununprinssin puolue, sillä sellainenkin siellä nykyään on entisten lisäksi, on liittoaikeissa lähennellyt Preussin kuningasta, mutta kun keisarinna Elisabet siitä tiedon saatuaan oli lausunut paheksumisensa ja uhannut uudella sodalla, oli hallitus heti pelästyneenä peräytynyt aikomuksestaan.» »Niin, niin, kovin on ränsistynyt Ruotsin leijona», myönsi Sprengtport, »eikä se kykene enää kauan Suomea käpälissään pitelemään. Kaksi kaistaletta on kotka jo riistänyt isänmaastamme ja kolmannella kertaa menee se kokonaan.» »Usein olen muistanut niitä sanoja, jotka lausuit siellä Myllykylän haudalla», virkkoi Löfving tovin kuluttua. »Ja yhä enemmän on minulle alkanut sen jälkeen selvitä, että Suomi kulkee uutta tulevaisuutta kohti. Mikä se sitten tulleekin olemaan, mutta yhteyttä Ruotsin kanssa ei voi enää kovin pitkälle jatkua.» »Miksi eivät suomalaiset valitse itselleen omaa kuningasta?» kuului samassa kirkkaalla äänellä lausuttu kysymys sohvan nurkasta.
- 58. Hämmästyneinä kääntyivät molemmat sotavanhukset puhujaa kohti. Heitä kohtasivat Sprengtportin nuorimman pojan, pienen Yrjö Maunun kirkkaat ja totiset silmät. Hän oli edellisen keskustelun aikana hiipinyt huoneeseen ja sijottunut isän nahkasohvalle, kummankaan kiinnittämättä häneen mitään huomiota. »Aijai, sinä pieni politikoitsija, mitä vaarallisia oppeja sinä julistat!» torui isä hellästi. »Tule tänne nyt tervehtimään setä Löfvingiä ja sitten saat mennä heti nukkumaan rangaistukseksi siitä, että sekaannut vanhempain keskusteluun.» Kun Yrjö Maunu oli lähtenyt huoneesta, virkkoi Löfving: »Siinä me sen nyt kuulimme. Onhan kirjotettu, että lasten ja imeväisten suusta olet sinä totuuden valmistanut.» »Sinä, veikko, olet aina sangen herkkä kaikellaisille ennustuksille ja unennäöille», naurahti Sprengtport. »Mutta joka tapauksessa saa Yrjö Maunu, jos hänellä elämän päiviä riittää, nähdä ja kokea paljon sellaista, josta meillä voi olla ainoastaan omat aavistuksemme. Niin, niin, tulevan sukupolven tehtäväksi jää uuden Suomen luominen. Me olemme jo tehtävämme tehneet ja saamme rauhassa odottaa viimeistä lähtökäskyä. Ja nyt shakkilaudan ääreen.» He siirsivät tuolinsa lähemmäs pöytää ja alkoivat syysillan hämärtyessä asetella nappuloita paikoilleen. Siteet katkeavat
- 59. »Hyvät herrat, jos minä olisin alusta alkain saanut olla ylimpänä määrääjänä, niin me olisimme tällä hetkellä vielä koreasti Suomen mantereella, niin, sen eteläosassa, ja Ruotsi olisi vielä pitkiksi ajoiksi pysyttänyt Suomen yhteydessään.» Nämä sanat lausui maaliskuun 16 päivän iltana v. 1809 kenraalimajuri v. Döbeln kävellen tuimasti edestakaisin Eckeröön pappilan salissa. Hän viskasi hansikkaansa vihaisesti pöydälle, kohensi sidettä otsallaan ja alahuuli yrmysti esiin työntyneenä jatkoi kävelyään. Hänen kuulijansa, esikuntapäällikkö eversti Schultzenheim sekä armeijaosaston intendentti eversti Fock hätkähtivät tästä odottamattomasta purkauksesta ja kumpikin etsi turhaan soveliaita sanoja vastaukseksi tähän päällikkönsä omituiseen ja arkaluontoiseen väitteeseen. Viime päivinä olivat tapaukset seuranneet nopeasti toisiaan. Döbeln oli pienine armeijoineen varustautunut lujaan puolustusasemaan Ahvenan mantereelle, jota venäläisten uusi ylipäällikkö, kenraali Knorring, mukanaan itse sotaministeri Araktshejeff, läheni suurine valtausarmeijoineen. Heidän tarkotuksenaan oli marssia suoraa päätä Tukholmaan ja pakottaa siellä Ruotsi rauhantekoon. Neljä päivää sitten oli v. Döbeln, kuultuaan venäläisten lähenevän kolmelta suunnalta, pitänyt pääkortteerissaan Jomalassa tulisen puheen joukoilleen, kehottaen heitä puolustautumaan viimeiseen saakka. Mutta pari päivää sen jälkeen, kun kaikki oli jo valmiina taistelua varten, oli hän saanut Tukholmasta herttua Kaarlen ja Adlercreutzin allekirjottaman kirjeen, jossa ilmotettiin, että kuningas oli erotettu valtaistuimelta sekä käskettiin hänen viipymättä peräyttää joukkonsa Ruotsin mantereelle. Tästä tiedonannosta oli hän silmittömästi suuttunut, sillä niin kykenemättömäksi hallitusta hoitamaan kuin hän tiesikin
- 60. kuninkaan, oli hän kuitenkin saattanut toivoa sodan pitkittymistä sekä jotakin onnellista käännettä tapausten kulussa niin kauan kuin itsepäinen Kustaa Aadolf oli hallituksen ohjaksissa. Mutta nyt seuraisi varmasti pikainen ja tölppö rauha sekä samalla Suomen luovuttaminen Venäjälle. Tulistuksissaan tästä odottamattomasta asiain käänteestä oli hän lähettänyt Tukholmaan eronpyynnin päällikkyydestä. Mutta sitä odottaessaan täytyi hänen kumminkin totella saamiaan määräyksiä. Niin katkeraa kuin hänestä olikin miekan lyönnittä jättää tämä viimeinen kolkka Suomen suuriruhtinaskunnasta, ryhtyi hän kuitenkin järjestämään peräytymisretkeä. Joukot saivat käskyn kokoontua Eckerööhön, josta sitten lähdettäisiin tuolle nelipenikulmaiselle taipaleelle Ahvenanmeren yli. Mutta venäläiset olivat tällä välin ehtineet uhkaavan lähelle. Suurena puoliympyränä olivat ne jo astuneet Ahvenan mantereelle ja Döbelnin pieni armeija oli vaarassa milloin hyvänsä joutua saarroksiin. Näytti miltei mahdottomalta ehtiä kuormasto, tykistö ja sairaat kuljettaa Ruotsin puolelle. Tässä tukalassa asemassa päätti Döbeln käyttää kieltään, kun hänen ei kerta oltu sallittu miekalla asioitaan hoitaa. Niinpä oli hän tänään aamusella noussut satulaan ja yhdessä everstiluutnantti Lagerbringin kanssa ratsastanut Klemetsbyyhyn, missä oli venäläisten pääkortteeri, saadakseen aikaan muutaman päivän aselevon. Hän olikin onnistunut taivuttamaan kenraali Knorringin kolmen päivän aselepoon, jonka kuluessa venäläiset pysyisivät alallaan, mutta Döbelnin joukkoineen tuli jättää Ahvenanmaa. Mutta juuri kun sopimus piti allekirjotettamaan, saapui paikalle sotaministeri Araktshejeff, joka keskustelujen aikana oli ollut ulkona
- 61. joukkoja tarkastamassa. Röyhkeästi hän purki tehdyn sopimuksen ja vaati Döbelniä joukkoineen antautumaan vangiksi. Vimmastuneena tällaisesta häikäilemättömyydestä joutui Döbeln kiivaaseen sananvaihtoon venäläisten kenraalien kanssa ja lopuksi, äärimmilleen kiihtyneenä, löi kätensä miekanhuotralle ja painaen hatun päähänsä lähti muitta mutkitta pois. Pihalla satulaan noustessaan oli hänellä kuitenkin malttia pyytää Lagerbringia, jolla oli sujuva ja kohtelias käytös, jäämään venäläisten pääkortteriin sekä koettamaan kaikenlaisilla keskusteluilla viivyttää venäläisten etenemistä. Hevonen vaahdossa oli hän itse äsken saapunut Eckerööhön sekä jakanut käskyjä liikkeelle lähdöstä. Kun hän sen jälkeen astui pappilan saliin, näkyi hänen kasvoillaan ja kaikissa eleissään vielä ankara kiihtymys, minkä syyksi kumpikin saapuvilla oleva upseeri mielessään luki nuo hänen alussa mainitut kiivaat sanansa. Lyhyin ja tuimin askelin edestakaisin kävellen sekä kiivaasti heiluttaen vasenta kättään, jatkoi hän hetken kuluttua: »Mutta kaikkihan on alusta aikain käynyt päin mäntyyn! Silloin tällöin joku loistava yritys, joka kuitenkin kohta epäröimisellä ja saamattomuudella pilattiin. Ja niin paljon miehuutta ja kuntoa kuin Suomen sotajoukossa olikin! Mutta nyt se on kaikki tuhlattu hukkaan. Kaikki mainiot tilaisuudet ja kaikki toimintahalusta palavat voimat jätetty käyttämättä. Saamattomuutta, epäröimistä, hitautta ja — niin, suoranaista anteeksiantamatonta tuhmuutta ylimmässä johdossa! Kas, siinä siemenet niihin hedelmiin, joita me nyt päivä päivältä saamme poimia. Mutta niinhän se on aina ollut, että milloin kohtalo on nähnyt hyväksi ahdistaa jonkun valtakunnan vararikkoon, silloin se on asettanut aasit valtapaikoille.»
- 62. Hän pysähtyi, irrotti siteen otsaltaan ja painoi sormin ohimoaan, jossa puoliavoimena punotti Porrassalmella saatu arpi. Hänen terävissä silmissään hehkui kuumeenomainen tuli, kun hän matalammalla äänellä, ikäänkuin itsekseen puhuen, jatkoi: »Ja meillä ovat asioita johtaneet juuri sellaiset aasit, joiden korvien läpi eivät edes toisten antamat järjelliset neuvot ole voineet tietä löytää. Mitä! Emmekö vielä yhdennellätoista hetkellä olisi yhdellä iskulla voineet muuttaa sodankulkua, jos olisi noudatettu minun ehdotustani siirtää sotanäyttämö rohkealla vedolla Etelä- Suomeen? Minun voittoni jälkeen Juuttaalla se olisi käynyt mainiosti päinsä: Silloin olisi kaksikin tietä Päijänteen seutuville ollut vielä avoinna. Mutta ei! Tuuma oli tietysti aivan liian uskalias. Varovaisuutta! Niin, aasien varovaisuus on oikealla nimellään hitautta ja saamattomuutta. Ja muutoin he ovat minun ehdotuksistani epäilleet aina, että täällä ei kaikki ole muka oikein reilassa.» Döbeln viittasi otsaansa sekä naurahti lyhyesti ja katkerasti. »Mutta miksi kaiken on pitänyt käydä näin?» huudahti hän hetken kuluttua kiihkeästi ja pysähtyi upseerien eteen. »Miksi yksikään kykenevämpi käsi ei ole tarttunut tapausten kulkuun? Miksi ei Viaporissa paremmin kuin maa-armeijassakaan noussut ketään, joka olisi sanonut: ei niin, mutta näin!» »Niin, miksi ei esimerkiksi herra kenraali sitä tehnyt?» uskalsi Schultzenheim hymyillen huomauttaa. »Tepä sen sanoitte!» huudahti Döbeln ja jäi tuijottamaan intendenttiään silmiin. — »Miksi en minä sitä tehnyt, vaikka se lakkaamatta eli mielessäni ja vaikka minä tunsin niin hyvin omat voimani kuin ulkonaiset olosuhteet monta kertaa myötäisiksi
- 63. vallankeikaukselle? Olihan sille hyvä maaperä siinä katkeruudessa, joka jäyti useimpain mieltä armeijassa, kun asiain nähtiin menevän päinvastoin kuin niiden olisi pitänyt. Ja kuitenkaan ei kukaan tehnyt pienintäkään yritystä. Oliko se saamattomuutta? En tiedä, mutta ainakin minut valtasi ratkaisevina hetkinä omituinen raukeemus, aivan kuin jotakin näkymätöntä olisi tullut siihen väliin.» Syntyi pitempi äänettömyys, minkä kestäessä Döbelnin katse levotonna harhaili tyhjyydessä, kuin etsien selitystä sille salaperäiselle, joka oli estänyt häntä ratkaisun hetkinä toimimasta. »Se oli kohtalo», keskeytti vihdoin Schultzenheim hiljaisuuden. »Niin juuri, kohtalo se oli, itse Fatum!» huudahti Döbeln, pyörähti sitten kantapäällään ja jatkoi, äänessään tyyntynyt ja alistuvainen sävy: »Kohtalon vallat olivat päättäneet erottaa Suomen Ruotsista ja siihen me, maan matoset, olemme saaneet tyytyä. Kohtaloa vastaan on itse Bonapartekin voimaton, niin loistava sotapäällikkö kuin hän onkin.» Hetken kuluttua oli Döbelnin äänessä sen tavallinen kylmähkö sävy, kun hän lausui: »Niin, huomenna meidän, viimeisten ruotsalaisten, on jätettävä tämä viimeinen lieve Suomen maata. Sitä ennen meille on kuitenkin suotu yhden yön lepo.» Hän toivotti hyvää yötä ja enempää puhumatta poistui makuuhuoneeseensa. * * * * *
- 64. Kovan lumipyryn ja pakkasen vallitessa lähtivät seuraavana aamuna viimeiset v. Döbelnin joukot hyvässä järjestyksessä marssimaan länttä kohti. Kuormasto ja tykistö olivat jo aikasemmin lähteneet liikkeelle. Itse Döbeln kulki esikuntineen jälkijoukossa.
- 65. *** END OF THE PROJECT GUTENBERG EBOOK AIKOJEN YÖSTÄ: HISTORIALLISIA KERTOMUKSIA IV *** Updated editions will replace the previous one—the old editions will be renamed. Creating the works from print editions not protected by U.S. copyright law means that no one owns a United States copyright in these works, so the Foundation (and you!) can copy and distribute it in the United States without permission and without paying copyright royalties. Special rules, set forth in the General Terms of Use part of this license, apply to copying and distributing Project Gutenberg™ electronic works to protect the PROJECT GUTENBERG™ concept and trademark. Project Gutenberg is a registered trademark, and may not be used if you charge for an eBook, except by following the terms of the trademark license, including paying royalties for use of the Project Gutenberg trademark. If you do not charge anything for copies of this eBook, complying with the trademark license is very easy. You may use this eBook for nearly any purpose such as creation of derivative works, reports, performances and research. Project Gutenberg eBooks may be modified and printed and given away—you may do practically ANYTHING in the United States with eBooks not protected by U.S. copyright law. Redistribution is subject to the trademark license, especially commercial redistribution. START: FULL LICENSE
- 66. THE FULL PROJECT GUTENBERG LICENSE
- 67. PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK To protect the Project Gutenberg™ mission of promoting the free distribution of electronic works, by using or distributing this work (or any other work associated in any way with the phrase “Project Gutenberg”), you agree to comply with all the terms of the Full Project Gutenberg™ License available with this file or online at www.gutenberg.org/license. Section 1. General Terms of Use and Redistributing Project Gutenberg™ electronic works 1.A. By reading or using any part of this Project Gutenberg™ electronic work, you indicate that you have read, understand, agree to and accept all the terms of this license and intellectual property (trademark/copyright) agreement. If you do not agree to abide by all the terms of this agreement, you must cease using and return or destroy all copies of Project Gutenberg™ electronic works in your possession. If you paid a fee for obtaining a copy of or access to a Project Gutenberg™ electronic work and you do not agree to be bound by the terms of this agreement, you may obtain a refund from the person or entity to whom you paid the fee as set forth in paragraph 1.E.8. 1.B. “Project Gutenberg” is a registered trademark. It may only be used on or associated in any way with an electronic work by people who agree to be bound by the terms of this agreement. There are a few things that you can do with most Project Gutenberg™ electronic works even without complying with the full terms of this agreement. See paragraph 1.C below. There are a lot of things you can do with Project Gutenberg™ electronic works if you follow the terms of this agreement and help preserve free future access to Project Gutenberg™ electronic works. See paragraph 1.E below.
- 68. 1.C. The Project Gutenberg Literary Archive Foundation (“the Foundation” or PGLAF), owns a compilation copyright in the collection of Project Gutenberg™ electronic works. Nearly all the individual works in the collection are in the public domain in the United States. If an individual work is unprotected by copyright law in the United States and you are located in the United States, we do not claim a right to prevent you from copying, distributing, performing, displaying or creating derivative works based on the work as long as all references to Project Gutenberg are removed. Of course, we hope that you will support the Project Gutenberg™ mission of promoting free access to electronic works by freely sharing Project Gutenberg™ works in compliance with the terms of this agreement for keeping the Project Gutenberg™ name associated with the work. You can easily comply with the terms of this agreement by keeping this work in the same format with its attached full Project Gutenberg™ License when you share it without charge with others. 1.D. The copyright laws of the place where you are located also govern what you can do with this work. Copyright laws in most countries are in a constant state of change. If you are outside the United States, check the laws of your country in addition to the terms of this agreement before downloading, copying, displaying, performing, distributing or creating derivative works based on this work or any other Project Gutenberg™ work. The Foundation makes no representations concerning the copyright status of any work in any country other than the United States. 1.E. Unless you have removed all references to Project Gutenberg: 1.E.1. The following sentence, with active links to, or other immediate access to, the full Project Gutenberg™ License must appear prominently whenever any copy of a Project Gutenberg™ work (any work on which the phrase “Project Gutenberg” appears, or with which the phrase “Project Gutenberg” is associated) is accessed, displayed, performed, viewed, copied or distributed:
- 69. This eBook is for the use of anyone anywhere in the United States and most other parts of the world at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org. If you are not located in the United States, you will have to check the laws of the country where you are located before using this eBook. 1.E.2. If an individual Project Gutenberg™ electronic work is derived from texts not protected by U.S. copyright law (does not contain a notice indicating that it is posted with permission of the copyright holder), the work can be copied and distributed to anyone in the United States without paying any fees or charges. If you are redistributing or providing access to a work with the phrase “Project Gutenberg” associated with or appearing on the work, you must comply either with the requirements of paragraphs 1.E.1 through 1.E.7 or obtain permission for the use of the work and the Project Gutenberg™ trademark as set forth in paragraphs 1.E.8 or 1.E.9. 1.E.3. If an individual Project Gutenberg™ electronic work is posted with the permission of the copyright holder, your use and distribution must comply with both paragraphs 1.E.1 through 1.E.7 and any additional terms imposed by the copyright holder. Additional terms will be linked to the Project Gutenberg™ License for all works posted with the permission of the copyright holder found at the beginning of this work. 1.E.4. Do not unlink or detach or remove the full Project Gutenberg™ License terms from this work, or any files containing a part of this work or any other work associated with Project Gutenberg™. 1.E.5. Do not copy, display, perform, distribute or redistribute this electronic work, or any part of this electronic work, without prominently displaying the sentence set forth in paragraph 1.E.1
- 70. with active links or immediate access to the full terms of the Project Gutenberg™ License. 1.E.6. You may convert to and distribute this work in any binary, compressed, marked up, nonproprietary or proprietary form, including any word processing or hypertext form. However, if you provide access to or distribute copies of a Project Gutenberg™ work in a format other than “Plain Vanilla ASCII” or other format used in the official version posted on the official Project Gutenberg™ website (www.gutenberg.org), you must, at no additional cost, fee or expense to the user, provide a copy, a means of exporting a copy, or a means of obtaining a copy upon request, of the work in its original “Plain Vanilla ASCII” or other form. Any alternate format must include the full Project Gutenberg™ License as specified in paragraph 1.E.1. 1.E.7. Do not charge a fee for access to, viewing, displaying, performing, copying or distributing any Project Gutenberg™ works unless you comply with paragraph 1.E.8 or 1.E.9. 1.E.8. You may charge a reasonable fee for copies of or providing access to or distributing Project Gutenberg™ electronic works provided that: • You pay a royalty fee of 20% of the gross profits you derive from the use of Project Gutenberg™ works calculated using the method you already use to calculate your applicable taxes. The fee is owed to the owner of the Project Gutenberg™ trademark, but he has agreed to donate royalties under this paragraph to the Project Gutenberg Literary Archive Foundation. Royalty payments must be paid within 60 days following each date on which you prepare (or are legally required to prepare) your periodic tax returns. Royalty payments should be clearly marked as such and sent to the Project Gutenberg Literary Archive Foundation at the address specified in Section 4, “Information
- 71. about donations to the Project Gutenberg Literary Archive Foundation.” • You provide a full refund of any money paid by a user who notifies you in writing (or by e-mail) within 30 days of receipt that s/he does not agree to the terms of the full Project Gutenberg™ License. You must require such a user to return or destroy all copies of the works possessed in a physical medium and discontinue all use of and all access to other copies of Project Gutenberg™ works. • You provide, in accordance with paragraph 1.F.3, a full refund of any money paid for a work or a replacement copy, if a defect in the electronic work is discovered and reported to you within 90 days of receipt of the work. • You comply with all other terms of this agreement for free distribution of Project Gutenberg™ works. 1.E.9. If you wish to charge a fee or distribute a Project Gutenberg™ electronic work or group of works on different terms than are set forth in this agreement, you must obtain permission in writing from the Project Gutenberg Literary Archive Foundation, the manager of the Project Gutenberg™ trademark. Contact the Foundation as set forth in Section 3 below. 1.F. 1.F.1. Project Gutenberg volunteers and employees expend considerable effort to identify, do copyright research on, transcribe and proofread works not protected by U.S. copyright law in creating the Project Gutenberg™ collection. Despite these efforts, Project Gutenberg™ electronic works, and the medium on which they may be stored, may contain “Defects,” such as, but not limited to, incomplete, inaccurate or corrupt data, transcription errors, a copyright or other intellectual property infringement, a defective or
- 72. damaged disk or other medium, a computer virus, or computer codes that damage or cannot be read by your equipment. 1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except for the “Right of Replacement or Refund” described in paragraph 1.F.3, the Project Gutenberg Literary Archive Foundation, the owner of the Project Gutenberg™ trademark, and any other party distributing a Project Gutenberg™ electronic work under this agreement, disclaim all liability to you for damages, costs and expenses, including legal fees. YOU AGREE THAT YOU HAVE NO REMEDIES FOR NEGLIGENCE, STRICT LIABILITY, BREACH OF WARRANTY OR BREACH OF CONTRACT EXCEPT THOSE PROVIDED IN PARAGRAPH 1.F.3. YOU AGREE THAT THE FOUNDATION, THE TRADEMARK OWNER, AND ANY DISTRIBUTOR UNDER THIS AGREEMENT WILL NOT BE LIABLE TO YOU FOR ACTUAL, DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE OR INCIDENTAL DAMAGES EVEN IF YOU GIVE NOTICE OF THE POSSIBILITY OF SUCH DAMAGE. 1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you discover a defect in this electronic work within 90 days of receiving it, you can receive a refund of the money (if any) you paid for it by sending a written explanation to the person you received the work from. If you received the work on a physical medium, you must return the medium with your written explanation. The person or entity that provided you with the defective work may elect to provide a replacement copy in lieu of a refund. If you received the work electronically, the person or entity providing it to you may choose to give you a second opportunity to receive the work electronically in lieu of a refund. If the second copy is also defective, you may demand a refund in writing without further opportunities to fix the problem. 1.F.4. Except for the limited right of replacement or refund set forth in paragraph 1.F.3, this work is provided to you ‘AS-IS’, WITH NO OTHER WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED,
- 73. INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PURPOSE. 1.F.5. Some states do not allow disclaimers of certain implied warranties or the exclusion or limitation of certain types of damages. If any disclaimer or limitation set forth in this agreement violates the law of the state applicable to this agreement, the agreement shall be interpreted to make the maximum disclaimer or limitation permitted by the applicable state law. The invalidity or unenforceability of any provision of this agreement shall not void the remaining provisions. 1.F.6. INDEMNITY - You agree to indemnify and hold the Foundation, the trademark owner, any agent or employee of the Foundation, anyone providing copies of Project Gutenberg™ electronic works in accordance with this agreement, and any volunteers associated with the production, promotion and distribution of Project Gutenberg™ electronic works, harmless from all liability, costs and expenses, including legal fees, that arise directly or indirectly from any of the following which you do or cause to occur: (a) distribution of this or any Project Gutenberg™ work, (b) alteration, modification, or additions or deletions to any Project Gutenberg™ work, and (c) any Defect you cause. Section 2. Information about the Mission of Project Gutenberg™ Project Gutenberg™ is synonymous with the free distribution of electronic works in formats readable by the widest variety of computers including obsolete, old, middle-aged and new computers. It exists because of the efforts of hundreds of volunteers and donations from people in all walks of life. Volunteers and financial support to provide volunteers with the assistance they need are critical to reaching Project Gutenberg™’s goals and ensuring that the Project Gutenberg™ collection will
- 74. remain freely available for generations to come. In 2001, the Project Gutenberg Literary Archive Foundation was created to provide a secure and permanent future for Project Gutenberg™ and future generations. To learn more about the Project Gutenberg Literary Archive Foundation and how your efforts and donations can help, see Sections 3 and 4 and the Foundation information page at www.gutenberg.org. Section 3. Information about the Project Gutenberg Literary Archive Foundation The Project Gutenberg Literary Archive Foundation is a non-profit 501(c)(3) educational corporation organized under the laws of the state of Mississippi and granted tax exempt status by the Internal Revenue Service. The Foundation’s EIN or federal tax identification number is 64-6221541. Contributions to the Project Gutenberg Literary Archive Foundation are tax deductible to the full extent permitted by U.S. federal laws and your state’s laws. The Foundation’s business office is located at 809 North 1500 West, Salt Lake City, UT 84116, (801) 596-1887. Email contact links and up to date contact information can be found at the Foundation’s website and official page at www.gutenberg.org/contact Section 4. Information about Donations to the Project Gutenberg Literary Archive Foundation Project Gutenberg™ depends upon and cannot survive without widespread public support and donations to carry out its mission of increasing the number of public domain and licensed works that can be freely distributed in machine-readable form accessible by the widest array of equipment including outdated equipment. Many
- 75. small donations ($1 to $5,000) are particularly important to maintaining tax exempt status with the IRS. The Foundation is committed to complying with the laws regulating charities and charitable donations in all 50 states of the United States. Compliance requirements are not uniform and it takes a considerable effort, much paperwork and many fees to meet and keep up with these requirements. We do not solicit donations in locations where we have not received written confirmation of compliance. To SEND DONATIONS or determine the status of compliance for any particular state visit www.gutenberg.org/donate. While we cannot and do not solicit contributions from states where we have not met the solicitation requirements, we know of no prohibition against accepting unsolicited donations from donors in such states who approach us with offers to donate. International donations are gratefully accepted, but we cannot make any statements concerning tax treatment of donations received from outside the United States. U.S. laws alone swamp our small staff. Please check the Project Gutenberg web pages for current donation methods and addresses. Donations are accepted in a number of other ways including checks, online payments and credit card donations. To donate, please visit: www.gutenberg.org/donate. Section 5. General Information About Project Gutenberg™ electronic works Professor Michael S. Hart was the originator of the Project Gutenberg™ concept of a library of electronic works that could be freely shared with anyone. For forty years, he produced and distributed Project Gutenberg™ eBooks with only a loose network of volunteer support.
- 76. Project Gutenberg™ eBooks are often created from several printed editions, all of which are confirmed as not protected by copyright in the U.S. unless a copyright notice is included. Thus, we do not necessarily keep eBooks in compliance with any particular paper edition. Most people start at our website which has the main PG search facility: www.gutenberg.org. This website includes information about Project Gutenberg™, including how to make donations to the Project Gutenberg Literary Archive Foundation, how to help produce our new eBooks, and how to subscribe to our email newsletter to hear about new eBooks.
- 77. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com