In recent years, an evolutionary change has occurred in the way modern systems are developed or, perhaps, we should now say “assembled”. Instead of building systems from the ground up – designing, constructing, and testing every part, thereby incurring time delays and huge costs – modern systems are being assembled from a combination of components to meet the needs of the business. These components or services might have been rented or bought from third-party suppliers, reused from previous systems, or built to provide a special set of services for the solution. The aim is to avoid building most of the solution.

This component-based development strategy can be summed up as “Reuse before you Buy before you Build”. It's the new approach to meet the needs of tomorrow. Interestingly, the UML, as well as 99 percent of this book, works fine with any of these alternatives, including a combination of alternatives. This chapter explains the background of many seemingly odd questions raised by IT people, which might seem to be too early in the project. As we show, components can early on play a key role in the bid/proposal stage of a project.

Yesterday's development approach was for large amounts of time and effort spent in developing basic parts of the system architecture, for example, visual controls, communications interfacing, and so forth with a smaller amount of time and effort spent in project-related activities, that is, delivering solutions, as shown in Figure 6-1.

Business modeling concerns process owners, reengineers, or business analysts with IT specialists in an advisory role. Later, in class modeling and especially in object interaction modeling, IT people become the driving force. Here, in adding rigor to the requirements through use-case modeling, there's a shared effort. Business experts provide the essence of the requirements, while IT specialists provide the structure. Having modeled the business, we now start aligning the system specification – most of it being the functional requirements – to the requirements of our business processes.

A diagram technique for this is very widespread: UML standard use cases that were pioneered some 20 years ago by Ivar Jacobson. Use cases are simply the ways in which the actors use the system. A similar step is natural in any knowledge industry because exact requirements minimize lead time and misunderstandings.

Use Cases

Human-computer interaction (HCI) is a vast field, to which use cases contribute with a practical, down-to-earth technique for the doers. To end users of the planned solution, the user interface often seems to be the entire system. Use cases extend this simplified view by modeling what's going to happen at the user interface, as well as interfaces to other systems. Use cases, interface layout examples, and prototypes complement each other, so they fully define the functional requirements of the system. Any remaining UML diagrams specify the inside/kernel of the system hidden behind that interface.

Yet another book about UML! Since its initial version, the Unified Modeling Language has gone an impressive way in the IT community. Over the past couple of years, we have been loading our bookcase with quite a few UML books. Many of them deal with applying or extending UML for a specific domain: UML for project management, UML for business modeling, UML for Java, real-time UML, UML for components, UML for web applications, and so forth.

This book takes a somewhat different and, in our opinion, long-awaited approach. It goes back to the basics of UML: improving the communication among different stakeholders of a (software) project. As the authors of the book write: “a UML made easy for people who specify, buy, or manage complex software systems”. Many of these stakeholders are non-IT professionals in much need of an easy-to-digest introduction to UML.

Looking back on the IBM SanFrancisco project – one of the real success projects in the field of object-oriented business applications – where we, at IBS, played a central role as initiators and principal development partner to IBM, a key success factor was the alignment among domain experts, sponsors, and object experts – through a minimum set of concepts and techniques.

In addition, this book focuses on the new paradigm in software development: fast delivery of applications based on components sourced from various suppliers.

Now that we've specified the external requirements, we begin mapping our system-to-be by sketching out its internal structure, gradually involving more IT personnel. Involvement of the stakeholders depends on the nature of the system. If the system is to be highly interactive, then much of the hard work has already been done during specifying and defining the use cases. If the system-to-be is more complex than interactive, such as a knowledge base, then you might have to do much more work at this stage, for example, detailing the rules that affect each part of the solution.

We're also dependent on the skills of our IT personnel. Throughout the project, experienced people familiar with both object methodology and conceptual thinking will ask many of the important questions early in the specification stage, whereas new converts will appreciate more input from other stakeholders, including help with first-cut key diagrams.

Because structure issues are key with most enterprise systems, we provide boxes on some advanced constructs, as well as extensive footnotes on details and semi-technical issues. We point out why some peripheral, or seemingly peripheral, questions often emerge during modeling.

Some methodologies encourage a two-step process on defining classes: first, model the business classes (the first cut), and then develop a complete class model. In a lightweight approach, we can view these as two levels of detail, which then gives an indication of the involvement of relevant business expertise.

Software – Yet Another Knowledge Industry

Knowledge industries such as electronics, space, pharmaceuticals, or software are special. On the surface, they're the hotly-argued-upon backbone of the new economy, a concept that's no longer new. In our opinion, it's the approach to business that makes the difference, rather than a company's niche or age. Some old-economy veterans, such as global-automation vendor ABB, have rapidly expanded their R&D initiatives and resources, employing many more IT specialists than many so-called new high-profile IT firms. IT provides a foundation to a variety of current business ideas, including customer-driven manufacturing where a web customer configures the product or even the software guiding an industrial robot in manufacturing the chosen customized product.

Obviously, knowledge industries are more special under the shell than at this slightly superficial mass-media/thematic level. On one hand, they have business processes similar to other industries but, on the other hand, production/operations is a small part of any business dominated by R&D and by marketing the know-how of that organization.

Awareness of knowledge-industry specifics is a project-time saver, both within the software industry itself and with the rapidly increasing number of its customers in the other knowledge industries. Knowledge industries are often interleaved with traditional industry sectors – today, you find computer chips and software in all the flagships of industrialism, from heavy trucks to railways. But, in a high-tech region, the complete knowledge-business value chain can sometimes grow remarkably long without any tangible (“hard”) products whatsoever (Figure 1-1).

Think Big, Start Small, and Sustain the Effort

Most people agree that analysis occurs only when the domain expert is in the room. In our experience, in addition to being present, experts are also supposed to understand the language “spoken” in the room. The language problem has often turned out to be even bigger than that of business-travel logistics. The UML, however, provides many powerful tools to make yourself understood in the room, which come in handy for the frequent visitor. By writing this book, we simply seized the opportunity and packaged much of the substance in a lightweight manner for this purpose.

Implementing UML models (and tools) to specify requirements doesn't take much time. Employing them in a practical approach preshrunk to fit your type of systems takes more training days and practical experience. Finally, adopting a component approach throughout the enterprise can take years of sustained effort, but it's definitely worthwhile.

UML Under Time Constraints

We believe the lightweight style of this book makes it possible for experts from many other areas to approach practical, basic UML. A frequent guest to the landscape of software can view this as a phrase book for the journey, keeping grammar detail at a minimum because many good grammar books already exist for this modeling language.

At the same time, we've provided some hints on cooperation with the hosts and on what parts of the language a guest typically becomes involved with in practice.

The excellent idea of writing a lightweight book on the Unified Modeling Language (UML) wasn't ours, we admit. This idea originated from Milan's customers. Having taught more than a hundred courses and seminars on component approaches to software development and on UML over the past few years, he was repeatedly asked for “UML made easy” for people who specify, buy, or manage complex software systems, yet don't program them. This demand seems logical given the way UML is being used in projects and read of in the success stories – as well as the increasing specification workload in any knowledge industry (see Introduction). However, as we moved on into this book project, both of us became increasingly enthusiastic about the idea, as did Cambridge University Press (CUP). Luckily, a majority of our readers are quite familiar with CUP from their own (variety of) fields; so this book is likely to be seen as accessible in most senses of the word.

Any system specification can state requirements on functionality, usability, reliability, performance, and supportability, as well as legal and technical constraints where relevant. In UML projects, we start from a view of the business – its processes and activities – and move into functionality, incrementing all the remaining, nonfunctional, bullet lists as we go.

Having set the stage with class diagrams, we'll now look more closely at what is likely to happen on that stage. We examine life cycles and (with the assistance of IT staff) interactions between all the small parts within the system.

State Diagrams

Some business entities have interesting life cycles because of real-world regularities and constraints, such as business rules, legislation, laws of nature, and so forth governing their “lives.” Because these business entities are represented by a class, we model this dynamic aspect in a state diagram per class.

In most enterprises, some key business entities have an interesting life cycle, which makes a state diagram necessary. These examples show the key states (life-cycle phases) for certain key entities in different industries:

• Banking: Account (in_credit – overdrawn – blocked – overdrawn and blocked – closed)

• Travel: Reservation (registered – on waiting list – reserved – paid)

• Brokerage, shares, bonds: Order (placed – activated at desired price – deal-confirmed – closed)

• Insurance: Retirement plan (employed – payment-aged – retired – deactivated)

We find such key entities in practically any business. The latter example simply mirrors the life cycle from a retirement plan point of view.

Strengths

A state diagram is a compact, yet quite intuitive, notation. These diagrams are versatile because they can mirror the lifetime dynamics of a rather long “life” in the kernel of an enterprise system, as well as a rather short “life” in a user dialogue or in a real-time system.

Data modeling has been covered thoroughly for decades. Like class diagrams, it provides a structural view. Unlike class diagrams, data modeling omits business-level operations that the proposed system will perform. Most often, it also omits some key relationships, such as generalization, despite the fact that various data-model notations for generalization have been around for almost two decades. Because most data models are on a design level, they already take into account some restrictions posed by the underlying implementation technology (data tables).

Strengths

Data models cope well with the data to be stored in the bottom layer of a system. Therefore, data modeling is a technique suitable later on, during design. The mapping to data models enables modern object-oriented systems to use ordinary relational database engines, which are standard in enterprise systems. In practice, brief previews with Database Administrators are a good idea to coordinate legacy and other systems with our models to come. By the time data modeling becomes really interesting in our project, we already have a more technical focus.

Limitations

Data models omit most of the behavior and business logic. Also, what data modelers call constraints or rules typically turns out to mean special data-related ones (such as rules of referential integrity across data tables), whereas UML includes a more versatile and powerful standard for declaring complex business logic, the UML Object Constraint Language (OCL).

Before modeling the design of the system, a project team typically models the business processes to identify the scope of the planned system and to ensure that any chosen system aligns to the demands of both this business model and business vision.

A variety of possible diagram techniques exist for delivering this business model, as well as possible levels of ambition. With business redesign, a risk occurs of having eyes for nothing else but the modeling and ignoring some real dangers. The hard work isn't about creating a best-of-breed business model; it's about enforcing corporate change within the organization. To remind the reader of these risks, we've made separate box diagrams of the more fancy UML features. Here, lengthy modeling exercises might become a convenient excuse for avoiding challenge and confrontation with the permafrost layers found in many organizations. This challenge and lack of confrontation is a common pitfall in implementing new business practices. Therefore, process innovation methodologies spend little time analyzing the current (as is) processes – often, a quick diagnosis is enough. Instead, we focus on the new business models: the business to be.

Ownership of the business models must remain with the stakeholders and process owners. This avoids the danger of the new processes being seen as the work of the IT department, which can lead to rejection of the models by the process owners. It must be made clear that the IT specialists act only as agents in producing the business models.

Introduction

This appendix contains guidance on ensuring that the re-use of tests and testing materials is achieved between testing phases and testing projects. It includes:

1. ▲ How and when to create a Re-use Pack

2. ▲ A list of the typical contents of a Re-use Pack

3. ▲ Guidance on using Re-use Packs.

Creating a Re-use Pack

At the end of any testing phase, the Test Team Leader (or Development Team Leader during Unit and Integration Testing) should collect copies of a number of items generated during the testing project into a single file (a simple manila folder is usually sufficient for this purpose). This file is termed a Re-use Pack.

The Re-use Pack will be archived with the rest of the project files and can be retrieved subsequently on request from the Testing Manager (or equivalent role).

The contents of the Re-use Pack can be used by other testing projects in order to reduce the effort and cost associated with testing and to improve the consistency and quality of testing.

Examples of the use of Re-use Packs include:

1. ▲ During subsequent testing phases of the same Application Under Test (AUT) (such as re-using some System tests during Acceptance Testing)

2. ▲ In Regression Testing modifications to the same AUT (such as either rerunning a complete System Test or selected elements of the System Test)

3. ▲ Where the AUT is similar or related to another AUT (such as employing existing integration test material when an additional module is added to an existing suite of applications).