Open Modeling with UML - Softcover

Preface
Purpose of this book
Austin, Texas, October, 1995. We were both there to listen to the jagged and ragged singing of one of the three Amigos of the Unified Modeling Language as its precursor, the Unified Method, was announced on an eventful evening. The UML has come a long way since then, and a large number of IT professionals1 have worked towards smoothing the edges of this now very popular modeling language. With the acceptance of the UML by the Object Management Group in 1997, it is now a public domain modeling language that is available to anyone and everyone who wishes to follow a disciplined and standard approach to modeling systems and applications in the new millennium. It is thus a necessary part of any software activity but, needless to say, not sufficient. Insufficiencies of the UML arise from the fact that it is a pure modeling language, nothing more. It contains no elements of process that would guide software development from start to finish. Being only a modeling language, it also does not take responsibility for data issues, migration issues, component integration issues, nor for the higher-level process and project management issues. As the IT world moves forward in the new millennium, a dearth is felt by most IT professionals of a +process+ that would not only provide the control and guidance needed for varied software development situations, but of a +process environment+ that would lend itself to +tailoring+ - a customization process that would enable the development process to be tailored to precisely fit the individual organization+s development environment. While there is a lot of process material that discusses new software development, there is a dearth of discussion on processes that help in customizing software packages and/or provide help in +integrating+ newly developed components with existing legacy software. These are some of the areas that are addressed in this work through OPEN.
So, what is OPEN?
OPEN stands for Object-oriented Process, Environment and Notation. It is a +third generation+ methodological approach that has been very successfully used in practice, as well as for teaching about object-oriented methods and even basic object-oriented concepts around the world, for several years. In this book, however, we present OPEN at an introductory level for industry. Having read this book, you will no doubt want to find out further, more detailed, information. This can be found in other titles in the OPEN book series. We have written two full books to describe all the detail (Graham et al., 1997a; Henderson-Sellers et al., 1998). These contain the information on how to use OPEN on real projects once you have mastered the introductory level concepts described in this book. There is also a detailed case study example in the book (see Bibliography) of Firesmith et al. (1998). In contrast to those earlier books, therefore, this book will initiate interest and provide support in the use of a process-based development effort. It will be found useful both for industry users and also at a university Master+s level.
Summary of the book
The book is primarily written around a pair of case studies. The first (Chapter 4) is a relatively simple one showing how to use OPEN in a responsibility-driven style of development, and the second, in Chapter 5, focuses on the use of OPEN in a use-case-driven software project. This choice of case studies illustrates our belief that to learn about good software design, you must observe, study and then replicate (with fine tuning, of course) existing development material. This is best exemplified by a case study.
However, since this is an introductory level book, we precede these two case studies by some ground-laying material. In Chapter 1 we give a brief overview of the OPEN process and an appropriate modeling language: UML (the Unified Modeling Language of the Object Management Group). These two topics (UML and OPEN) are then examined in the next two chapters in more detail.
In Chapter 2 we describe the key elements of the UML. We must stress here that, while UML is a modeling language and thus contains both a metamodel and a notation, it is primarily the notational element that we will introduce here. The metamodel is implicit in the rules we give you about how to build models and how to document them using the notation and the recommended diagram types. We will also use it, as and when required, in the context of the OPEN process (Chapters 3-5). This contrasts with, for instance, one of the first books on UML (see Bibliography) by Fowler and Scott (UML Distilled) which only addressed notation, but still found it necessary to invent fractions of process (e.g. the four phases of development) in order to explain the notation. Similarly, in a recent book by Quatrani, the focus is on modeling with the ROSE tool - although there is a stronger process element than in UML Distilled. Please note that we have no issues in using any CASE tool in order to show the use of notations and diagramming technique. In fact, we have used evaluation versions of three different CASE tools to draw UML diagrams in the last three chapters in this book. However, our focus here is on the use of process rather than notation. This means that we are in no danger of omitting important methodological process steps and, at the same time, we introduce only commonly used notational elements.
In Chapter 3, we examine the support in OPEN for modeling. OPEN contains a number of Activities, Tasks and Techniques, many of which are focused on modeling. Indeed, this book only deals with modeling. So, in this chapter, we select those elements of OPEN which support modeling and discuss, particularly, its modeling Tasks and Techniques. These give you the tools and the process by which to build software. The work product or artefact resulting from the process can then be documented using the chosen modeling language of UML. OO methodologies in general (and OPEN is no exception) are often more extensive than their traditional (structured) counterparts, since they reflect an increasing sophistication in our use of modeling techniques. Companies are building increasingly sophisticated software and find that their use of object technology permits this. They can take on challenges and establish their competitive edge in ways that they could only dream about 10 or 20 years ago. Using a good, process-focused methodology is only one element in making those dreams come true. Skills of people, an organizational fit (between culture and process) and a determination to succeed all facilitate the road to success. Object technology (and increasingly OO-based component technology) provides a bridge between technical success and management success.
Finally we would note that using OPEN on a commercial project requires access to the full methodology as well as a modeling language. In other words, a significant number of the OPEN project management tasks and techniques will be needed, as well as detailed iterations of the activities of requirements engineering and deployment. Due consideration of quality and reuse will also be required. Some of these activities and related issues are alluded to in Chapter 5 as well as demonstrated, albeit briefly, in the Appendix. Training and mentoring on the process, modeling language and tools is also necessary and is offered by relevant and rapidly maturing third-party organizations. (See open.au for details.)
Literary audience
This book is targeted at an introductory industrial level or a senior academic level. It will be of prime interest to methodologists, project managers, process managers and quality assurance professionals who are responsible for implementing software development processes or managing development thereof, in their respective organizations. Students of component-based software development who, on completion of their C++ or Java courses, have realized that languages are not enough for industrial software development, will quickly find that this book answers many of their questions on "practical component development". Thus, this book can be used as a two-day course in an industrial setting, or as part of a one-semester course in an academic environment. Finally, it will be of interest to anyone and everyone involved in modeling software components, who are practising the UML standard, and who wish to start following a process in order to correctly model their requirements and systems, so that they produce +business value+ to the sponsors of their projects.
Mapping to a workshop
It is envisaged that this book will provide invaluable process and modeling-related information to a wide range of audiences. As mentioned before, the material in this book may be used in a two-day industrial training setting or as a course in a university environment. Here, we briefly outline how a two-day workshop can be conducted in conjunction with this book. Please note that the two case studies in this book can be expanded and discussed in detail if more time is available. For instance, if the workshops are conducted with the help of a CASE tool, then the workshop outline provided here will need three or more days to complete. On the other hand, if less time is available only one of two case studies may be used.

Mapping of the chapters in this book to a two-day workshop

--Day Session Presentation and Relevant Comments
discussion workshop chapters
topic

--1 8:30- The UML - basics; Chapter 2 All basic UML notations are described, together with their importance; the need for a process is highlighted - especially its acute need to complement industrial usage of the UML.
10:00 The necessity and insufficiency of the UML

10:30- The OPEN process - Chapter 1 Basic concepts of OPEN - how
12:00 basics; How OPEN it is a +process environment+.
complements the Its relevance in component
UML integration, Internet-based
development, etc., focusing
on OPEN+s +tailorability+.
Together with UML, a
complete IT environment.

1:30- The OPEN artefacts - Chapter 3 Some of the OPEN artefacts -
3:00 Activities, Tasks and especially the ones relevant to
Techniques tothe case study in Chapter 4 -
are discussed in detail as a
preparation for the first case
study.

3:30- Case study 1 - Chapter 4 This session highlights the
5:00 Library management use of OPEN and UML in a
system responsibility-driven design
approach. Participants are
expected to use material
from the previous session
and attempt the process
and designs.

--2 8:30- The OPEN artefacts - Chapter 3 Remaining OPEN artefacts are
10:00 Activities, Tasks and discussed in greater detail,
Techniques especially those required for a
use-case-driven approach as
shown in Chapter 5. Also,

--Day Session Presentation and Relevant Comments
discussion workshop chapters
topic

--2 (cont) OPEN artefacts not discussed
in the book are highlighted.

10:30- Case study 2 - Small Chapter 5 Discuss the problem
12:00 Business Loan System statement; Attempt at
+tailoring+ the OPEN lifecycle.
Create Project Plan,
Requirements Model.

1:30- Case study 2 - Small Chapter 5 Complete the Activities
3:00 Business Loan System of Analysis and Design,
Evaluation.

3:30- Summary and All chapters Use discussion topics at the
5:00 conclusions end of each chapters; Review
and summary; Further
readings, etc.

Semantics
The authors firmly believe in gender-neutral language. Person is therefore used

wherever possible. Quotes and other references have been left untouched.
Terms like programmer and manager, unless otherwise mentioned, represent roles

performed by actors. These terms don+t tie down real people like you and us

who, in a short span of time, can jump from the role of a programmer to a manager

to a director and back. Thus, when we say +a programmer has to implement these

designs+, it implies the role of a programmer which might be filled by a person

today who, in five (or two) years+ time, might be performing the role of a manager

with significantly different responsibilities.
We throughout the text refers not only to the authors, but also includes the

reader. Occasionally, we refers to the general IT community of which the authors

are members. Thus, a statement like +we need to follow a process+ implies all

in the IT community need to follow a process.
Acknowledgements
It is in the nature of things that the sum of parts has something more to it

than a mere arithmetic sum. This is especially true of explaining the concept

of OPEN with UML, as has been attempted here in this book. We are grateful to

a number of individuals who, having written eminent work in this same area,

found it worthwhile to give their time and effort in commenting on our drafts.

Other friends contributed to the drawing and supplying of some of the figures,

reading our work and passing constructive criticisms. We wish to thank them

all, and mention some of them in particular. They are, in alphabetical order

of first names, Alistair Cockburn, Anneke Kleppe, Christopher Biltoft, David

Hazlewood, Errol Thompson, Levi Martinovich, Paresh Shal or Rahul Mohod, Rob

Rist, Shreekanth Sindia, Sid Mishra, Sunil Vadnerkar and Susan Lilly, to name

but a few.
SriPrabhat (S.D.) Pradhan, CEO, Tata Technologies India Limited, has been very

supportive of this work and sees its immense value in promoting software process

discipline in the phenomenal and still rapidly growing software industry in

India. "The new millennium in India can do well with a simple and lucidly

written work like this", he says - and we thank him sincerely for his comments.
We also wish to thank our respective families in their support during our effort.

BH-S: To Ann for her continued support of my book-writing efforts. BU: Thanks

to my wife Asha, daughter Sonki Priyadarshini and son Keshav Raja, as well as

my extended family Girish and Chinar Mamdapur, for all their moral support.
Finally, this work acknowledges all trademarks of respective organizations,

whose names and/or tools have been used in this book. Specifically, we acknowledge

the trademarks of Adaptive-Arts (for SimplyObjects), Computer Associates (for

ParadigmPlus and Process Continuum) and Rational (for ROSE).
Critiques
It will only reflect a healthy state of affairs within the IT world if this

work receives its due share of criticism. We believe that all criticisms have

an underlying rationale and that they should all be accepted in a positive and

constructive vein. All comments on this work, both positive and negative, will

be accepted positively. Thus, to all our prospective critics, whose criticisms

will not only enrich our own knowledge and understanding of the subject discussed

in this book, but also add to the general wealth of knowledge available to the

IT community, we wish to say a big thank you in advance.

brian henderson-sellers &
bhuvan unhelkar
Sydney, January, 2000 0201675129P04062001

BHUVAN UNHELKAR is Director of Internet and Component Technologies at Myriad Solutions (USA, Australia & India), with 18 years of professional IT experience in consulting, training and product development. He is a recipient of the Computerworld Object Developer's Award and has delivered papers, tutorials and workshops at many OT and project management conferences around the world. Bhuvan is also the author of two books and has published many articles in a number of well-recognized industry magazines. Brian Henderson-Sellers is Director of the Centre for Object Technology Applications and Research and Professor of Information Systems at the University of Technology, Sydney. He is author of nine books on object technology and is well-known for his work in Object Oriented methodologies and metamodelling (MOSES, COMMA and OPEN) and in Object Oriented metrics. He was recently voted number 3 in the Who's Who of Object Technology (Handbook of Object Technology, 1999, Appendix N) and, in July 2001, was awarded a DSc by the University of London for his extensive and significant contributions to object-oriented methodologies. 0201675129AB12142001