Tài liệu Model-Driven Development with Executable UML docx

SOL,www.sol.rs, a software development company specializing in building software devel-opment tools using model-driven technology, as well as in building custom applications and systems.

Model-Driven Development with Executable UML

Preface xxi

Part I: Introduction Chapter 1: Information Systems Modeling 3

Chapter 2: Traditional Approaches to IS Development 15

Chapter 3: The Object Paradigm 25

Part II: Overview of OOIS UML Chapter 4: Getting Started 41

Chapter 5: Basic Language Concepts 49

Chapter 6: Interaction and Querying 97

Part III: Concepts Chapter 7: General Concepts 141

Chapter 8: Classes and Data Types 181

Chapter 9: Attributes 247

Chapter 10: Associations 281

Chapter 11: Constraints 353

Chapter 12: Querying 391

Chapter 13: Operations and Methods 423

Chapter 14: State Machines 483

Chapter 15: Collaborations and Interactions 517

Chapter 16: Commands, Presentation, and Architecture 547

Part IV: Method Chapter 17: About the Method 593

Chapter 18: Conceptual Modeling 609

Chapter 19: Modeling Functional Requirements 631

Part V: Supplemental Chapter 20: Characteristics of Information Systems 663

Chapter 21: Process and Principles of Software Development 685

Chapter 22: The Relational Paradigm 695

Chapter 23: Structured Analysis 727

Chapter 24: Introduction to the Object Paradigm 737

References and Bibliography 749

Index 753

Model-Driven Development

with Executable UML

Model-Driven Development with Executable UML

Copyright © 2009 by Dragan Milicev

Published by Wiley Publishing, Inc., Indianapolis, Indiana

Published simultaneously in Canada

ISBN: 978-0-470-48163-9

Manufactured in the United States of America

10 9 8 7 6 5 4 3 2 1

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 Sections

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, 222 Rosewood

Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600 Requests to the Publisher for permission should be

addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201)

748-6011, fax (201) 748-6008, or online athttp://www.wiley.com/go/permissions.

Limit of Liability/Disclaimer of Warranty:The publisher and the author make no representations or warranties

with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties,

including without limitation warranties of fitness for a particular purpose No warranty may be created or extended

by sales or promotional materials The advice and strategies contained herein may not be suitable for every

situation This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting,

or other professional services If professional assistance is required, the services of a competent professional person

should be sought Neither the publisher nor the author shall be liable for damages arising herefrom The fact that an

organization or Web site is referred to in this work as a citation and/or a potential source of further information

does not mean that the author or the publisher endorses the information the organization or Web site may provide

or recommendations it may make Further, readers should be aware that Internet Web sites listed in this work may

have changed or disappeared between when this work was written and when it is read.

For general information on our other products and services please contact our Customer Care Department within the

United States at (877) 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.

Library of Congress Control Number: 2009927339

Trademarks: Wiley, the Wiley logo, Wrox, the Wrox logo, Wrox Programmer to Programmer, and related trade dress

are trademarks or registered trademarks of John Wiley & Sons, Inc and/or its affiliates, in the United States and

other countries, and may not be used without written permission All other trademarks are the property of their

respective owners Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book.

To Miloˇs, Mina, Jovan, and Sneˇza

CreditsExecutive Editor

About the Author

Dragan Milicev , PhD, is an associate professor at the Department of Computer Science at the University

of Belgrade, School of Electrical Engineering He is the founder and CTO of Serbian Object Laboratoriesd.o.o (SOL,www.sol.rs), a software development company specializing in building software devel-opment tools using model-driven technology, as well as in building custom applications and systems.With 25 years of experience in building complex software systems, he has served as the chief softwarearchitect, project manager, or consultant in more than 20 academic and international industrial projects

Of note is the fact that he was Chief Software Architect and Project Manager for most of SOL’s projectsand all its products: SOLoist, a rapid application model-driven development framework for informationsystems; SOL UML Visual Debugger, one of the world’s first UML visual debuggers, designed for thePoseidon for UML modeling tool; and SOL Java Visual Debugger, a plug-in for Eclipse that enables mod-eling of test object structures using UML object diagrams He has published papers in some of the mostprestigious scientific and professional journals and magazines, contributing to the theory and practice ofmodel-driven development and UML He is the author of three previous books on C++, object-orientedprogramming, and UML, published in Serbia You may contact him atdmilicev@etf.rs

I would like to express my great debt of gratitude to Bran Selic, one of the pioneers and most respected

authorities on model-driven software engineering and key contributors to UML, whose careful and

thorough review of the manuscript and invaluable comments helped improve this book’s structure and

technical accuracy

Special thanks to my colleagues from SOL who have been involved in the development of SOLoist and

its application to many industrial projects Their contribution to the implementation of many ideas

pre-sented in this book, as well as their help in making the concepts indeed pragmatic and effective for

industrial systems, is deeply appreciated

I would like to thank my research assistants, as well as my graduate and undergraduate students from

the University of Belgrade, School of Electrical Engineering, Department of Computer Science, who took

part in the research and development of some ideas and concepts presented in the book They also offered

many valuable comments on the early drafts of the manuscript

Many thanks to the companies where I have served as a consultant I have enjoyed the opportunity to

brainstorm with colleagues and discuss many ideas presented in this book, as well as the opportunity to

apply the ideas in practice

The work on the development and implementation of the approach presented in this book is partially

supported by the Serbian Ministry of Science, under the national program for technology development,

grant TR-13001

Finally, I would like to express my boundless gratitude for forbearance, understanding, and support to

my beloved daughter, Mina, sons Miloˇs and Jovan, and wife, Sneˇzana, to whom I dedicate this book

Part I: Introduction

Models and Modeling Paradigms, Languages, and Tools 5

Characteristics of Traditional Modeling Paradigms 16

Desired Characteristics of Object-Oriented Information Systems 33

Usability Aspects 34

Part II: Overview of OOIS UML

Chapter 6: Interaction and Querying 97

Part III: Concepts

Common Characteristics of Classes and Data Types 181

Discriminating Characteristics of Classes and Data Types 185

Notion of N-ary Association 331

Chapter 13: Operations and Methods 423

Part IV: Method

Business Processes and Use Cases 647

Actions Upon Structure 703

Fundamental Object-Oriented Concepts and Principles 737

P r e f a c e

Logical complexity of software systems is one of the main factors causing problems and errors in theirplanning, design, development, testing, deployment, maintenance, and use There is a common under-standing that building complex software systems requires careful planning, good architectural design,and well-controlled development processes Many good books and papers, as well as all software engi-neering curricula, address this issue and yet, many software projects fail, miss their deadlines, or exceedtheir budgets Building or maintaining a complex system (be it software or not) is always connected to arisk of mistakes and missed requirements, because humans (who are supposed to build the system) areintrinsically prone to errors when handling too many details and interrelated components at a time

However, logical complexity is not completely inherent to software systems On one hand, there is aninevitable component of complexity that is inherent to the very problem domain a software system

deals with The term essential complexity refers to that part of logical complexity inherent to the

prob-lem domain, and not introduced by a solution or the impprob-lementation technology used for it Essentialcomplexity is, thus, the ‘‘natural’’ part of complexity that cannot be removed and will exist in every

solution to a problem, simply because a simple solution to the problem does not exist However,

essen-tial complexity stands in contrast to accidental complexity, which arises purely from the implementation

technology, tools, and methods applied in a solution While essential complexity is unavoidable by anyapproach chosen to solve a problem, accidental complexity is caused by that very approach

One of the main tasks in software engineering as a discipline is to discover means to minimize accidentalcomplexity Accidental complexity is to be minimized in any good software architecture, design, andimplementation

Sometimes, accidental complexity can be caused by mistakes such as ineffective planning or project

management, or a low priority placed on a project However, some accidental complexity always occurs

as a result of solving any problem For example, the complexity caused by out-of-memory errors in manyprograms is an accidental complexity that occurs because someone decided to use a computer to solvethe problem [Wiki]

Another significant cause of accidental complexity is a mismatching or immature technology or processselected for the development of a software system If the available technology (including the languageused for software development) requires the developer to write more words or perform more actions tospecify a design decision than is really necessary, the artifacts of the development will be accidentallycomplex Using an assembly language to implement a non-trivial algorithm, and using a file system

interface to build a database application are simple, extreme examples of such mismatching technology

A less obvious example of such accidental complexity is when some code has to be written to specify that

a relationship between two objects has to be established when one object is dragged and dropped on theother object This can be done in an easier and more direct way, by demonstration

For that reason, raising the level of abstraction of the technology used for development of software

systems, and doing so in a way that it better matches the problem domain of those systems, is one of thebasic means for guarding against accidental complexity Raising the level of abstraction is one of the main

characteristics of the evolution of software engineering as a discipline As Bran Selic once said, ‘‘There has

been no revolution in software engineering since the invention of a compiler.’’ In other words, once we

understood that we did not have to talk to the computer in the language its hardware understands, but

rather we can do it in a language that is more suitable for us, and which can be automatically translated

into the language of the machine, we made the most significant breakthrough in software engineering

Everything since then has basically been all about raising the level of abstraction of the language used to

program machines

The point of raising the level of abstraction is to achieve better expressiveness By using a language that

better matches the problem you want to solve, you can say more ‘‘facts’’ in fewer ‘‘words.’’ This also

means that you can do more with less work In addition, written words do not have to be the only way to

communicate with the machine Pictures (such as diagrams), motions, and sounds (for example, spoken

words) have already been a mode of communication between humans and computer programs, so they

can be in software development, too

This book contributes to the technology of developing one of many kinds of software systems, and

proposes a technique that can improve development efficiency by raising the level of abstraction and

reducing accidental complexity

Model-driven development is one approach to raising the level of abstraction that has been successfully

exploited for more than a decade Its basic premise is to use models instead of (solely) code to specify

software Models are generally nonlinear forms, as opposed to code that is inherently linear.1

Non-linear means that models consist of elements that are interrelated in a manner that is freer than a simple

sequence where each element can have (at most) two adjacent elements For that reason, models are

usually rendered using visual notations, such as diagrams, instead of pure text

The software development approach described in this book is model-driven

The Unified Modeling Language (UML) is a standard language that is used for modeling software It was

proposed in the mid-1990s, and was first standardized in 1997 It is a general-purpose language aimed at

modeling all kinds of software systems

The approach described in this book uses UML as the modeling language.2The book follows the

defini-tions and specificadefini-tions given in the reference [UML2]

However, the scope of this book does not cover all kinds of software systems Instead, it is limited to one

special kind of software systems known as information systems The introductory part of this book defines

what is precisely meant by this term In short, this book focuses on all those applications that have the

following properties:

❑ A complex conceptual underpinning— The applications rely on rather rich sets of concepts,

properties, and relationships from their problem domains

1 Note that code is a sequential form, because it represents a string of characters Machines and humans read code in

a sequential order, one character after another To improve its readability, machines render code in two-dimensional

viewports, but it is still inherently sequential.

2 As of this writing, the latest UML standard is version 2.2 This book describes this version of UML and is based on

the reference [UML2].

❑ Large-scale dynamic instantiation— During exploitation, the applications manipulate largespaces of instances of their concepts and relationships These instances are dynamically created,

modified, retrieved, queried, presented, and deleted They are traditionally referred to as data

accom-This book focuses on model-driven development of information systems using UML

UML is not, however, a fully formal language This means that its semantics are not defined in an biguous way in all its elements For that reason, UML cannot be used as a language in the same way astraditional programming languages, in which a specification of a software system can be unambiguouslyinterpreted by machines (for example, compiled and executed) In order to be such, a language must haveformal, unambiguous semantics — that is, a unique interpretation of each of its concepts that is supposed

unam-to have run-time effects

In addition, UML is a general-purpose modeling language that can be profiled for a specific domain of problems For example, standard UML leaves many so-called semantic variation points, which allow a

profile to interpret certain language concepts in several ways A profile can also reduce the set of thelanguage concepts used in a particular problem domain, or extend the semantics of the concepts in acontrolled way This way, a profile can customize the standard language so that it becomes fully formaland, thus, executable A model built in such a profile represents the implementation of the software atthe same time, and, because it can be executed, is not just an informal sketch of the design

This book proposes and describes one new executable profile of UML for the described application

domain It is but one of several existing profiles of UML with formal and executable semantics, cally tailored for the domain of information systems.3

specifi-On one hand, the relational paradigm has been proven and widely accepted as the underpinning nology for building information systems On the other hand, as another software-development paradigmwith significantly more abstract and expressive concepts, object orientation has been successfully usedfor decades in programming UML is one of the languages based on the object paradigm

tech-The marriage of object orientation with information systems development has been predominantly

accomplished by using object-oriented programming (OOP) languages to implement behavior (or the

so-called business logic) upon the underlying relational database, possibly accessed through a data

per-sistence layer that performs object-to-relational mapping This approach has partially replaced the use

of fourth-generation programming languages that directly fit into the relational paradigm At its currentstage of technical development, this widely used approach suffers from discontinuities in developmentcaused by incomplete or informal coupling of the object with the relational paradigm

3 For that reason, the term ‘‘executable UML’’ does not refer to any particular executable version of UML, but is rather

a generic term that denotes any formal and executable specialization of standard UML One such executable ization of standard UML is presented in this book.

special-This book discusses the problems of these technologies, how they affect development, and how they can

be overcome

In short, this book explores the following:

❑ A technology for rapid development of one kind of applications referred to as information

systems

❑ The use of the object paradigm and model-driven development of information systems

❑ One executable profile of UML for model-driven development of information systems

Following are the goals of this book:

❑ To provide an in-depth tutorial on model-driven development and UML for building

informa-tion systems

❑ To show how information systems can be understood better and developed more efficiently

by using the object paradigm, model-driven development, and a profile of UML that is formal

and executable (rather than the relational paradigm or its incomplete coupling with object

orientation)

Note that this book is not any of the following:

❑ A tutorial on, a reference specification of, or a textbook about the entire general-purpose

UML— This book does cover a major part of UML, but there are still parts of UML that are not

covered Instead, the book focuses on the concepts and parts of UML that are most likely to be

needed in building information systems

❑ A complete tutorial on the object paradigm or any traditional OOP language— However, this

book does describe the fundamental concepts of object orientation

❑ A complete tutorial on information systems or all the related technologies— Part V of this

book does, however, provide a condensed recapitulation of the main facts about information

sys-tems and the technology of their building, including their architectures, the relational paradigm,

entity-relationship, structured analysis, and SQL

❑ A complete textbook on the development process of software systems in general, and

infor-mation systems in particular— Part IV of this book does, however, provide a quick practical

guide to the proposed development method

❑ A book that describes patterns or other techniques and building blocks for building

informa-tion systems— This book does not teach how to build information systems through the use of

complex, integrated examples and case studies Instead, it teaches concepts and principles, using

many small, simple, and particular examples for illustration

Whom This Book Is For

This book will be useful to software practitioners who analyze, specify, design, model, develop, or test

information systems This book is for those who want to improve their knowledge and productivity by

exploiting model-driven rapid application development with an executable profile of UML Readers who

might benefit include system analysts, system and software architects, designers, developers, and testers

The book will also be interesting to researchers who want to explore new software development gies, methods, and metaphors, especially model-driven development and programming by demonstra-tion The book introduces some new concepts and ideas that could be interesting to explore further.

strate-This book can also be used as a textbook for higher-education courses on information systems, driven software engineering, and UML

model-The reader’s prior knowledge of the object paradigm or any of the OOP languages is a plus, but is notnecessary This book gradually introduces the basic concepts and principles of object orientation

Similarly, prior knowledge of the relational paradigm or any of the relational database managementsystems (RDBMSs) and SQL is not essential, although it is desirable Part V of the book summarizes thesetopics for those who are not familiar with them On the other hand, readers familiar only with thesetopics will experience a paradigm shift

Finally, prior knowledge of UML is not needed at all The book is a complete beginner’s tutorial of (aprofile of) UML However, experienced users of UML will also benefit from clarification of many vagueconcepts of UML and their semantics

The prerequisite for reading this book is general knowledge of programming Knowledge and experience

in building information systems is a plus, although not essential

How This Book Is Str uctured

The book is divided in the following parts:

❑ ’’Introduction’’ (Part I, Chapters 1–3) — This part quickly introduces information systems Itthen elaborates on traditional technologies of development of information systems and their

advantages and drawbacks This part clearly indicates the main issues with the widespread use

of traditional paradigms for building information systems (most notably, relational modeling

or entity-relationship modeling), or with incomplete coupling of object orientation (and OOPlanguages) with relational modeling The analysis provides the motivation for the approach pre-sented in the book

❑ ’’An Overview of OOIS UML’’ (Part II, Chapters 4–6) — This part is a quick overview of the

executable profile of UML proposed in this book, referred to as the OOIS UML profile This part

quickly presents the main concepts and ideas that will be described in more detail later in thebook

❑ ’’Concepts’’ (Part III, Chapters 7–16) — This central part of the book thoroughly explains theconcepts of OOIS UML and their semantics

❑ ’’Method’’ (Part IV, Chapters 17–19) — This part provides a quick guide to the proposed

method for applying the OOIS UML profile for building information systems

❑ ’’Supplemental’’ (Part V, Chapters 20–24) — This part provides auxiliary tutorial material forthe traditional technology that is widely used for building information systems nowadays, andthat is not essential for understanding the main parts of the book The supplement includes asummary of the general characteristics of information systems, some basics of software engi-neering processes, the relational paradigm, entity-relationship modeling, structured analysis,and general principles of the object paradigm These tutorials are provided for the convenience

of the interested readers who are not familiar with these topics and traditional technologies, or

as quick reminders for those who are experienced with them

If you are familiar with the notion of information systems and the traditional technology of their

devel-opment (including relational databases and entity-relationship), you can simply read the book from its

beginning In the first three chapters of the book, you will find an analysis of the issues that you have

probably faced in your work You will also find explanations of the causes of the issues, while the central

part of the book will provide solutions

If you are not familiar with these traditional technologies, you can still start reading from the beginning

However, you can also skip to the supplement to gain some basic knowledge of the technology you do

not know well However, this knowledge is not essential for understanding of the main part of the book

Finally, if you are just eager to see what this book is all about, and the new and original information

contained herein, simply read Part II and you will get the main idea Then you can go back or forward as

you like

About the Suppor ting Software and the

Accompanying Site

The method described in this book can be applied even without full-fledged tool support The author

has taken part in several successful industrial projects where only customized off-the-shelf or ad hoc

developed tools were used to partially support some activities in the approach (such as UML modeling

tools, customized code generators, and object-to-relational mapping frameworks) Even without

full-fledged tool support, the proposed approach can boost the productivity and improve the quality of

the produced software because of the raised level of abstraction, better expressiveness of the modeling

language and its semantics, clear architecture of the software system, and a well-controlled development

method

However, obviously, the full benefit of the proposed approach can be reaped only with strong and

full-fledged support of computer-based tools There can be many different implementations of the proposed

UML profile with the appropriate tool support The author is the inventor and has served as the chief

architect of one such tool, named SOLoist4, which has been developed for and successfully applied to a

wide variety of industrial projects since 2000, and which supports many concepts described in this book

Seewww.ooisuml.orgfor more discussion about the profile and the method presented in this book, their

open issues and further improvements, as well as their implementations and applications to real-world

projects

Conventions

To help you get the most from the text and keep track of what’s happening, we’ve used a number of

conventions throughout the book

4 SOLoist is a trademark of Serbian Object Laboratories d.o.o (SOL)

❑ Each section of the book ends with a summary enclosed in a box like this.

As for styles in the text:

❑ We highlight new terms and important words when we introduce them.

❑ We show keyboard strokes like this: Ctrl+A

❑ We show filenames, URLs, and code within the text like so:persistence.properties

❑ We present code in two different ways:

We use a monofont type with no highlighting for most code examples

We use gray highlighting and underlining to emphasize code that is of particular

importance in the present context

Errata

We make every effort to ensure that there are no errors in the text or in the code However, no one isperfect, and mistakes do occur If you find an error in one of our books (such as a spelling mistake orfaulty model fragment), we would be very grateful for your feedback By sending in errata you may saveanother reader hours of frustration and, at the same time, you will be helping us to provide even higherquality information

To find the errata page for this book, go tohttp://www.wrox.comand locate the title using the Search box

or one of the title lists Then, on the book details page, click the Book Errata link On this page you canview all errata that has been submitted for this book and posted by Wrox editors A complete book list(including links to each book’s errata) is also available atwww.wrox.com/misc-pages/booklist.shtml

If you don’t spot ‘‘your’’ error on the Book Errata page, go towww.wrox.com/contact/techsupport.shtmland complete the form there to send us the error you have found We’ll check the informationand, if appropriate, post a message to the book’s errata page and fix the problem in subsequent editions

of the book

p2p.wrox.com

For author and peer discussion, join the P2P forums atp2p.wrox.com The forums are a Web-based tem for you to post messages relating to Wrox books and related technologies, and to interact with otherreaders and technology users The forums offer a subscription feature to e-mail you topics of interest ofyour choosing when new posts are made to the forums Wrox authors, editors, other industry experts,and your fellow readers are present on these forums

sys-Athttp://p2p.wrox.com, you will find a number of different forums that will help you not only as youread this book, but also as you develop your own applications To join the forums, just follow these steps:

1. Go top2p.wrox.comand click the Register link.

2. Read the terms of use and click Agree

3. Complete the required information to join, as well as any optional information you wish to

provide, and click Submit

4. You will receive an e-mail with information describing how to verify your account and

com-plete the joining process

You can read messages in the forums without joining P2P However, in order to post your own messages,

you must join.

Once you join, you can post new messages and respond to messages other users post You can read

messages at any time on the Web If you would like to have new messages from a particular forum

emailed to you, click the Subscribe to this Forum icon by the forum name in the forum listing

For more information about how to use the Wrox P2P, be sure to read the P2P FAQs for answers to

questions about how the forum software works, as well as many common questions specific to P2P and

Wrox books To read the FAQs, click the FAQ link on any P2P page

Part I Introduction

Chapter 1: Information Systems Modeling

Chapter 2: Traditional Approaches to IS Development

Chapter 3: The Object Paradigm

Information Systems

Modeling

To provide a foundation for the discussions throughout this book, this chapter begins by defining

what is actually meant by the term information system The focus is on model-driven engineering

of the software component of information systems This chapter also introduces and describes the

very notion of modeling The chapter concludes with a brief discussion about software engineering

processes, an important aspect of building successful information systems

Definition of Information Systems

Information systems have played a key role in the history of computers and their use in

every-day human activities It is hard to imagine even a small company, institution, or organization that

does not have a need for storing and using information of a different kind We are all witnesses

of the tremendous improvement of computer and communication technology, which support

ever-increasing demands of human community for interchanging and utilizing information It

is not necessary to discuss the role and importance of information systems such as healthcare

systems, enterprise systems, banking and financial systems, educational information systems,

customer-support systems, governmental systems, and many other kinds of information systems

(see Figure 1-1)

Trying to catch up with the importance and ever-emerging demand for improved functionality

and performance of such systems, the hardware and software technology for their implementation

seem to constantly stay behind It has always been a question of how to improve the technology

(especially that for software development) to meet the users’ needs Because this question defines

the scope of this book, before trying to answer it, it is necessary to set up the context and define what

information systems really are

First and foremost, information systems are systems A system is a set of elements organized to

cooperate in order to accomplish a specific purpose Elements of a system collaborate synergistically,

in a manner that provides a behavior and quality bigger than the sum of its parts It is likely that a

particular part of a complex information system (such as a piece of hardware or software) may be of no

use if it is taken without the other parts Only a complex interaction of such parts accomplishes the real

purpose of the entire system

Figure 1-1: Information systems

Moreover, information systems are computer-based systems, meaning that their elements encompass

hardware, communication equipment, various software subsystems, information, and users The

software of almost every information system is also a complex subsystem, comprised of communication

software, the operating system, the database management system, different application modules,

presentation modules, and so on Because information systems generally assume storing and processing

of large amounts of data, computer technology is irreplaceable for their implementation

Next, information systems deal with information Avoiding more complex and abstract definitions and

focusing on computer-based information only, information can be understood as a piece of data that is

structured, stored, transferred, processed, and presented in a proper manner, and at a right time, so that

it has a certain meaning and accomplishes a specific purpose for its users Therefore, information is not

just a simple fact, but a piece of data that is shaped properly and provided timely to meet the specific

user’s needs

For example, the fact that a certain patient has blood type A has no importance to the accountant

using a hospital information system To the accountant, it is much more important to present the

total quantity of blood type A used for transfusions in a certain period On the other hand, the same fact

is key for a doctor who must organize the transfusion for that patient However, if that fact relates to a

patient that was hospitalized 50 years ago, it may be of no importance even to the doctor If, however,

the fact relates to a patient who just arrived in the Emergency Room, it has the crucial importance and

represents the right information at the right time

In summary, an information system is a computer-based system primarily dealing with pieces of data

that are structured, stored, transferred, processed, and presented in a proper manner, and at the right

time, so that they have a certain meaning and accomplish a specific purpose for the system’s users

For a more in-depth discussion of the variety of characteristics of information systems (characteristics

that can more precisely describe the nature of information systems, as well as their engineering aspects),

see Chapter 20 in the Supplement

Section Summary

❑ An information system is a computer-based system primarily dealing with

large amounts of data that are structured, stored, transferred, processed, andpresented in a proper manner, and at a right time, so that they have a certainmeaning and accomplish a specific purpose for the system’s users

Models and Modeling Paradigms, Languages, and Tools

Model-driven software engineering is a modern discipline that covers the building of software based on models, using modeling languages and tools However, the notions and principles of this discipline have

roots in other engineering approaches This section further explores these topics

Modeling

The engineering disciplines that are much more mature than software engineering (such as civil, ical, or electrical engineering) require that the designers of a new system build simplified representa-tions of the system under construction in order to analyze the future system’s characteristics before

mechan-it is built, as well as to convey their design to the implementers Such a simplified representation of

the system under construction is called a model of the system, and the process of its creation is called

modeling.

Models can be expressed in abstract terms, such as, for example, mathematical models, schemas, or

blueprints On the other hand, models can be physical, usually small copies made of plastic, wood,

or other materials Models allow the designers to experiment with the design and test its characteristicsbefore the system is actually built Such an approach reduces the risk of faulty construction of the realsystem with potentially disastrous or costly consequences

There is no reason why software engineering would not follow these good practices of other engineeringdisciplines and exploit models and modeling in building complex software systems One crucial dif-ference is that in software engineering, the ‘‘material’’ that models are made of can be the same as theultimate system — the model can be a formal and unambiguous specification that can be either directlyinterpreted by another software system, or transformed into a form that can be executed by hardware

or interpreted by another software system In that case, the model is executable and represents, when

complete, the very system under construction

A model is a simplified representation of the real world It is built to provide a better understanding of acomplex system being developed Models of complex systems are built because such systems cannot becomprehended in their entirety By modeling, four aims are achieved [Booch, 1999]:

❑ Models help to visualize a system as it is, or as designers want it to be (visualization).

❑ Models permit the designer to specify the structure and behavior of the system (specification).

❑ Models give templates that guide in constructing systems (construction).

❑ Models document the design decisions that have been made during development

(documentation).

Basically, programs created in traditional programming languages may be treated as models because they

specify the software system in a formal and executable way However, programs created in traditional

programming languages are not considered as being models, because of the following:

❑ Models basically deal with more abstract notions, while programs deal with subtle

implementa-tion details

❑ Models may often be incomplete or imprecise, especially in early analysis phases, although this

does not prevent them from being executable Programs are ultimate artifacts of software

devel-opment

❑ Models are usually specified in visual (diagrammatic) notations, combined with textual

(se-quential) parts, while traditional programming languages predominantly presume textual

(sequential) forms

The software engineering discipline in which models are the central artifacts of development, which are

used to construct the system, communicate design decisions, and generate other design artifacts, is called

model-driven engineering (MDE), while the development of systems that exploit MDE is called model-driven

development (MDD).

Modeling Languages

To build models, developers must know the vocabulary that can be used in modeling The vocabulary

available for modeling (that is, the set of concepts, along with the semantics of these concepts, their

properties, relationships, and the syntax) form the definition of the modeling language Using a certain

modeling language, developers build sentences in that language, creating models that way Therefore,

a modeling language is the key tool available to developers for building models because there is no

purpose in making models without understanding their meaning Hence, a modeling language provides

a common means for communication between developers

To be successful, a modeling language must be carefully balanced to meet somewhat opposing demands

On one hand, a modeling language must be simple enough to be easily understandable and usable by

modelers If the modeling language were too complex to be comprehensible, it would not be widely

accepted by the software community Additionally, it is very desirable that users who pose the

re-quirements also understand the modeling language, at least the part that is used in specification of

requirements This property may significantly reduce the risk of misunderstandings between users and

modelers during requirements specification

On the other hand, a modeling language should not be too simple or too specific If the modeling

lan-guage were not general enough, it could not cover all situations that could arise in the real world

In addition, a modeling language must be abstract enough to be conceptually close to the problem

domain A modeling language that is not abstract enough suffers from a large conceptual distance

from the problem domain In that case, the development requires a big mental effort because the modelersmust take the conceptual mapping from the problem domain into the model In other words, the lan-

guage must be expressive enough.

Expressiveness is a descriptive property of a language that measures the ‘‘quantity’’ of meaning

of certain language concepts An expressive language consists of concepts that have rich semantics

and, thus, have plentiful manifestation at the system’s execution time Models in an expressive

language may be concise, and yet provide lots of run-time manifestations that correspond to the

posed requirements Expressiveness is, in other words, a measure of conciseness with which a

particular logical design may be expressed in a certain language Put more simply, it measures how

many (or few) words you must say in the given language in order to express some logical design orintention

Therefore, the modeling effort and development cost is directly affected by expressiveness If the guage is expressive enough, models consist of smaller sentences, and developers make less effort to

lan-specify systems under construction, and vice versa

Additionally, a modeling language should allow informal, incomplete, or inconsistent models

because the process of modeling in the early phases of requirements specification and system

conception often assumes such models During the early phases of requirements engineering and

system conception, system analysts and designers have vague and sometimes incorrect visions

of the systems being specified and constructed Therefore, the analysts should be able to make

sketches in the modeling language, in a way that allows their later refinement If the modeling

language does not allow such imprecise modeling, it could not be used in the early requirements

specification and conceptualization phase However, it is very useful if the same language is used inthe entire process of system development, but not just during requirements specification or just duringdesign

On the other hand, a modeling language should be simple and primitive enough in order to have precisesemantics that allow transformation of models into an implementation form Highly abstract modelsare usually transformed into lower-level forms that can be either interpreted by other software systems,

or further transformed into even lower-level forms, or ultimately executed by hardware (which alsointerprets the binary code in some way)

For example, source code in a traditional textual programming language such as C++, Java, or C# istransformed (compiled) by other software systems (compilers) into either a binary executable program(for C++), which is executed by hardware, or into an intermediate form (as in Java or C#), which is

interpreted by other software systems (virtual machines), to provide the running application Similarly,

a model made in a visual modeling language, such as the Unified Modeling Language (UML), which

is a focus of this book, may be transformed into the target programming language code (for example,C++, Java, or C#)

The described transformation into a lower-level form can be performed manually, semi-automatically,

or completely automatically, using the corresponding transformer It is very useful if a highly abstractmodel of a system, specified in a modeling language, can be transformed completely automatically (inone or several steps) into a form that can be executed or interpreted in a way that provides the runningapplication, following the semantics of the initial model In that case, the modeling language can be

treated as executable, although it is not directly executed by hardware This is because the model implies

an automatically achievable form that can be ultimately executed by hardware

In this chain of transformations and intermediate models (for example, source code, intermediate code,

executable code, and so on), the form that can be interpreted by another software system to result in the

running application (such as Java byte code or SQL statements), or that can be automatically compiled

into an executable binary code (such as source code in C++), is referred to as the implementation form, and

the language it is made in is referred to as the implementation language.

In order to be executable, the modeling language must have precise and completely formal

seman-tics, and the model that should be executed (or, more precisely, automatically transformed into an

implementation form), must be formal, unambiguous, and consistent These are the most important

char-acteristics of the modeling languages that claim to be useable and useful for modeling of any complex

software system in general, and information systems in particular

The concrete notation of modeling and implementation languages can be textual or visual Textual

languages allow you to create inherently sequential models Although textual models (that is, programs

or scripts or sentences written in textual languages) may be visually perceived by the developer in

two dimensions, they are inherently sequential because the transformers parse them as sequences of

characters

Conversely, visual languages assume making models in two or even three dimensions, most often using

diagrammatic notations combined with textual fragments It is usually the case that a pictorial,

diagram-matic notation is much more descriptive, intuitive, and easier to perceive than the equivalent sequential

(textual) form This is why modeling languages with diagrammatic notations are more popular for

abstract modeling

However, it is not always true that visual languages are more usable than textual ones Some intentions

can be much more effectively expressed in a textual form than in a visual form For example, to specify a

simple loop or an expression such as a regular expression or a simple addition of two operands, a textual

form may be much more convenient and concise than an equivalent graphical notation

In short, both textual and diagrammatic languages have their advantages and drawbacks Usually, a

combination of both is most efficient in modeling

Figure 1-2 illustrates the comparison of abstract versus low-level modeling, and visual versus

tex-tual modeling languages A small piece of a model in a highly abstract, visual language is shown in

Figure 1-2a, whereas the equivalent model in a low-level, textual language is shown in Figure 1-2b Both

examples model the same simple fact from the problem domain that a person (described with name,

social security number, and address) may work for at most one company (described with name and

address), and a company may employ many persons

The example shown in Figure 1-3 illustrates a yet more dramatic difference between the abstract visual

model in Figure 1-3a, and its semantic equivalent in a lower-level, textual programming language in

Figure 1-3b The figure shows the lifecycle model for a course enrollment in an imaginary educational

institution The diagram in Figure 1-3a depicts how a student’s application for a course is processed until

it gets either rejected or accepted, or suspended (and later resumed) or canceled

Figure 1-2: Abstract vs low-level modeling and visual vs textual modeling languages

(a) A model in a highly abstract, visual language (b) A model in a low-level, textual

language Both examples model the same simple fact from the problem domain that a

person (described with name, social security number, and address) may work for at

most one company (described with name and address), and a company may employ

many persons

Modeling Tools

As in any other engineering discipline, tools are key factors to successful production In the context ofmodeling, different kinds of software systems are used as modeling tools The system that is used as anenvironment for creating and editing models (and that is responsible for their specification, visualization,

and consistency checking) is called the model editor The tools that transform the models into lower-level forms are generally called transformers or translators, or specifically generators or compilers, depending on

their target domain

For example, a tool that transforms a higher-level, abstract, and visual model into a textual source code

in the implementation language (for example, C++, Java, or C#) is often referred to as a code generator,although it is sometimes called a model compiler

Finally, the tool that transforms a program written in a textual language (such as C++, Java, or C#) into

the executable (binary) code, or interpretable (intermediate) code, is often called the compiler Many other

kinds of modeling tools are also used for specific tasks in development, such as model analyzers, modelcomparators

Modeling Paradigms

There are modeling languages that are particularly appropriate for (or the same) problem domains,

such as those that analyze or compare models, and others These languages, based on the same set of

fundamental concepts, form a modeling paradigm The languages of the same paradigm may differ in

more or less detail or variations

acceptrejecttakeOver

Processing

Submitted

InApproval

CanceledAcceptedRejected

Suspended

suspendresume

H

(a)

(b)

switch (state) { case Submitted:

switch (event) { case takeOver: state = InApproval; break;

case suspend: prevState = state; state = Suspended; break;

case cancel: state = Canceled; break;

};

break;

case InApproval:

switch (event) { case reject: state = Rejected; break;

case accept: state = Accepted; break;

case suspend: prevState = state; state = Suspended; break;

case cancel: state = Canceled; break;

For example, the relational modeling paradigm is based on the fundamental concept of mathematical

relation, which is often represented by a table with columns (or fields, properties, attributes) and

rows (records or tuples) Although relational database management systems (RDBMSs) often support

somewhat different languages, varying in other concepts built upon the basic relational concepts, they

are still based on the same paradigm For additional information about the relational paradigm and

DBMSs, see Chapter 22 in the Supplement

Similarly, the procedural programming paradigm assumes some common concepts such as data type,

variable, expression, statement, loop, subprogram (procedure or function), argument (formal and actual),