Open Modeling with UMLby Brian Henderson-Sellers, Bhuvan Unhelkar
Brian Henderson-Sellers Bhuvan Unhelkar
“As you read this book you will find a well-defined and well-honed methodology for managing your own software development processes. Clear explanations of fundamentally difficult concepts make this book a major contribution to the literature and to future standardization in this area” – Richard Soley,… See more details below
Brian Henderson-Sellers Bhuvan Unhelkar
“As you read this book you will find a well-defined and well-honed methodology for managing your own software development processes. Clear explanations of fundamentally difficult concepts make this book a major contribution to the literature and to future standardization in this area” – Richard Soley, Chairman and CEO, Object Management Group.
“I have seen the software industry evolve over the past 33 years and in my opinion process discipline has been one of our most significant lacunae. OPEN with UML provides an extremely solid and powerful base for promoting the software process discipline, offering immense value to the still rapidly growing software industry. The new millennium in my home country of India, as well as worldwide, will benefit greatly from a simple and lucidly written work such as this.” - Prabhat (S.D.)Pradhan, CEO, TATA Technologies India.
OPEN (Object-oriented Process, Environment and Notation) addresses a number of key concerns facing IT professionals today. How do you deal with challenges encountered in migration, component integration, and Internet-based development, as well as higher-level process and project management issues? OPEN is a tailorable, complete ‘process environment’ which gives you the power to easily customize the development process to precisely fit with your individual organization’s needs.
This introductory-level book guides you through the basic concepts that you will need to master for using OPEN process in industry, and to understand the use of the Unified Modeling Language (UML) as its notational element. The authorsadopt a strong practical approach, drawing on their extensive experience and developing their arguments around two detailed case studies. Primarily aimed at software developers needing to use an adaptable process to model with UML, this book will also help project managers and quality managers appreciate the use of a software development process together with a standardized notation.Structure of the book:
Chapter 1 overviews the OPEN process and the appropriate use of the UML within it
Chapter 2 introduces the key aspects of UML, primarily focusing on the notational element
Chapter 3 covers how OPEN supports modeling and discusses the modeling artifacts such as Tasks and Techniques, the tools and processes with which to build software complemented by UML as the notation
Chapters 4 and 5 consist of in-depth case studies: a library management system which illustrates how to use OPEN in a responsibility-driven style of development; and a small business loan system, an example of a use-case-driven large-scale software project for the Web
Read an Excerpt
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 softwaredevelopment, 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 www.open.org.au for details.)
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
--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
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
--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
--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,
1:30- Case study 2 - Small Chapter 5 Complete the Activities
3:00 Business Loan System of Analysis and Design,
3:30- Summary and All chapters Use discussion topics at the
5:00 conclusions end of each chapters; Review
and summary; Further
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.
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).
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 &
Sydney, January, 2000
and post it to your social network
Most Helpful Customer Reviews
See all customer reviews >