IBM SG24-7368-00 User Manual

Front cover

Model Driven Systems Development with Rational Products

Understanding context

Understanding collaborations

Understanding distribution of responsibilities

ibm.com/redbooks

Brian Nolan

Barclay Brown

Laurent Balmelli

Tim Bohn

Ueli Wahli

International Technical Support Organization

Model Driven Systems Development with Rational Products

February 2008

SG24-7368-00

Note: Before using this information and the product it supports, read the information in “Notices” on page ix.

First Edition (February 2008)

This edition applies to IBM Rational Systems Developer, Version 7.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

The team that wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

Chapter 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

The challenges of systems development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

The changed context for systems development . . . . . . . . . . . . . . . . . . . . . . 2

Management of complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Creative/dynamic and transactional complexity . . . . . . . . . . . . . . . . . . . . . . 3

Overview of model-driven systems development . . . . . . . . . . . . . . . . . . . . . . . 4

The benefits of modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Central problems MDSD addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Benefits of model-driven systems development . . . . . . . . . . . . . . . . . . . . . . 8

Core processes of model-driven systems development . . . . . . . . . . . . . . . 13

Prerequisites/required foundational concepts/languages . . . . . . . . . . . . . . 15

How the book is organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Chapter 2. Definitions, design points, and key concepts . . . . . . . . . . . . . 17

Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Artifact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Actor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Locality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Design points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Four basic principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Additional design points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Key concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Model levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Viewpoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Transformation methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Summary: The core MDSD process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Chapter 3. Black-box thinking: Defining the system context . . . . . . . . . . 35

The importance of understanding context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

The system in context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

An important context: Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Usage-driven versus feature-driven system design . . . . . . . . . . . . . . . . . . 38

Actors and boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Primary and secondary actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Questions to discover actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Actors and value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Actors and the system boundary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

I/O entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Use cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Writing a brief description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Actor involvement in use cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Use case flows of events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Level of detail in use case flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Initiation of the use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Using activity diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Understanding collaboration from a black-box perspective . . . . . . . . . . . . . . . 54

Identifying operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Requests: The key to operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Specifying request signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Information in the MDSD model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Message naming: A quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Toward better requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Identifying operations from the sequence diagram . . . . . . . . . . . . . . . . . . . 62

Refactoring operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

More about operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Chapter 4. White-box thinking: Understanding collaboration . . . . . . . . . 69

Operation realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

The logical viewpoint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Operation analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Flowdown to further levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Chapter 5. Understanding distribution of responsibility. . . . . . . . . . . . . . 79

Localities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Localities and systems engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Locality semantics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

iv Model Driven Systems Development with Rational Products

Connection semantics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Localities and nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Localities, services, and interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Design trades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Sequence diagrams with localities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Joint realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Joint realization tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Chapter 6. Tool support for MDSD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Model structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Organizing an MDSD model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Level 0 model organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

MDSD UML Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Stereotypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Levels of decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Logical entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Use cases and operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Distribution entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Creating MDSD artifacts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

UML diagrams for systems modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Preparing the environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Preparing the Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Installing the MDSD plug-in. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Modeling the system as a black box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Modeling the system at level 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Creating a localities diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Chapter 7. MDSD and SysML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

MDSD (RUP SE) as contributor to SysML . . . . . . . . . . . . . . . . . . . . . . . . 144

MDSD with SysML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Basics of SysML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Areas of focus of SysML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Requirements modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Block semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Block definition diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Internal block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Parametrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Behavior modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Contents v

MDSD with SysML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Blocks as basic structural units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Understanding context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Using blocks to stand for systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Requirements and understanding context . . . . . . . . . . . . . . . . . . . . . . . . 163

Understanding collaborations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Understanding distribution of responsibilities . . . . . . . . . . . . . . . . . . . . . . 166

Parametrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Summary of SysML basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Chapter 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Why we build systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Systems engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Systems concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

How does MDSD fit in? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Appendix A. MDSD use case specification template. . . . . . . . . . . . . . . . 181

Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Document Approval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

Use-Case Specification: <Use-Case Name> . . . . . . . . . . . . . . . . . . . . . . . . 185

1 Brief Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

2 Actor Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

3 Preconditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

4 Postconditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

5 Basic Flow of Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

6 Alternative Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

7 Subflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

8 Extension Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

9 Special Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

10 Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Appendix B. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

vi Model Driven Systems Development with Rational Products

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Contents vii

viii Model Driven Systems Development with Rational Products

Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION

PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.

This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.

Trademarks

The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:

developerWorks® IBM® Learning Solutions® Rational®

The following terms are trademarks of other companies:

Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Microsoft, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Other company, product, or service names may be trademarks or service marks of others.

Rational Rose® Rational Unified Process® Redbooks® Redbooks (logo) ®

RequisitePro® RUP® SoDA® WebSphere®

x Model Driven Systems Development with Rational Products

Preface

This IBM® Redbooks® publication describes the basic principles of the Rational® Unified Process® for Systems Engineering, which is IBM Rational’s instantiation of model-driven systems development (MDSD).

MDSD consists of a set of transformations that progressively refine knowledge, requirements, and design of complex systems. MDSD begins with activities and artifacts meant to promote an understanding of the system's context.

Requirements problems often arise from a lack of understanding of context, which, in MDSD, means understanding the interaction of the system with entities external to it (actors), understanding the services required of the system, and understanding what gets exchanged between the system and its actors. Managing context explicitly means being aware of the shifts in context as you go from one model or decomposition level to the next.

MDSD suggests that a breadth-first collaboration based approach across multiple viewpoints is more effective than a traditional depth-first functional decomposition in creating an architecture that will not only meet requirements, but will prove to be more resilient in the face of inevitable change. MDSD also seeks to provide an effective distribution of responsibilities across resources. Joint realization and abstractions such as localities provide an effective and elegant way of accomplishing this.

Finally, the ability to attach attributes and values to modeling entities and the parametric capabilities of SysML provide a basis for doing simulations or other models to meet cost, risk, and other concerns.

The team that wrote this book

This book was produced by a team of specialists from around the world working at the International Technical Support Organization, San Jose Center.

Brian Nolan is a course developer for IBM Software Group, Rational Learning Solutions® and Services, specializing in model-driven development. Prior to his current position, he was the regional practice lead for the Rational Unified Process for Systems Engineering. Dr. Nolan holds a Ph.D. degree in the classics from Ohio State University.

Barclay Brown is an executive consultant in the system engineering practice in IBM Global Business Services. Prior to this, he was the Worldwide Community of Practice leader for Rational Solution Architecture. He leads client engagements in aerospace and defense, system development, and IT enterprise architecture, helping clients transform their engineering organizations using IBM technologies, methods, and tools. Barclay has been a practitioner, consultant, and speaker on system engineering methods for over 8 years. His experience spans some 24 years in project management, system engineering, architectural modeling, and requirements analysis. His current specialization includes model-driven system development, enterprise architecture, estimation methods, and solution architecture. He is the designer of the model-driven system development course, offered by IBM. Barclay holds degrees in electrical engineering, psychology, and business.

Dr. Laurent Balmelli is a manager at IBM in charge of architecting the new generation of offerings and tools for systems engineering and product development. He has been a research staff member at T.J. Watson Research Center and IBM Tokyo Research Labs, and a member of several leadership councils in IBM since 2000. Since 2003, Dr. Balmelli has represented IBM within the SysML standard team and is one of the lead authors of the SysML language specification. He was recently awarded the position of invited professor at Keio University in Tokyo, Japan, where he currently resides.

Tim Bohn is currently the Worldwide Community of Practice Leader for Solution Architecture. Tim has been active in the Systems community for many years, helping customers adopt MDSD in their practice. Tim has been with IBM Rational Software for 12 years, in both technical and management roles. Prior to joining Rational, Tim worked as a software engineer and systems engineer for 16 years. Tim holds a BS and MS degree from the University of Southern California, where he also guest lectures.

xii Model Driven Systems Development with Rational Products

Ueli Wahli is a Consultant IT Specialist at the IBM International Technical

Support Organization in San Jose, California. Before joining the ITSO over 20 years ago, Ueli worked in technical support at IBM Switzerland. He writes extensively and teaches IBM classes worldwide about WebSphere® Application Server and WebSphere and Rational application development products. In his ITSO career, Ueli has produced more than 40 IBM Redbooks. Ueli holds a degree in Mathematics from the Swiss Federal Institute of Technology.

Thank you

We would like to thank the following individuals for their help with this book: 򐂰 Thanks to several authors who participated, but whose contributions we were

not able to include in this edition: Christopher Alderton, Keith Bagley, James

Densmore, Steven Hovater, and Russell Pannone 򐂰 Thanks to the reviewers, especially David Brown, who made extensive

suggestions for improvement throughout

򐂰 Thanks to our managers for their support 򐂰 Thanks to Dr. Murray Cantor, for his thought, leadership, encouragement, and

support

򐂰 Thanks to Yvonne Lyon, IBM Redbooks Editor, for editing this book 򐂰 Thanks to our families for their patience, support, and encouragement

throughout this project

Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbooks publication dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You will have the opportunity to team with IBM technical professionals, Business Partners, and Clients.

Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you will develop a network of contacts in IBM development labs, and increase your productivity and marketability.

Find out more about the residency program, browse the residency index, and apply online at:

ibm.com/redbooks/residencies.html

Preface xiii

Comments welcome

Your comments are important to us!

We want our Redbooks to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways:

򐂰 Use the online Contact us review Redbooks form found at:

ibm.com/redbooks

򐂰 Send your comments in an e-mail to:

redbooks@us.ibm.com

򐂰 Mail your comments to:

IBM Corporation, International Technical Support Organization

Dept. HYTD Mail Station P099

2455 South Road

Poughkeepsie, NY 12601-5400

xiv Model Driven Systems Development with Rational Products

Chapter 1. Introduction

This book is based on work done at IBM Rational by Dr. Murray Cantor and others. In a series of articles for Rational, Dr. Cantor sets out the basic principles of the Rational Unified Process for Systems Engineering (RUP® SE), which is IBM Rational’s instantiation of model driven systems development (MDSD)

This chapter provides an introduction to MDSD, discusses the challenges it was designed to address, and some of the benefits of using it. It provides a core set of concepts to enhance understanding the methodology, and provides an overview of the rest of the book. It also indicates what knowledge is needed as a prerequisite to understanding the material we present.

L. Balmelli, D. Brown, M. Cantor, and M. Mott, Model-driven systems development, IBM Systems Journal, vol 45, no. 3, July/September 2006, pp. 569-585 is the most recent.

http://www.research.ibm.com/journal/sj/453/balmelli.html

See also the series of articles in the Rational Edge, August-October, 2003

The challenges of systems development

As the world moves into the Information Age, the rate of change is increasing. Information is enabling new business models, such as eBay or Amazon.com, and as a result new demands are placed upon the information systems. System complexity is increasing in response to the capability of languages, technology, and global information flow. Coincident with increasing complexity, the pace of change is creating a need to reduce the time required to deliver solutions. Systems development has not kept pace with the demands to deliver more capability in less time. Development teams, using traditional methods, often still fail to deliver capability, which can be fatal to a business in the Information Age.

The changed context for systems development

Computing technology has advanced so that modern systems are thousands of times more powerful than their predecessors. This change removed resource constraints and is changing the approach to system delivery in fundamental ways. Historically teams struggled to deploy as much functionality using as little computer resource as possible. The development team's primary goal was to delivery a working system—cost, especially over a system's life cycle, was a secondary solution. Solutions were often highly customized and proprietary. Development life cycles were longer, and we could regularly schedule updates.

In modern systems, fewer components provide more functionality and therefore have greater code counts. Integration is critical. Our systems must integrate with today and tomorrow's systems now. Within the systems themselves, we must integrate components from a variety of sources. We have many technology choices, and software permeates everything. We have improved software development productivity, but our software has increased tenfold in size must update our systems constantly, yet reduce costs across the life span of the system. We must innovate, but also manage risk; we must meet new technical challenges, but also manage cost.

. We

Within the aerospace and defense markets, the changes are especially dramatic due to the changing nature of threats in conjunction with the changes to technology. During the Cold War, defense agencies and suppliers built large and expensive systems. Because these systems were focused on defending against other high technology threats, the high cost and time to develop was not seen as a major issue. With the threats posed by terrorism, this has changed. Terrorists cause disruption with relatively low cost devices and also change their tactics

David Longstreet, Software Productivity Since 1970, 2002 (http://www.softwaremetrics.com/Articles/history.htm). cited in Cantor, Rational Unified Process for Systems Engineering, Part 1: Introducing RUP SE Version 2.0, The Rational Edge, August 2003

2 Model Driven Systems Development with Rational Products

rapidly. Hence the methods that worked for the Cold War do not work in the current environment. In today's world, defense systems require agility and net-centricity. Systems must become much more agile and capabilities must be deployed more quickly. Our development methods must help us integrate and deploy complex and scalable functionality more quickly.

Management of complexity

Our world is very complex—and becoming more complex daily. manage complexity, before it overwhelms us. Methods for managing complexity can help us prosper in our complex world. Model driven systems development (MDSD) is such a method.

At its core, MDSD is quite simple, but very powerful in its simplicity; extraordinarily complex things are built from simple pieces. wide range of domains, and across a wide range of levels of abstraction from very abstract to very concrete, from business modeling to the modeling of embedded software. MDSD is not just a method for reasoning about and designing software systems, it is a method for reasoning about and designing large complex systems consisting of workers, hardware and software.

The power of MDSD lies in the power of its abstractions.

Creative/dynamic and transactional complexity

In building systems, we are faced with two different kinds of complexity: Creative/dynamic complexity and transactional complexity:

򐂰 We face creative/dynamic complexity because we need teams of people to

work together creatively to architect optimal, robust systems. 򐂰 We face transactional complexity when we try to manage all the components

that make up a complex system.

We must

It applies across a

Transactional complexity can be managed with MDSD.

Cantor, Rational Unified Process for Systems Engineering, Part 1: Introducing RUP SE Version 2.0, The Rational Edge, August 2003,

http://www.ibm.com/developerworks/rational/library/content/RationalEdge/aug03/f_rupse_m c.pdf

Booch covers this point in Object-Oriented Design and Analysis with Applications, 3rd Edition, Addison Wesley, Reading, MA, 2007. When designing a complex software system, it is essential to

decompose it into smaller and smaller parts, each of which we may then refine independently. In this manner, we satisfy the very real constraint that exists upon the channel capacity of human cognition …, page 19.

See Blanchard and Fabryky’s definition: Blanchard and Fabryky, Systems Engineering and Analysis, third edition, Prentice Hall, 1998, quoted by Murray Cantor (see footnote 3).

Chapter 1. Introduction 3

Creative/dynamic complexity can be managed with a governance process. (The governance process must be enabling and not confining.)

Governance more and more becomes a matter of managing risk in an innovative world; of balancing innovation and risk.

Overview of model-driven systems development

Model-driven systems development is the progressive, iterative refinement of a set of models to drive development of your system.

The benefits of modeling

Why do we model? We model to manage complexity, to simplify and abstract essential aspects of a system. We model so that we can test inexpensively before we build, so that we can erase with a pencil before we have to demolish with a sledgehammer.

The models are the architecture—they provide us with multiple views of the system and promote our understanding.

Model-driven systems development leverages the power of modeling to address a set of problems that have plagued systems development. We discuss some of these problems in the sections that follow. MDSD uses a set of transformations to iteratively refine our models and our understanding of the system to be built.

Central problems MDSD addresses

MDSD addresses a core set of system development problems: 򐂰 Overwhelming complexity: Managing complexity by managing levels of

abstraction and levels of detail 򐂰 Not considering appropriate viewpoints: Multiple views to address multiple

concerns 򐂰 System does not meet functional, performance and other system concerns:

Integration of form and function 򐂰 Lack of scalability: Isomorphic composite recursive structures and method to

address scalability

This is an adaptation of a quote from Frank Lloyd Wright: An architect's most useful tools are an eraser at the drafting board, and a wrecking bar at the site

4 Model Driven Systems Development with Rational Products

Managing complexity by managing levels of abstraction and levels of detail

Very often, when dealing with a system of systems, it is difficult to manage the details of system design at different levels of abstraction and detail. Issues at one level of the system get intertwined with issues at another; requirements and design at one level get confused with requirements and design at another.

Think of it this way—if your concern is to travel from Cambridge, England to Rome, Italy, you will be thinking about planes, trains, and automobiles—you probably do not want to be thinking about the wiring in the airplane, or the details of the air control system, or the brake system in the car.

Engineers have a tendency to want to jump down to the details. So when they talk about a system for getting you to your destination, they are as likely to talk about problems with the air control software or the wiring of a piece of hardware as they are to talk about larger-grained issues. This can lead to confusion and errors—diving too deep too early causes integration problems and constrains a solution too early. Requirements are usually best understood in context; jumping levels leads to a loss of context.

In our consulting practice at IBM, we have found it useful to manage the level of abstraction, and to use the appropriate level of detail for the level of abstraction under consideration. Also, we use a formal meta model to provide rigor to our reasoning. decomposition. Model level refers to what phase of our thinking we are in—analysis models should be less detailed than design models, for example. Decomposition level refers to how deep we are in the structural hierarchy of the system.

Briefly, we consider two kinds of levels: model levels and levels of

This is one of the foundational concepts for MDSD. For example, if we are creating a model for analysis, and we want to reason about distribution issues, we should use entities that do not commit us too early to design decisions.

If we are reasoning about the enterprise, we use entities that are appropriate for that level of decomposition, and keep our thinking at that level until it is appropriate to go to the next level of decomposition.

L. Balmelli, J. Densmore, D. L. Brown, M. Cantor, B. Brown, and T. Bohn, Specification for the Rational Unified Process for Systems Engineering—Semantics and Metamodel, Technical Report RC23966, IBM Thomas J. Watson Research Center, Hawthorne, NY 10532, (May 2006)

Localities in MDSD are a good example of this. See the discussion in chapters 2 and 5.

Chapter 1. Introduction 5

Multiple views to address multiple concerns

Our life is complicated, our systems are complex.9 They are built from many parts; often there are many systems working together to accomplish a goal. Our minds do not handle certain kinds of complexity well. In mathematics, when we deal with multi-variable equations, we isolate variables, solve for them, and substitute them back into the equation.

We must provide a mechanism for doing the same thing with systems.

We do the same thing when we design and construct buildings. A building is a system. When we construct a building, we draw up many different plans: One for the electricity, another for the plumbing, different views of the exterior. To address the complexity of our systems, we have to create viewpoints that address multiple concerns. These can vary from system to system. Common viewpoints might include the logical viewpoint (what is the functionality), the distribution viewpoint (where does the functionality take place), the data viewpoint (what domain entities are manipulated), and the worker viewpoint (what human roles are involved). MDSD is explicitly designed to promote the creation of different viewpoints to address different concerns.

Integration of form and function

Function does not occur in a vacuum. It is hosted by physical form. Form exists to carry out function. We build systems to accomplish goals. The systems that we build do not exist in a vacuum—they are physical things. The goals that we have for a system, the functionality that we would like it to exhibit, are realized by forms or structures. The form that a system takes must support the goals that we have for it. Both the functionality of the systems and the systems themselves are constrained: we want something to occur within a specified amount of time; we do not want the system to harm its users or innocent bystanders.

Our systems generally must fit into certain spaces, weigh less than a certain amount. The goal of system design is to create a set of forms that will provide desired functionality within a set of constraints. MDSD ensures that system goals are met by distributing functionality across cooperating entities while reasoning about system performance, and other constraints.

See the discussion on increased complexity in Cantor and Roose, Hardware/software codevelopment using a model-driven systems development (MDSD) approach, The Rational Edge, IBM developerWorks®, December 2005,

http://www.ibm.com/developerworks/rational/library/dec05/cantor/index.html?S_TACT=105AG X15&S_CMP=EDU

See the discussion of abstraction, decomposition, and other topics in Booch et al., Object-Oriented Analysis and Design with Applications, 3rd Edition, Addison-Wesley, 2007, chapters 1 and 2

6 Model Driven Systems Development with Rational Products

Two analogies

Consider two analogies here: Project management and restaurant ownership.

Project management

If you are a project manager, you want to complete your project on schedule and within budget. You have a set of people who will carry out a set of tasks. Your job is to schedule the tasks, assign them to workers, and ensure that the project remains on schedule and finishes within budget. Now consider a system to be a project—not the task of building the system, but the system itself. There is a set of tasks that you want the system to perform, you must distribute those tasks to a set of resources, and you want the tasks to be accomplished within a certain schedule, budget, and other constraints. Reasoning about this distribution problem is a core pillar of MDSD.

Restaurant ownership

Now imagine that you want to start a restaurant. Your goals might be varied and personal, but one of them better be to make a profit. There will be many aspects involved in making a profit, but one of them will be to maximize your throughput—that is, to serve as many quality meals as possible to as many customers as possible. You have many options at your disposal to accomplish this. Each option has a cost associated with it. You have to balance costs with the return inherent in each option.

You might start with a short-order cook in front of a stove, behind a counter with stools for the customers. Your rent is low, because you need very little space. Your salaries are low, because you only have to hire a cook or two. But the cook has to invite the customer to sit down, then take the order, cook it, deliver it, and wash dishes. You soon discover that your one employee can only handle a small number of customers at one time, because he or she has to do virtually everything. Your cook is very good, so word gets around. People come to the diner in droves, but soon get frustrated because of the long wait and lack of seating. Your cook gets burnt out, because he or she has to be constantly on the go. The throughput of your restaurant is limited, as are its profits.

You could add tables and some wait staff. Your rent has gone up because your space has increased, as have your salaries because your staff is increased, but you can increase the output of the cook because he or she can focus on the cooking, and the throughput of the restaurant through the division of responsibilities. Still, you will likely be constrained by the capabilities of the wait staff. Now they have to greet the customers, seat them, take their orders, bring them to the kitchen, retrieve the orders, carry them to the tables, give the customers their bills, collect the money, clear the table, and set it again for the next customers. Customers are frustrated because it takes so long to get seated, get their meals, and get their checks. You risk losing customers. So you add staff to clear and set the tables.

Chapter 1. Introduction 7

You can see how the situation progresses. Many restaurants now have someone to greet the customer, someone to seat them, someone to take their order, someone to pour beverages, someone to cook the order, someone to deliver it to the table, someone to deliver and collect the bill, someone to clear and set tables. The end goals remain the same, the tasks to be performed remain the same, but specialized roles are created to increase the restaurant’s capacity and throughput. However, as noted before, the increased capacity comes at a cost, both in increased salaries and increased management complexity—you now have quite a staff to manage. The cost must be balanced against the increased capacity.

Finally, as opposed to suffering through these options by painful experience and trial and error, you could model the various options and run simulations to learn what could happen and to better understand the implications of your options. You might save yourself a lot of pain, suffering, and the loss of your time and money. You would certainly be better informed about your options, and increased knowledge reduces uncertainty and risk.

MDSD provides ways to reason about these issues—both for systems and for business processes.

Scalability: Isomorphic composite structures and recursion

Systems are composite structures; that is, they are made up of distinct pieces. Not only are they composite structures, they are isomorphic; of the composite structure has a similar or identical structure itself. Composite isomorphic structures lend themselves to being processed recursively. MDSD is scalable because it is a recursive methodology. We can use it to reason about a system of any size. At each level of abstraction (or more precisely, at each model level, and at each level of decomposition)

we perform basically the same activities: understand the context of the system under consideration, understand the collaboration required to achieve the system’s desired goals, and understand how function is distributed across form to achieve system goals within a set of constraints.

that is, each piece

Benefits of model-driven systems development

MDSD provides many benefits. These are some of of the more significant ones:

򐂰 Reduction of risk 򐂰 Enhanced team communication

Isomorphic comes from the Greek ισο (iso) meaning “same” and μορφοσ (morphos) “form”

See Chapter 2 discussion of model levels.

8 Model Driven Systems Development with Rational Products

򐂰 Explicit processes for reasoning about system issues and performing trade

studies

򐂰 Early detection of errors 򐂰 Integration as you go, better architecture 򐂰 Traceability

Reduction of risk

MDSD, in conjunction with appropriate governance, can significantly reduce the risks of system development. The goal of many of the activities of MDSD is to reduce risk. The creation of models is the creation of an architecture. We build models to increase understanding, increased understanding reduces what is unknown both technically in the domain space, and operationally in the project management space—our technical knowledge increases as we complete iterations. At the same time, as we produce concrete deliverables we gain better estimates of time to completion. Increased levels of specificity reduce the variance in a solution space. However, MDSD does not create an artificial level of specificity at any point; the creation of false levels of specificity is often an unrecognized trap leading to false confidence and nasty surprises. Increase in knowledge and reduction of variance are prime risk reducers.

Enhanced team communication

Words can be slippery, elusive, and imprecise. Models can improve communication because they make specific a particular aspect of a system. They also can make system issues

visible through the use of diagrams. Often it

is easier to point to a picture or diagram than it is to describe something in words. The very act of modeling or diagramming can force you to be concrete and specific. We have seen many times in our consulting practice (and many years of experience across many industries) the value of looking at a diagram, set of diagrams, or models. In one customer we worked with, MDSD diagrams were printed out on a plotter, posted in a central lobby, and became the focal point for discussions about the system across a broad set of stakeholders.

Improved communication across a development organization also occurs as a result of MDSD. Engineers in different disciplines have a unifying language they can use to deal with systems issues. Systems engineers can create models that can be handed to the engineers in multiple disciplines (hardware, software, and others) as specification for their design; common use case models can drive system development, testing, and documentation.

Again, see Booch et al., Object-Oriented Analysis and Design with Applications, 3rd Edition, Addison-Wesley, 2007, chapter 1: Models provide a means to reason about a part of the system—necessary due to cognitive limits of the human—while maintaining on overall coherence of the parts

Chapter 1. Introduction 9

Common languages promote common understanding. Unified Modeling Language (UML) and Systems Modeling Language (SysML) derive from the same meta object framework; products in one or the other are likely to be understandable across diverse disciplines. By focusing on usage, collaboration, and distribution, better cross-organizational discussions can take place. Use cases, or common system threads, can unify stakeholders, developers, and users. Beyond systems and software engineering MDSD also provides the framework for reasoning about the integration of concerns across all of the engineering disciplines (for example, thermal, structure, electrical, and navigation).

Explicit processes for reasoning about system issues

Often, many of our design decisions are implicit, the result of many years of experience. While this can be valuable (we do value experience), it can also lead to premature design decisions, or decisions that have not been adequately reasoned through, communicated, tested, or verified.

Complexity also demands explicit processes. A commercial pilot would not think of taking off with a plane full of passengers without a checklist of tasks and safety checks. We follow a repeatable process to improve quality and consistency. By designing the process to address specific issues and risks, we increase our chances for success.

MDSD has been designed to address a specific set of issues in the development of complex systems. Explicit processes also improve communications. Design decisions are taken out of the heads of engineers, documented through models, and progressively refined. In MDSD, process is not just the checking off of steps, but performing repeatable tasks to produce quality artifacts—the quality of the process is judged by the quality of the results—where possible by executable results, that is, a running system or piece of a system.

Early detection of errors

One of the benefits of a well designed process for designing systems is the early detection and resolution of errors. Figure 1-1 shows the cost of errors rising exponentially as they are discovered later in the system development life cycle.

See Walker Royce, Software Project Management: A Unified Framework, Addison-Wesley, 1998. Also Kurt Bittner and Ian Spence, Managing Iterative Software Development Projects, Addison-Wesley, 2006.

10 Model Driven Systems Development with Rational Products

Figure 1-1 High cost of requirements errors

Our experience has shown us that iterating through the production of a set of artifacts improves both the artifacts themselves and the system that is the end product. Each progressive step in the process of defining context, defining collaborations, and specifying the distribution of responsibilities across a set of cooperating entities highlights ambiguities in previous steps, uncovers problems or issues in design, and provides the opportunity to correct mistakes early in the development process at a much lower cost than when they go undetected until later.

MDSD is based on many years of experience across a wide range of customers and projects. We have seen the benefits of well designed activities applied iteratively to a set of concrete artifacts that can be tested.

Integration as you go—better architecture

One of our greatest challenges in developing systems is to integrate functionality successfully, avoid duplication of functionality, and avoid brittle architectures.

Cantor provides the following example:

One image satellite ground support system that is currently being fielded was built with a functional decomposition architecture. The system requirements included the ability to plan missions, control the satellites, and process the collected data for analysis. Accordingly, the developer built three subsystems: mission planning, command and control, and data processing. Each of these

Chapter 1. Introduction 11

subsystems was given to an independent team for development. During the project, each team independently discovered the need for a database with the satellite's orbital history (the satellites can, to some extent, be steered to different orbits as needed). So each team built its own separate database, using separate formats. But the information needs to be consistent for the overall system to operate correctly, and now, the effort required to maintain these three databases is excessive and could easily have been avoided had the team done some kind of object analysis, including a study of the enterprise data architecture.

MDSD seeks to avoid this kind of duplication of functionality by promoting a breadth-first analysis of functionality across a set of collaborating entities. Collaboration, both in the development process, and in system functionality is at the heart of MDSD.

Traceability

Traceability is usually a requirement for the systems that we build. Often, it is an explicit contract item: You the requirements of the system have been implemented and tested. Apart from contract requirements, traceability is needed to do effective fault or impact analysis: If something goes wrong, we must determine what caused the fault; if some requirement must be changed, or added, we must determine what parts of the system will be affected.

Providing traceability can be an onerous requirement. Many times it is done manually at significant cost both in the original development and later through testing and maintenance. Manual methods of providing traceability are difficult to maintain and error-prone.

shall provide traceability matrices to demonstrate how

MDSD can help lighten the burden of providing and then maintaining traceability information. Three of the core processes of MDSD, operations analysis, logical decomposition and joint realization tables, allow for a great deal of the traceability problem to be automated. SysML provides semantic modeling support for traceability. The Rational Software Delivery Platform also provides tools and support for traceability.

Well defined semantics

Talking about the various parts of a system, at their different levels, and talking about their relationships, can be difficult and confusing without well defined semantics. MDSD has a well defined meta model which promotes clarity of discussion (see the aforementioned citation

Cantor, Thoughts on Functional Decomposition, The Rational Edge, April 2003,

http://www.ibm.com/developerworks/rational/library/content/RationalEdge/apr03/Functiona lDecomposition_TheRationalEdge_Apr2003.pdf

12 Model Driven Systems Development with Rational Products

Core processes of model-driven systems development

Model-driven systems development is essentially a simple process, but no less powerful because of its simplicity; in fact, we believe its elegance and simplicity contributes to its power. Furthermore, it is correct in that it is constructed from first principles. It starts with the definition of a system and then provides constructs for defining each of the parts of the system. It also provides an underlying meta model to maintain coherence of the model design as a team reasons about the various parts of the system.

Model-driven systems development is an extension to the Rational Unified Process (RUP). As such, it has a well defined set of roles, activities, and artifacts that it produces. Furthermore it exists as a plug-in for the Rational Method Composer (RMC). Within the context of the Rational Unified Process, however, its essential simplicity is not necessarily immediately apparent within the phases, work flows, and activities. One of the goals of this document is to demonstrate its essential simplicity and power.

The various activities of MDSD are centered around three goals:

򐂰 Defining context 򐂰 Defining collaborations 򐂰 Distributing responsibilities

These activities are carried out at each model level, and at each level of system decomposition. As noted previously, MDSD is a recursive or fractal process—this is part of what makes it simple and powerful.

Defining context

Confusion about context is one of the prime causes of difficulty in system development and requirements analysis. If you are not sure what the boundaries of your system are, you are likely to make mistakes about what its requirements are. Lack of clarity at this point in the development process, if carried through to deployment of the system, can be extraordinarily expensive—systems get delivered that do not meet the expectations of their stakeholders, or faults occur in expensive hardware systems after they have been deployed, and have to be recalled, redesigned, and redeployed. Or the system never gets deployed at all, after millions of dollars have been spent in its development.

Defining context means understanding where the system fits in its enterprise, domain, or ecosystem. Understanding context in a system of systems also means understanding where the various pieces of the system fit and how they relate to each other.

Correspondence with Michael Mott, IBM Distinguished Engineer

Chapter 1. Introduction 13

One of the most difficult areas of defining or understanding context is being aware of context shifts, especially in systems of systems. A context shift occurs when you go from talking about a system within an enterprise to talking about one of its subsystems. At that point, you are considering the subsystem to be a system in its own right. It will have its own set of actors, likely to be other subsystems of the original system under consideration. It is important to manage these context shifts carefully, and to keep straight where in the system you are at a particular point. Technically, we call this set of levels within the system its decomposition levels. box views are one of the ways MDSD manages this context shift.

An explicit transformation between black box and white

Understanding the intended usage of a system is one of the most powerful means of analyzing it and its requirements effectively. Usage drives the functional requirements for the system. What we want the system to do determines its functionality. In MDSD, use cases represent the most important usages of the system. Use cases help define the context of the system; use cases also help put other related requirements into a context.

An essential set of artifacts is produced as we reason about context at any level:

򐂰 Context diagram 򐂰 Use case model 򐂰 Requirements diagram (optional using SysML) 򐂰 Analysis model

Defining collaborations

Brittle, stove-piped architectures are expensive and difficult to maintain or extend. MDSD promotes horizontal integration by emphasizing collaborations at the core of the methodology. Even when we are examining the context of a system, we investigate how it collaborates with other entities in its domain or enterprise. As we analyze candidate architectures and perform trade studies, we investigate how the internal pieces of the system collaborate together to realize its functionality.

Scalability is achieved through system decomposition and operational analysis. The interaction of a set of systems at any given level of abstraction or decomposition determines the interactions of subsequent levels.

Essential list of artifacts:

򐂰 Sequence diagrams 򐂰 Analysis model 򐂰 Package diagram/overview of logical architecture

See the aforementioned citation (footnote 15).

See Chapter 2, “Transformation methods” on page 28, and discussion in Chapters 3 and 4.

Ibid.

14 Model Driven Systems Development with Rational Products

+ 194 hidden pages