Modeling with Technology FrameWork

0RGHOLQJ ZLWK 

7HFKQRORJ\ 

)UDPH:RUN 

Preliminary 

Documentation 

Ptech FrameWork 5.3

Ptech Inc. 

160 Federal Street 

Boston, MA 02110 

Tel: (617) 443-1170 

Fax: (617) 443-1136 

www.ptechinc.com 

© 1998 Ptech Inc. 

All rights reserved. 

Printed in the USA. 

DFD04-533-0000 

This document describes version 5.3 of Ptech Technology FrameWork FrameWork for 

Windows. By receiving this document, you agree that: 

● The information in this document is confidential and cannot be copied or 

reproduced without the written consent of Ptech Inc. 

● This document and its contents cannot be used in the manufacture or 

reproduction of the product described, and the delivery of this document does not 

constitute any right or license to do so. 

The software described in this document is furnished under license and can be used or 

copied only in accordance with the terms of that license. Ptech Inc. is not liable for 

errors in this document or for any damages that may occur in connection with using 

this material. The information contained in this document is subject to change without 

notice. 

Restricted rights notice: Use, duplication, or disclosure by the US Government is 

subject to the restrictions set forth in subparagraph (c) (1) (ii) of the Rights in Technical 

Data and Computer Software clause at DFARS 252.227-7013. 

Ptech and the Ptech logo are trademarks of Ptech Inc. Act! is a registered trdemark of 

Symantec Corporation. CORBA and Object Management Group are registered 

trademarks and Interface Definition Language (IDL), Object Request Broker, OMG, 

ORB, UML, and Unified Modeling Language are trademarks of Object Management 

Group, Inc. Forté is a trademark of Forté Software, Inc. Java is a trademark of Sun 

Microsystems, Inc. Netscape is a trademark of Netscape Communications 

Corporation. Oracle8 is a trademark of Oracle Corporation. Windows is a registered 

trademark of Microsoft Corporation. All other trademarks, trade names, and service 

marks appearing in this document are the property of their respective owners.

About This Book 

&RQWHQWV 

Welcome! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii 

A note about the illustrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii 

A note about the examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv 

Related documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv 

Customer support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi 

Chapter 1: Introduction to FrameWork Models 

What’s in this chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 

About FrameWork models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 

Types of models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 

Format of model descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 

Chapter 2: Cross-model Concepts 

What’s in this chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 

About cross-model concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 

Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 

Model elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 

Model element comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 

Model element dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 

Object constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 

Design changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 

Contents 

iii

Chapter 3: Activity Models (UML) 

Contents 

iv 

About activity models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 

Sample activity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 

Action and activity states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 

Creating an action or activity state . . . . . . . . . . . . . . . . . . . . . . .20 

Forms for action and activity states . . . . . . . . . . . . . . . . . . . . . . .20 

Activity control flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 

Branching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 

Forking and joining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 

Creating control flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 

Form for transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 

Initial and final states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 

Object flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 

Creating object flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 

Form for object flow states . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 

Responsibility for activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 

Chapter 4: Business Architecture Models 

About business architecture models . . . . . . . . . . . . . . . . . . . . . . . . .33 

Sample business architecture diagram . . . . . . . . . . . . . . . . . . . . . . .34 

Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 

Information about activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37 

Creating activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37 

Forms for activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 

Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 

Information about products . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 

Creating products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 

Form for products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 

Consumption and production relationships . . . . . . . . . . . . . . . . . . . .41 

Information about consumption and production relationships . . .42 

Creating consumption and production relationships . . . . . . . . . .42 

Inheritance relationships in business architecture models . . . . . . . .43 

Partitions in business architecture models . . . . . . . . . . . . . . . . .43 

Generalizations in business architecture models . . . . . . . . . . . .45 

Creating inheritance relationships in business architecture models 

46 

Modeling closed systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

Chapter 5: Business Object Models 

Chapter 6: Business Rule Models 

About business object models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 

Sample business object diagram . . . . . . . . . . . . . . . . . . . . . . . . . . .50 

Model classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52 

Information about model classes . . . . . . . . . . . . . . . . . . . . . . . . .53 

Creating model classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 

Forms for model classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 

Associations and attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57 

Information about associations, association ends, and attributes . . 

60 

Creating associations and attributes . . . . . . . . . . . . . . . . . . . . . .61 

N-place associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64 

Symmetric associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 

Ordering associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 

Forms for associations, association ends, and attributes . . . . . .67 

Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69 

Information about operations . . . . . . . . . . . . . . . . . . . . . . . . . . . .70 

Creating operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 

Form for operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72 

Uniqueness constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73 

Information about uniqueness constraints . . . . . . . . . . . . . . . . . .74 

Creating uniqueness constraints . . . . . . . . . . . . . . . . . . . . . . . . .74 

Form for constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 

Inheritance relationships in business object models . . . . . . . . . . . . .76 

Partitions in business object models . . . . . . . . . . . . . . . . . . . . . .76 

Generalizations in business object models . . . . . . . . . . . . . . . . .78 

Intersections in business object models . . . . . . . . . . . . . . . . . . .79 

Information about inheritance relationships . . . . . . . . . . . . . . . . .79 

Creating inheritance relationships in business object models . . .80 

Forms for inheritance relationships . . . . . . . . . . . . . . . . . . . . . . .82 

About business rule models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 

Sample business rule diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 

Business rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86 

Rule sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86 

Rule conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86 

Contents 

v

Chapter 7: Class Models (UML) 

Contents 

vi 

Condition tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86 

Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87 

About class models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89 

Sample class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90 

Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90 

Model classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91 

External classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91 

Interface classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92 

Information about classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92 

Forms for classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93 

Realizes relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93 

Uses relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93 

Associations and attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94 

Creating an association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95 

Form for associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95 

Creating an attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95 

Form for attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96 

Inheritance relationships in class models . . . . . . . . . . . . . . . . . . . . .96 

Partitions in class models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96 

Generalizations in class models . . . . . . . . . . . . . . . . . . . . . . . . .97 

Intersections in class models . . . . . . . . . . . . . . . . . . . . . . . . . . .97 

Forms for inheritance relationships . . . . . . . . . . . . . . . . . . . . . . .97 

Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98 

Creating an operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98 

Forms for operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99 

Decision functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99 

Uniqueness constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99 

Creating a single-function constraint graphically . . . . . . . . . . . .100 

Creating a constraint textually . . . . . . . . . . . . . . . . . . . . . . . . . .101 

Relaxing constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101 

Form for constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 

Chapter 8: Collaboration Models (UML) 

About collaboration models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103 

Sample collaboration diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103

Class roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104 

Creating a class role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104 

Form for class roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105 

Association end roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105 

Creating an association end role . . . . . . . . . . . . . . . . . . . . . . . .105 

Form for association end roles . . . . . . . . . . . . . . . . . . . . . . . . .105 

Chapter 9: Component Models (UML) 

About component models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107 

Sample component diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108 

Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108 

Creating a component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109 

Forms for components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110 

Component interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110 

Creating a component interface . . . . . . . . . . . . . . . . . . . . . . . .110 

Form for component interfaces . . . . . . . . . . . . . . . . . . . . . . . . .110 

Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 

Creating a node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 

Form for nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 

Contains relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 

Depends-on relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112 

Requires relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112 

Communicates-with relationships . . . . . . . . . . . . . . . . . . . . . . . . . .113 

Resides relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 

Chapter 10: Deployment Models (UML) 

About deployment models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115 

Sample deployment diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115 

Executable component instances . . . . . . . . . . . . . . . . . . . . . . . . . .116 

Creating an executable component instance . . . . . . . . . . . . . .116 

Form for executable component instances . . . . . . . . . . . . . . . .117 

Interface instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117 

Node instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 

Creating a node instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 

Form for node instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 

Depends-on relationships in deployment models . . . . . . . . . . . . . .118 

Requires relationships in deployment models . . . . . . . . . . . . . . . . .119 

Contents 

vii

Contents 

viii 

Deploys relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119 

Chapter 11: Instance Interaction Models (UML) 

Chapter 12: Operation Models 

About instance interaction models . . . . . . . . . . . . . . . . . . . . . . . . .121 

Sample instance interaction diagram . . . . . . . . . . . . . . . . . . . . . . .121 

Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121 

Link ends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121 

Message instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122 

About operation models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123 

Sample operation diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124 

Operation model components . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124 

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125 

Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125 

Creating a method and connecting it to its domain class . .125 

Form for methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126 

Chapter 13: Package Models (UML) 

Chapter 14: Process Models 

About package models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 

Sample package diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128 

Packages, systems, and subsystems . . . . . . . . . . . . . . . . . . . . . . .128 

Information about packages, systems, and subsystems . . . . . .131 

Creating packages, systems, and subsystems . . . . . . . . . . . . .132 

Forms for packages, systems, subsystems, and their elements . . . 

134 

About process models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137 

Sample process diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137 

Process model components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138 

Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139 

Creating an operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140 

Forms for operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140 

Operation references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140 

Creating an operation reference . . . . . . . . . . . . . . . . . . . . .141

Chapter 15: Project Models 

Form for operation references . . . . . . . . . . . . . . . . . . . . . . .141 

Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 

Process initiation events . . . . . . . . . . . . . . . . . . . . . . . . . . .141 

Operation completion events . . . . . . . . . . . . . . . . . . . . . . . .142 

Process completion events . . . . . . . . . . . . . . . . . . . . . . . . .142 

Creating an event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143 

Forms for events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143 

Inheritance relationships in process models . . . . . . . . . . . . . . .143 

Partitions in process models . . . . . . . . . . . . . . . . . . . . . . . .143 

Generalizations in process models . . . . . . . . . . . . . . . . . . .144 

Forms for inheritance relationships . . . . . . . . . . . . . . . . . . .144 

Trigger rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144 

Creating a trigger rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145 

Form for trigger rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145 

Objects for operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145 

Base functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146 

Base input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147 

Argument assignments for operations . . . . . . . . . . . . . . . . . . . .149 

Eval functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150 

Eval function input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151 

Decision functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153 

Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154 

Creating a filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154 

Form for filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154 

About project models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155 

Sample project diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155 

Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156 

Project tasks and milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156 

Project teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156 

Implemented strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157 

Chapter 16: Report Layout Models 

About report layout models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159 

Sample report layout diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160 

Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161 

Contents 

ix

Chapter 17: Road Map Models 

Contents 

x 

Creating a report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162 

Form for reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162 

Sample first page of a Document report . . . . . . . . . . . . . . . . . .163 

Prefaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163 

Creating a preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164 

Form for prefaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164 

Sample preface from a Document report . . . . . . . . . . . . . . . . .165 

Chapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165 

Creating chapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166 

Form for chapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 

Sample chapter from a Document report . . . . . . . . . . . . . . . . .167 

Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168 

Creating sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169 

Form for sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170 

Sample section from a Document report . . . . . . . . . . . . . . . . . .170 

Paragraphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171 

Creating paragraphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172 

Focus objects and content functions . . . . . . . . . . . . . . . . . . . . .173 

Text paragraphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .174 

Image/data file paragraphs . . . . . . . . . . . . . . . . . . . . . . . . . . . .176 

List paragraphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178 

Table paragraphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180 

Cross-reference table paragraphs . . . . . . . . . . . . . . . . . . . . . . .183 

About road map models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .187 

Sample road map diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188 

Road map model contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189 

Information about diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . .189 

Creating road map diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . .191 

Form for diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192 

Chapter 18: Sequence Models (UML) 

About sequence models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193 

Sample sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193 

Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194 

Creating an object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194

Form for objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195 

Lifeline points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195 

Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196 

Creating a message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196 

Form for messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196 

Chapter 19: Statechart Models (UML) 

About statechart models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197 

Sample statechart diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197 

States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198 

Creating a state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198 

State actions and internal transitions . . . . . . . . . . . . . . . . . . . . .199 

Form for states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199 

Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199 

Creating a transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200 

Events, actions, and guards . . . . . . . . . . . . . . . . . . . . . . . . . . .200 

Form for transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200 

Synchronization bars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201 

Initial states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201 

Final states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202 

Composite states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202 

Submachine states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203 

Creating a submachine state . . . . . . . . . . . . . . . . . . . . . . . . . . .203 

Form for submachine states . . . . . . . . . . . . . . . . . . . . . . . . . . .204 

Chapter 20: Technology Architecture Models 

About technology architecture models . . . . . . . . . . . . . . . . . . . . . .205 

Sample technology architecture diagram . . . . . . . . . . . . . . . . . . . .205 

Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207 

Information about resources . . . . . . . . . . . . . . . . . . . . . . . . . . .208 

Creating resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209 

Forms for resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .210 

Locations in technology architecture diagrams . . . . . . . . . . . . . . . .212 

Chapter 21: Use Case Models (UML) 

About use case models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .215 

Contents 

xi

Contents 

xii 

Sample use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .215 

Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .216 

Creating a subsystem and connecting it to use cases . . . . . . .217 

Form for subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .218 

Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219 

Creating and relating use cases . . . . . . . . . . . . . . . . . . . . . . . .220 

Forms for use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221 

Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224 

Creating an actor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224 

Form for actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .225 

Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .225 

Communications from actors and use cases . . . . . . . . . . . . . .226 

Bidirectional communications . . . . . . . . . . . . . . . . . . . . . . . . . .227 

Form for communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227 

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229

Welcome! 

$ERXW 7KLV %RRN 

Welcome to Modeling with Technology FrameWork. This book is for 

users of Ptech Technology or Enterprise FrameWork. It describes 

the types of models directly supported by Technology FrameWork 

through the metamodels, diagram types, tool folders, queries, and 

forms shipped with the product. For each type of model, this book 

describes the semantics and usage of the model, presents a sample 

diagram, and gives detailed information about the modeling tools 

and forms you use to create and modify its components. 

To gain the most benefit from this book, you should be familiar with 

FrameWork basics and your Windows operating system. 

A note about the illustrations 

The FrameWork desktop and windows on your screen may differ 

slightly in appearance from the images in this book. The 

differences depend on the FrameWork product you’re using and on 

the environment in which you’re using it. For the purposes of this 

book, these differences are not significant. 


xiii

A note about the examples 

A note about the examples 


xiv 

To the extent possible, the examples in this book are drawn from 

the DemoExample KnowledgeBase distributed with all three 

FrameWork products. You can view the models on which these 

examples are based by opening the Demo Example folder in that 

KnowledgeBase. 

Related documentation 

Information on installing Ptech FrameWork for Windows is 

provided on an installation sheet distributed with the product 

CD-ROM. Additional information about FrameWork and other 

Ptech products is available in: 

■ Learning Business FrameWork and Learning Technology 

FrameWork — Each of these books contains a tutorial that 

introduces you to business process or application development 

modeling and the FrameWork tool. By doing the exercises in 

these books, you become familiar with the modeling process and 

the FrameWork features that support it. 

■ Using FrameWork — This book contains comprehensive 

information on using Ptech Business, Technology, and 

Enterprise FrameWork to capture your business processes and 

design the applications that support them. In this book, you’ll 

find both conceptual and procedural information on topics 

ranging from basic modeling techniques to sharing 

KnowledgeBase information. 

■ Modeling with Business FrameWork — This book describes the 

types of models directly supported by Ptech Business 

FrameWork. In this book, you’ll find information on the 

semantics and usage of each type of model, sample diagrams, 

and detailed information about the modeling tools and forms 

you use to create and modify model components.

Related documentation 

■ Generating C++ Code with FrameWork — This book explains 

how to generate C++ code from models you build using Ptech 

Technology or Enterprise FrameWork. This book also describes 

the C++-specific modeling tools and forms provided with 

FrameWork. 

■ Generating Java Code with FrameWork — This book explains 

how to generate Java code from models you build using Ptech 

Technology or Enterprise FrameWork. This book also describes 

the Java-specific modeling tools and forms provided with 


■ Generating CORBA IDL Code with FrameWork — This book 

explains how to generate Common Object Request Broker 

Architecture (CORBA) Interface Definition Language (IDL) 

code from models you build using Ptech Technology or 

Enterprise FrameWork. This book also describes the CORBAspecific 

modeling tools and forms provided with FrameWork. 

■ Customizing FrameWork — This book provides detailed 

information on using Enterprise FrameWork Professional to 

extend and customize the FrameWork modeling environment to 

meet the needs of your enterprise. Along with instructions for 

creating your own metamodels, diagram types, tool folders, 

queries, forms, and modeling contexts, this book includes an 

integrated set of examples that illustrate a customization 

scenario. 

■ Creating and Customizing ACG Templates — This book 

provides information that enables you to extend the reporting 

and code generation capabilities of the Ptech FrameWork 

products to meet the needs of your enterprise. The ability to 


xv

Customer support 

Customer support 


xvi 

create and customize Ptech Abstract Code Generator (ACG) 

templates is included only in Enterprise FrameWork 

Professional. 

Ptech offers its customers a variety of support services for 

FrameWork and its add-on products. In addition to the 

documentation and online help provided with the products, you can 

obtain information from the following sources: 

■ Formal training is available for all Ptech products. 

Experienced teachers can provide instruction tailored to your 

needs either at Ptech corporate headquarters or at your 

business site. For more information, please contact your Ptech 

sales representative at (800) 955-9345. 

■ The Ptech World Wide Web site provides access to up-to-date 

information on Ptech Inc. and the FrameWork family of products. 

You can browse the Ptech Web site at http://www.ptechinc.com. 

■ Technical support for Ptech products is available by telephone 

Monday through Friday between 9:00 a.m. and 6:00 p.m. 

Eastern time. To speak with a member of the Ptech Technical 

Support team, call (617) 443-1170 ext. 403. Alternatively, you 

can fax your questions to Ptech Technical Support at (617) 443- 

1136 or send email to support@ptechinc.com.

,QWURGXFWLRQ WR 

)UDPH:RUN 0RGHOV 

What’s in this chapter 

Ptech FrameWork is a powerful, object-oriented modeling tool that 

lets you capture, manage, analyze, and make full use of the 

knowledge capital of your enterprise. Its extensible, metamodelbased 

infrastructure ensures that you can model both business and 

application systems to the level of detail you choose, using the 

approach you prefer. 

This chapter contains general information about FrameWork 

models. It includes an overview of the types of models FrameWork 

directly supports and explains how information about models is 

presented in the remainder of this book. 

If you have Enterprise FrameWork Professional, you can create 

new types of models and the tools to build them. For information 

on creating your own model types, see Customizing FrameWork. 

About FrameWork models 

1 

Models and metamodels A FrameWork model is a structured representation of objects 

relevant to a specific view of a particular knowledge domain. Each 

model is built from a predefined set of semantic constructs. These 

semantic building blocks, as well as the rules and constraints that 


1

Types of models 


2 

govern their creation, are defined in one or more metamodels. A 

metamodel is a special type of class model that defines the 

constructs that can be used in other models. The classes in a 

metamodel are called metaclasses. For an introduction to objects 

and classes, see the discussion of FrameWork foundation concepts 

in Using FrameWork. For more information about metaclasses, see 

Customizing FrameWork. 

The FrameWork products come with metamodels that support a 

wide variety of types of models. Each metamodel specifies the 

semantics of a particular knowledge domain (or portion of a 

knowledge domain), such as strategic planning, use case modeling, 

or C++ class definition. Some of these metamodels describe the 

semantics of Unified Modeling Language (UML) models, as 

specified by the Object Management Group (OMG). 

Building models With FrameWork, you typically use graphical modeling tools to 

create the basic components of a model and then add detail and 

depth through the use of forms, dialog boxes, and additional 

models. The graphical representation of the model (that is, the 

diagram) is only one way of viewing it and can contain as much or 

as little detail as you choose. 

For more information on the mechanics of building models, see 

Using FrameWork. 

Directly-supported models To support your modeling work, FrameWork provides a variety of 

diagram types, each associated with one or more tool folders. Each 

diagram type corresponds to a type of model whose semantics are 

defined in the FrameWork metamodels. Models for which 

FrameWork provides a diagram type and modeling tools are called 

directly supported models. 


The table below lists the types of models that are directly supported 

by Ptech Business, Technology, and/or Enterprise FrameWork. For


each type of model, the table provides a brief description and 

indicates the metamodels that define the model semantics. Full 

descriptions of these model types and their components are in the 

documents noted after each description. 

Model type Description Supporting metamodels 

Activity 

(UML) 

Business 

architecture 

Business 

object 

Business 

relationship 

Describes the flow of activities in a process 

and, optionally, identifies objects that flow 

into and out of those activities — Modeling 

with Technology FrameWork 

Identifies core business activities of an 

enterprise, the resources they consume, 

and the products they produce — Modeling 

with Business FrameWork and Modeling 


Defines types of objects and identifies their 

associations, attributes, and operations — 

Modeling with Business FrameWork and 

Modeling with Technology FrameWork 

Describes peer and supplier-client 

relationships between accountable parties 

— Modeling with Business FrameWork 

Business rule Describes conditions that, when true, 

result in the occurrence of particular 

actions — Modeling with Business 

FrameWork and Modeling with Technology 

FrameWork 

■ Capability 

Management 

■ UML Activity 

■ UML Statechart 

■ Business Architecture 


Management 

■ Class Type Hierarchy 

■ Operation 

■ Implementation 

■ Ptech Foundation 

■ Enterprise Relationship 

■ Enterprise Structure 

■ Rule Modeling 

■ UML Request and 

Action 


3


continued 


C++ class Defines classes for a C++ application and 

identifies their properties, 

interrelationships, and operations — 

Generating C++ Code with FrameWork 

Class (UML) Defines types of objects and identifies their 

associations, attributes, and operations — 


Collaboration 

(UML) 

Describes the relationships between the 

objects that participate in or are otherwise 

affected by an interaction and identifies 

the communications that occur through 

these relationships — Modeling with 

Technology FrameWork 


4 

■ C++ Class 

■ C++ Parameterized 

Class 


■ Common Language 

Class 

■ Data Type Hierarchy 


■ Language Extension 

Supporting Objects 

■ Operation 






■ Operation 


■ UML Backbone 

■ UML Relationship and 

Dependency 

■ UML Collaboration

continued 

Component 

(UML) 

Deployment 

(UML) 

Distributed 

class 

Identifies software components, the 

dependent and containing relationships 

among them, and the functionality they 

require from one another — Modeling with 


Describes the run-time implementation of 

a software system — Modeling with 


Defines interface, implementation, and 

other types of classes for a CORBA 

application and identifies their properties, 

interrelationships, and operations — 

Generating CORBAL IDL Code with 


■ UML Component 

■ UML Deployment 



Enterprise 

activity 

Breaks down a core process into its 

component activities and identifies the 

parties that have responsibility for those 

activities and the resources they require — 

Modeling with Business FrameWork 



Class 

■ CORBA Class 

■ CORBA Java Database 

Connectivity 

■ CORBA Module 

■ CORBA Partition 





■ Operation 


■ Business Architecture 


Management 



5


continued 


Enterprise 

requirement 

Enterprise 

structure 

Captures internal and external 

requirements that drive the business of an 

enterprise — Modeling with Business 


Identifies organizations, positions, and 

people and describes their reporting 

hierarchy — Modeling with Business 


Forté class Defines classes for a Forté application and 

identifies their associations, attributes, 

and operations and the events they can 

post — Using FrameWork/Forté 

Forté process Describes the sequence and timing of 

operations in a Forté application process — 

Using FrameWork/Forté 


6 

■ Enterprise 

Requirement 

■ Enterprise Location 




Class 


■ Forté Class 

■ Forté Event 

■ Forté Operation 

■ Forté Partitioning 

■ Forté System Class 




■ Operation 


■ Extended Process 

■ Forté Event 


■ Process

continued 

Instance 

interaction 

(UML) 

Presents a specific example of an 

interaction described in a collaboration 

model — Modeling with Technology 




Java class Defines classes for a Java application and 

identifies their associations, attributes, 

and operations — Generating Java Code 

with FrameWork 

Metamodel Defines semantic constructs for building 

other models and specifies the ways in 

which those constructs can relate to each 

other — Customizing FrameWork 

Operation Describes an operation interface, including 

its arguments, return type, and rules for 

method selection — Modeling with 

Business FrameWork and Modeling with 


■ UML Instance and Link 




Class 

■ Java Concepts 

■ Java External Class 

Hierarchy 

■ Java Modifier 


■ Operation 






■ Diagrams and 

Narratives 

■ Operation 


Operation 

■ C++ Operation 

■ CORBA Operation 



7


continued 


Oracle8 Defines classes that correspond to object 

types in an Oracle8 database and identifies 

their associations, attributes, and 

operations — Generating Oracle8 PL/SQL 

Code with FrameWork 

Package 

(UML) 

Defines groupings of model elements for 

configuration, storage, or access purposes 

— Modeling with Business FrameWork and 


Process Describes the control flow of a process as a 

cause-and-effect chain of events and 

operations, with branching to show 

alternative and concurrent processing 

paths — Modeling with Business 




8 




Class 

■ Oracle8 Attribute 


■ Oracle8 Data Types 

■ Oracle8 Extensions 

■ Operation 




■ UML Model 

Management 

■ Java Concept 

■ Project Element 


■ Process 


■ Implementation

continued 

Process step Describes the sequence of actions that 

implements a business activity — 

Modeling with Business FrameWork 


■ Process 


■ Process Step 

■ Workflow 



Project Captures the planning, implementation, 

and progress of a project, as well as the 

sequence tasks it entails — Modeling with 

Business FrameWork and Modeling with 


Report layout Specifies the content and structure of a 

FrameWork Document report — Modeling 

with Business FrameWork and Modeling 


Road map Shows the logical organization of a group of 

models and provides access to the model 

diagrams — Modeling with Business 



Sequence 

(UML) 

Shows the order in which the objects in an 

interaction communicate with each other 

and describes the content of their 

communications — Modeling with 


■ Alternative Process 

■ and Implementation 

■ Project Planning 

■ Project Management 

■ Project Element 

■ Project Requirement 

■ Document Structure 

■ Paragraph Content 

■ Diagrams and 

Narratives 

■ Diagram Relationship 

■ UML Instance and Link 


9


continued 


Statechart 

(UML) 

Strategic 

planning 

Team 

architecture 

Technology 

architecture 

Use case 

(UML) 

Describes the ways in which the objects in 

a class change their state in response to 

external or internal events and conditions 

— Modeling with Technology FrameWork 

Describes the mission of a business 

enterprise and the visions, goals, 

directives, strategies, and projects that 

help realize that mission — Modeling with 

Business FrameWork 

Defines a project team and describes its 

roles, role assignments, and 

responsibilities — Modeling with Business 


Describes technology resources used by 

business activities and identifies the 

dependent and cooperative relationships 

among those resources; also, describes 

hardware and software requirements of an 

application — Modeling with Business 



Describes the types of interactions that can 

occur between a system and the users of 

that system — Modeling with Business 




10 

■ UML Statechart 

■ UML Event 

■ UML Request and 

Action 

■ Strategic Planning 

■ Goals and Objectives 

■ Enterprise 

Requirement 

■ Risk Management 

■ Team Architecture 

■ Resource Information 


Management 

■ Enterprise Location 

■ Resource Effectiveness 

■ UML Use Case 

■ UML Use Case Step

Format of model descriptions 


Except for this chapter and Chapter 2, “Cross-model Concepts,” the 

chapters in this book each contain information about a single type 

of model. These chapters all have the same basic structure and 

present the same kinds of information. 

Each chapter starts with a general information about the model 

type, followed by a sample diagram. This, in turn, is followed by 

sections discussing each type of object used to build models of that 

type. The discussion of each type of object typically includes: 

■ A general description of the object type, including the class to 

which the objects belong and suggested naming conventions. 

■ A list of properties objects of that type can have, along with the 

association end or attribute that implements each property. 

This information is provided to assist in the use of dialog boxes 

such as Edit Properties and Select Association End. The 

properties listed generally do not include inherited properties or 

properties that don’t apply in the context (that is, business or 

OOAD modeling). 

■ Instructions for creating objects of that type. 

■ Forms for viewing and modifying objects of that type. 


11



12

&URVV PRGHO &RQFHSWV 

What’s in this chapter 

The FrameWork metamodels include some concepts that apply 

across a variety of model types. This chapter describes some of 

those concepts. 

About cross-model concepts 

Abstract superclasses Some cross-model concepts are implemented as superclasses of 

lower-level classes that appear in several different metamodels. By 

adding a level of abstraction, these superclasses simplify the 

metamodels, making them easier to understand and, through 

inheritance, imposing consistency on classes that represent similar 

concepts. An example of this kind of superclass is #CLASSIFIER, 

which is described under “Classes” in Chapter 7, “Class Models 

(UML).” 

For an introduction to superclasses and inheritance, see the 

discussion of FrameWork foundation concepts in Chapter 1 of 


2 

Independent concepts Some cross-model concepts are independent of the class hierarchies 

associated with any particular type of model. The classes that 

implement these concepts typically have associations with the kind 


13

Objects 

Objects 

Model elements 


14 

of abstract superclasses described above. Through their 

associations, these classes often facilitate the use of FrameWork for 

analysis. An example of this type of class is #CONSTRAINT, which is 

described under “Object constraints” later in this chapter. For 

more information on using FrameWork for analysis, see Using 


The most basic cross-model concept in FrameWork is the notion of 

an object, which is implemented by the #OBJECT class. Because 

every KnowledgeBase object is an instance of this class, the 

properties of this class apply to all objects. These properties 

include: 

■ The #name attribute, which lets you specify textual 

representations for objects. 

■ The #description attribute and #document and #data files 

association ends, which let you associate descriptive and 

supporting text and application files with objects. 

■ The #contained_in, #diagrams, and #diagrams_anchored 

association ends, which specify the relationships between 

objects and the diagrams in which they appear, their attached 

diagrams, and their anchored diagrams, respectively. You can 

use the Related Diagrams form to view this information for an 

object. 

For more information on the properties listed above, see Using 


Another basic cross-model concept is implemented by the #MODEL 

ELEMENT class. A model can contain many different types of

Model element comments 

objects, some of which are more fundamental than others to its 

construction and meaning. FrameWork reserves the concept of 

model element for the core constructs of a model. These constructs 

typically have names and are not dependent on other objects for 

their existence. Examples of model elements are classes, activities, 

and use cases. 

Objects that are not model elements are usually unnamed and are 

either objectified relationships or other objects that cannot exist 

without the presence of one or more related objects. Examples of 

objects that are not model elements are attributes, consumption 

relationships, and bidirectional communications. 

The #MODEL ELEMENT class is an abstract superclass of a wide 

variety of other classes. When you create an object in any of these 

classes, that object is automatically an instance of #MODEL 

ELEMENT. You can define other individual objects as model 

elements by adding them to the #MODEL ELEMENT class. If you 

have Enterprise FrameWork Professional, you can define an entire 

class of objects as model elements by making the class a subclass of 

#MODEL ELEMENT or any of its subclasses. 

Model element comments 

Information on this topic is not yet available. 

Model element dependencies 

Object constraints 




15

Design changes 

Design changes 


16

$FWLYLW\ 0RGHOV 80/ 

About activity models 

 

3 

Description Activity models describe the flow of activities in processes and, 

optionally, identify objects that flow into and out of those activities. 

This type of model focuses on the dynamic aspects of an enterprise 

or system by showing the transitions from one state of activity to 

the next. Thus, an activity model is a statechart model of a process. 

For more information on statechart models, see Chapter 18, 

“Statechart Models (UML).” 

Activity models serve a variety of purposes. For example, you can 

use them to model standalone workflows, define the control flow of 

operations, or describe the implementation of use cases. 

The semantics and notations for activity models are prescribed by 

UML. For more information on the UML specification for this type 

of model, see the UML documentation made available by the OMG. 

Building activity models To build an activity model, you typically create an activity diagram 

using tools in the UML Activity Diagram Tools tool folder. 

Support Direct support for activity models is provided only in Technology 

and Enterprise FrameWork. 


17

Sample activity diagram 

Sample activity diagram 

Sample diagram The window below contains a sample activity diagram that shows 

the flow of activities for developing a sales order. The name of this 

diagram is Selling Activity Workflow. 

Visit not required The process shown in the Selling Activity Workflow diagram begins 

with the Plan Sales Strategy activity and then takes either of two 

paths, depending on whether a visit is required. If a visit is not 

required, the process moves on to the Provide Detailed Proposal 

activity. The output from this activity is a quoted customer order, 

which then serves as input to the Complete Sales Quote activity. 

This activity, the final one in this particular path, changes the 

quoted order to an approved and accepted order. 


18

Action and activity states 

Visit required If a visit is required, the process can take one of three paths after 

the visit, depending on what, if anything, is requested as a result of 

it. If an order is requested, control flows to the Provide Detailed 

Proposal activity. If more information is requested, control flows to 

the Submit Requested Information activity, from there to the Take 

Follow-up Actions activity, and then to the Provide Detailed Proposal 

activity. If nothing is requested, control flows to the Analyze 

Opportunity Loss activity, which is also a final activity for the 

process. 

Action and activity states 

Action states In an activity model, you can use both action and activity states to 

represent the stages of a process. An action state represents a 

single action that cannot be broken down or interrupted. When 

control passes to an action state, the action occurs, and control 

passes to the next state. The Selling Activity Workflow diagram 

shown above contains five action states: Plan Sales Strategy, Provide 

Detailed Proposal, Visit Account, Provide Detailed Proposal, and Take 

Follow-up Actions. 

Activity states An activity state represents an activity that can be broken down 

into a sequence of lower-level action or activity states. Because it’s 

actually a composite of other states, an activity state typically takes 

longer than an action state to complete and can be interrupted. In 

the Selling Activity Workflow diagram, Complete Sales Quote and 

Analyze Opportunity Loss are activity states. 

Unlike action states, activity states can be associated with entry 

and exit actions, internal transitions, and deferred events. For 

more information on these objects, see “States” in Chapter 18, 

“Statechart Models (UML).” 

Action or activity? The distinction between action and activity states often depends on 

the purpose and scope of the modeling project or on the modeler’s 

point of view. For example, in an activity model describing the 

manual process of performing a credit check, Review Customer 

Credit History might be an action state. However, in the activity 


19

Creating an action or activity state 

Action and activity state 

names 


20 

model detailing the flow of control for an operation in a software 

application, Review Customer Credit History would be an activity 

state that could be broken down into action states such as Retrieve 

Current Customer Credit Rating, and Retrieve Lowest Customer Credit 

Rating, and Compare Current and Lowest Ratings. 

The name of an action or activity state should be a verb phrase that 

clearly indicates what’s happening in the process. Use the simple 

form of the verb, followed by a singular noun to indicate a single 

performance of the action. For examples of action and activity state 

names, look at the Selling Activity Workflow model. 

Creating an action or activity state 

To create an action or activity state: 

1 In the UML Activity Diagram Tools tool folder, click and hold on 

the Action State or Activity State tool, as applicable. 

2 Drag into your activity diagram window and release the mouse 

button where you want to place the action or activity state 

graphic. 

3 Type a name for the action or activity state. Then click on the 

window background to close the edit box. 

Forms for action and activity states 

You can use the Basic State Information form to view and modify 

information about an action or activity state. You can also use the 

Basic Submachine State Information form for an activity state. For 

more information on these forms, see “States” in Chapter 18, 

“Statechart Models (UML).”

Activity control flows 

Branching 

Activity control flows 

In an activity model, the flow of control from one activity or action 

state to the next is represented by a transition. A transition is a 

change from one state of activity to another. Each state can have 

one or more incoming transitions, but typically has only one 

outgoing transition. The outgoing transition can branch or fork to 

represent alternative or concurrent control flows. 

Transitions do not usually have names. 

Decisions A decision is a point at which a control flow branches into two or 

more alternative paths. When the transition from an action or 

activity state leads to a decision, the flow of control passes through 

only one of the transitions coming out of the decision. For example, 

in the Selling Activity Workflow model, the transition from the Plan 

Sales Strategy activity leads to a decision with two branches. 

Control can flow to either branch, but not both, depending on 

whether a visit is required. 

Decisions do not usually have names. 

Guards You can associate each transition out of a decision with a guard. A 

guard is a condition that must be true for control to pass through 

the transition. The name of a guard is the boolean expression that 

describes the condition (that is, an expression that can evaluate to 

either true or false) such as visit required or visit not required. This 

name is usually enclosed in square brackets. 

The guards associated with the transitions coming from a single 

decision should cover all possibilities and should not overlap. If you 

cannot explicitly account for all possibilities, you can associate a 

catchall guard such as else or no other guard is satisfied with one of 

the transitions. 


21

Forking and joining 



22 

You can also associate a guard with a transition that comes directly 

out of an action or activity state. The implication, in this case, is 

that the process does not transition out of the state until the guard 

is satisfied. 

Forks When an action or activity state is followed by two or more states 

that can occur concurrently, the flow of control needs to split into 

multiple, independent paths. Control then flows along each of 

these paths at the same time. The point at which this split occurs 

is called a fork. Forks occur most frequently when different 

entities are responsible for the activities along each path. 

Joins If the paths of a fork are truly concurrent (as opposed to 

alternative), they need to merge back into a single path before the 

process represented by the activity model is complete. The point at 

which these paths merge is called a join. In a well-formed activity 

model, each fork has a corresponding join. 

Synchronization bars Forks and joins are represented by synchronization bars in 

activity diagrams. The synchronization bar for a fork has a single 

incoming transition and two or more outgoing transitions. The 

synchronization bar for a join has two or more incoming transitions 

and a single outgoing transition. Forks and joins do not usually 

have names. 

In the Process Order Workflow diagram below shows an example of 

forking and joining. In this diagram, the upper synchronization 

bars show that the control flow forks after the Pull Ordered Items 

from Stock state. The lower synchronization bar shows that the 

separate paths of the control flow rejoin each other before the Ship 

Package with Packing Slip state.


Nesting forks and joins You can nest forks and joins to any level. The paths coming out of 

any given fork should rejoin each other before joining any paths 

from a preceding fork. The sample activity diagram schematic 

shown below contains two nested forks and joins. 

Fork 

Join 


23

Creating control flows 


Creating a transition 

without a guard 

Creating a transition with a 

guard 


24 

Fork and join 

Fork and join 

Fork and join 

To create a transition without a guard: 


the Next Activity/Action tool. 

2 Drag onto the starting state for the transition and release the 

mouse button. Then click on the ending state for the transition. 

To create a transition with a guard: 


the Next Activity/Action with Guard tool. 

2 Drag onto the starting state for the transition and release the 

mouse button. Then click on the ending state for the transition. 

3 Type the boolean expression for the guard associated with the 

transition. Then click on the window background to close the 

edit box.

Creating a decision To create a decision: 



the Decision tool. 


button where you want to place the decision graphic. 

3 Click on the window background to close the edit box. 

4 Create transitions to and from the decision: 

Creating a fork or join To create a fork or a join: 

● Using the Next Activity/Action or Next Activity/Action with 

Guard tool, create a transition from the starting state to the 

decision. 

● Using the Next Activity/Action with Guard tool, create 

transitions from the decision to each ending state. 


either the vertical or horizontal Synchronization Bar tool. The 

choice of tool depends only on how you want your diagram to 

look. Semantically, these tools are the same. 

Tip 

After creating a vertical or horizontal synchronization bar, 

you can switch its orientation by resizing it. 


button where you want to place the synchronization bar 

graphic. 


4 Create transitions to and from the synchronization bar: 

● For a fork: 


25

Form for transitions 


26 

● Using the Next Activity/Action or Next Activity/Action 

with Guard tool, create a transition from the starting 

state to the synchronization bar. 

● Using the Next Activity/Action tool, create transitions 

from the synchronization bar to each ending state. 

● For a join: 


● Using the Next Activity/Action or Next Activity/Action 

with Guard tool, create transitions from each starting 

state to the synchronization bar. 

● Using the Next Activity/Action tool, create a transition 

from the synchronization bar to the ending state. 

You can use the State Transition Information form to view and 

modify information about a transition. For more information on 

this form, see “Transitions” in Chapter 18, “Statechart Models 

(UML).” 

Initial and final states 

Initial states Every activity model should have an initial state. This state 

indicates a starting point for the process represented by the model. 

A process is never actually in its initial state. Rather, the initial 

state provides an anchor for the transition to the first activity in 

the process. 

Final states Unless an activity model represents a process that loops infinitely, 

it needs to include at least one final state. A final state indicates 

an ending point for the process. As with the initial state, the 

process is never actually in a final state. Rather, the final state 

provides a terminus for the transition out of the last activity in the 

process.

Creating an initial or final 

state 

Object flows 

Moving objects through a 

process 

Initial and final states do not usually have names. 

To create an initial or final state: 

Object flows 


the Initial State or Final State tool, as applicable. 


button where you want to place the initial or final state graphic. 


The objects output by activities in a process often serve as input to 

other activities later in the process. You can add object flows to 

an activity model to identify the objects created, modified, or 

terminated by the activities in it. Object flows show the movement 

of objects through the stages of a process and optionally indicate 

the ways in which the objects change along the way. 

Object flow states Object flows consist of object flow states and flow transitions. An 

object flow state represents an object that is input to or output 

from an activity. This object is an instance of a particular class and 

is, optionally, in a specified state defined for the objects in that 

class. The name of an object flow state is usually the name of the 

class it instantiates, optionally followed by the name of the state 

the object is in. The state name is usually enclosed in square 

brackets. For example, the names of the object flow states in the 

Selling Activity Workflow model are Customer Order [quoted] and 

Approved Order [accepted]. 

To establish the relationships between an object flow state and the 

class and state of the object it represents, you associate the object 

flow state with an instance of the #CLASSIFIER IN STATE class. 

Each object in this class defines a pairing of a class and a state 

defined for the class. 


27

Creating object flows 

Flow transitions A flow transition connects an object flow state to an activity that 

creates, modifies, or terminates the object it represents. A flow 

transition that goes from an action or activity state to the object 

flow state shows that the object is output from the activity. For 

example, the Customer Order [quoted] object flow state in the selling 

activity model is output from the Provide Detailed Proposal action 

state. An object flow state usually has only one incoming transition 

or none if the object is coming from another process. 

Creating object flows 

Creating an object flow 

state 


28 

A flow transition that goes from the object flow state to an action or 

activity state shows that the object is input to the activity. For 

example, the same Customer Order [quoted] object flow state output 

from the Provide Detailed Proposal action state is input to the 

Complete Sales Quote activity state. An object flow state can have 

any number of outgoing transitions, including none. 

The flow transitions to and from an object flow state do not need to 

be connected to sequential states. Any number of action and 

activity states can occur between the state that produces an object 

flow state as output and a state that uses it as input. 

Flow transitions do not usually have names. 

To create an object flow state: 


the Object Flow State tool. 


button where you want to place the object flow state graphic. 

3 Type a name for the object flow state. Then click on the window 

background to close the edit box.

Creating a flow transition To create a flow transition: 

Form for object flow states 


the Flow Transition tool. 

2 Drag onto the starting action, activity, or object flow state for 

the transition and release the mouse button. Then click on the 

ending action, activity, or object flow state for the transition. 

Form for object flow states 

You can use the Basic Object Flow State Information form to view 

and modify information about an object flow state. The sample 

form below shows information about the Customer Order [quoted] 

object flow state in the Selling Activity Workflow model. Notice 

that Customer Order [quoted] is associated with a classifier in state 

that is itself associated with the Customer Order class and the 

Quoted Order state. 

Responsibility for activities 

Activities as capabilities In addition to the sequence of activities in a process, an activity 

model can also specify who has responsibility for those activities. 

Activities are capabilities, so the relationship between an activity 

and the party that has responsibility for it is established through 

the owner association end. For more information on capabilities 

and their owners, see Modeling with Business FrameWork. 


29


Swim lanes In activity diagrams, you use swim lanes to represent ownership 

relationships. Each swim lane is a rectangle that contains one or 

more action or activity states and that is connected to the party 

responsible for them. For example, in the Complete Sales Quote 

Activity diagram shown below, Sales Person is responsible for the 

Determine Total Cost of Order, Call Credit Admin, Give Order Info to 

Credit Admin, and Accept Order activities, while Credit Administrator 

is responsible for the Evaluate Order and Approve Order activities. 

Creating a swim lane To create a swim lane: 


30 


the Capabilities Owned tool.



button. 

3 While holding down the left mouse button, drag a box around 

the action and activity states for which you’re assigning 

responsibility and release the mouse button. 

Tip 

FrameWork doesn’t care if your box encloses transitions, 

object flow states, decisions, or synchronization bars. These 

objects are not capabilities and will not participate in the 

relationship you’re defining. 

4 Click on the party responsible for those activities. 


31



32

%XVLQHVV $UFKLWHFWXUH 

0RGHOV 

About business architecture models 

Description A business architecture model describes the functional composition, 

or architecture, of a business or application system — for example, 

the operational flow of a manufacturing process or the functional 

specification of an order processing application. The model breaks 

a large problem down into its smaller components. It represents 

what happens and why, but not how. 

Building business 

architecture models 

4 

For many modeling projects, the first step is to build a business 

architecture model that represents the higher-level activities of the 

system. This high-level model also serves to define the scope of the 

project. Additionally, a project may require lower-level business 

architecture models that further describe the components of the 

high-level model. 

Tip You can also use business architecture models to model valueadded 

chains for business processes. 

To build a business architecture model, you typically create a 

business architecture diagram using tools in the Business 

Architecture Diagram Tools tool folder and the common toolbar. 

Support Direct support for business architecture models is provided in all 

three FrameWork products. 


33

Sample business architecture diagram 

Sample business architecture diagram 

Sample diagram The window below contains a sample business architecture 

diagram that shows the activities involved in product marketing. 

The name of this diagram is Product Marketing Operations. 

Sales information analysis The Product Marketing Operations diagram shows that one of the 

activities involved in product marketing is analyzing sales 

information. The input to this activity consists of information 

about market demand, the products available for sale, industry 

regulations, and the competition. The output from this activity is 

sales information that’s critical to developing product marketing 

strategies. 

Product promotion and 

development 


34 

Another product marketing activity is product promotion. The 

market demand generated by this activity is part of the information 

used in performing sales information analysis. Information about 

products for sale, on the other hand, is the result of product 

development. This activity is outside the scope of product 

marketing.

Activities 

Activities 

About activities In a business architecture model, activities represent 

responsibilities or, more precisely, actions taken to carry out 

responsibilities. They consume resources (their input) and produce 

products (their output). For example, in the Product Marketing 

Operations model, the Analyze Sales Information activity uses 

resources named Market Demand, Products for Sale, Industry 

Regulations, and Competition and generates output named Critical 

Sales Information. 

Internal and external 

activities 

Many resources, one 

product 

Activities belong to the #ACTIVITY class. 

From the perspective of the Product Marketing Operations model, 

Analyze Sales Information is an internal activity. That is, it falls 

within the scope of what are considered to be product marketing 

operations. 

Business architecture models can also show external activities. 

An external activity is an activity whose performance lies outside 

the scope of the model. Like an internal activity, an external 

activity can also consume resources and produce products. You 

include external activities in business architecture models to show 

the origins of resources consumed by internal activities or the 

consumption of products they produce. For example, the Develop 

Products activity in the Product Marketing Operations model is an 

external activity that produces Products for Sale, which is a resource 

for the Analyze Sales Information activity. 

External activities belong to the #EXTERNAL_AGENT class. 

An activity can consume many resources, but generally should 

produce only one product. By restricting an activity in this way, 

you focus on the purpose of the activity that is most in line with the 

visions and goals of your enterprise or the role of your application. 


35

Activities 

Higher- and lower-level 

activities 


36 

For example, a clothing manufacturer may sell the scrap material 

that results from making clothing, but this is not the primary 

business of the enterprise. The activity model for this enterprise 

would show only Clothing as the product resulting from the activity 

Manufacture Clothing, not Clothing and Scrap Material. 

Some activities include other activities as part of their 

performance. To show this, you can do either of the following: 

■ To show the sequence of lower-level activities that make up a 

higher-level activity, you can use another business architecture 

diagram anchored to the higher-level activity. This subdiagram 

would also show the resources consumed and the products 

produced by the lower-level activities. For more information on 

subdiagrams, see Using FrameWork. 

■ To show one or more of the lower-level activities that make up a 

higher-level activity without showing their sequence, inputs, or 

outputs, you can use a partition or generalization, as described 

under “Inheritance relationships in business architecture 

models” later in this chapter. Alternatively, you can connect 

the lower-level activities to the higher-level activity through the 

super activity association end. This association end, however, 

does not have the full semantics implemented for partitions and 

generalizations. 

Activity names The name of an activity is typically a verb phrase that clearly 

indicates what is being done. Use the simple form of the verb, 

optionally followed by a plural or mass noun to represent the 

general performance of the activity rather than a single instance of 

it. An example of an activity name with a plural noun is Promote 

Products. An example with a mass noun is Analyze Sales 

Information. 

Activity names must be unique within a KnowledgeBase.

Information about activities 

Creating activities 

Information about activities 

In addition to its name and properties as a capability and cost 

element, an activity can have the following properties: 

■ Relationships to products consumed by the activity (#in_ 

consumption association end) 

■ Relationships to products resulting from the activity (#in_ 

production association end) 

■ Lower-level activities that make up the activity (subactivities 

association end) 

■ A higher-level activity that includes the activity (super activity 


To create an internal or external activity: 

1 In the Business Architecture Diagram Tools tool folder, click 

and hold on the Activity or External Activity tool, depending on 

the type of activity you want to create. 

2 Drag into your business architecture diagram window and 

release the mouse button where you want to place the activity 

or external activity graphic. 

3 Type a name for the activity or external activity. Then click on 

the window background to close the edit box. 


37

Forms for activities 

Forms for activities 

The Basic Activity 

Information form 


38 

You can use the Basic Activity Information form to view basic 

information about an activity and to change the activity name or 

the labels on its production relationships (see “Consumption and 

production relationships” later in this chapter). The sample form 

below shows information about the Analyze Sales Information 

activity. 

The Activity Classes form The Activity Classes form lists the classes of objects involved in the 

activity. 

These are the classes that appear in any diagrams anchored to: 

■ The activity itself or any products resulting from it 

■ Any activities or resulting products in any diagrams anchored 

to the activity, its resulting products, or, recursively, any 

activities or resulting products in any diagrams anchored to 

them

Products 

The sample form below lists the classes for the Sell Products 

activity. 

Products 

About products Products are the inputs to and outputs from activities. They can 

be tangible like manufactured products or intangible like satisfied 

customers. 

Products belong to the #PRODUCT class. 

Product names The name of a product is typically a noun phrase. Use a plural or 

mass noun. An example of a product name with a plural noun is 

Products for Sale. An example with a mass noun is Market Demand. 

Information about products 

In addition to its name, a product can have the following properties: 


39

Creating products 

Creating products 

Form for products 


40 

■ Relationships to activities that consume the product (#of_ 

consumption association end) 

■ Relationships to activities that produce the product (#in_ 

production association end) 

To create a product: 


and hold on the Product tool. 

2 Drag into your business architecture diagram window and 

release the mouse button where you want to place the product 

graphic. 

3 Type a name for the product. Then click on the window 

background to close the edit box. 

You can use the Basic Product Information form to view basic 

information about a product and to change the product name or the 

labels on its consumption relationships (see “Consumption and 

production relationships” below). The sample form below shows 

information about the Critical Sales Information product.

Consumption and production relationships 

Consumption and production relationships 

Consumption relationships represent the flow of products being 

consumed by activities. In a consumption relationship, the product 

is a resource for an activity. Production relationships, on the 

other hand, represent the flow of activities producing products. In 

a production relationship, the product is the goal of the activity. 

Consumption relationships belong to the #CONSUMPTION class. 

Production relationships belong to the #PRODUCTION class. 

Consumption and production relationships are usually unnamed. 

They exist only in conjunction with the activities and products they 

relate. Each relationship associates one activity with one product. 


41

Information about consumption and production relationships 

Information about consumption and production 

relationships 

Consumption relationship 

connections 

Production relationship 

connections 


42 

A consumption relationship has connections to: 

■ The product consumed by the activity (#consumes association 

end) 

■ The activity that consumes the product (#consumer association 

end) 

A production relationship has connections to: 

■ The product produced by the activity (#result association end) 

■ The activity that produces the product (#producer association 

end) 

Creating consumption and production relationships 

Creating a consumption 

relationship 

Creating a production 

relationship 

To create a consumption relationship: 


and hold on the Consumption tool. 

2 Drag onto the product that is consumed and release the mouse 

button. 

3 Click on the activity that consumes the product. 

To create a production relationship: 


and hold on the Production tool.

Inheritance relationships in business architecture models 

2 Drag onto the activity that produces the product and release the 

mouse button. 

3 Click on the product that’s produced by the activity. 

Inheritance relationships in business 


Within a business architecture model, you can use partitions and 

generalizations to show more get more specific about activities 

and products. Activity partitions and generalizations represent the 

relationship between a relatively general activity (called the 

superactivity) and more specialized forms of the activity (called 

subactivities). 

Similarly, product partitions and generalizations represent the 

relationship between a relatively general product (called the 

superproduct) and more specific forms of the product (called 

subproducts). 

For information on the classes and associations that implement 

inheritance relationships and on the forms you can use to view and 

modify inheritance relationships, see “Inheritance relationships in 

business object models” in Chapter 5, “Business Object Models.” 

Partitions in business architecture models 

Complete partitions When you partition an activity or product, you specify two or more 

mutually exclusive subactivities or subproducts. A complete 

partition represents a complete division of the superactivity or 

superproduct. In a complete partition, every occurrence of the 

superactivity or superproduct is also an occurrence of one of the 

subactivities or subproducts. 


43

Partitions in business architecture models 


44 

For example, the figure below shows a complete partition of the 

Products for Sale product into subproducts named Hard Goods and 

Services. The fact that the partition is complete means that each 

product for sale is either a hard good or a service. There are no 

products for sale that are neither hard goods nor services. 

Superproduct 

Complete partition 

Subproducts 

Incomplete partitions An incomplete partition represents an incomplete division of a 

superactivity or superproduct. In an incomplete partition, there 

can be occurrences of the superactivity or superproduct that are not 

also occurrences of one of the subactivities or subproducts. 

For example, the figure below shows an incomplete partition of the 

Promote Products activity into subactivities named Run 

Telemarketing Campaign, Run Direct Mail Campaign, and Run 

Advertising Campaign. The fact that the partition is incomplete 

means that there may be promotional activities that involve 

neither telemarketing, direct mail, nor advertising.

Generalizations in business architecture models 

Generalizations in business architecture models 

In a business architecture model, a generalization is a relationship 

between a single superactivity or superproduct and a single 

subactivity or subproduct. An activity or product can participate in 

multiple generalizations, but each one represents a relationship to 

only one other activity or product. Also, each generalization is 

semantically independent of the others (for example, 

generalizations make no statements about mutually exclusivity). 

The figure below shows a product generalization in which the 

superproduct is Services and the subproduct is After-Sale Services. 

Superproduct 

Generalization 

Subproduct 

Superactivity 

Incomplete partition 

Subactivities 


45

Creating inheritance relationships in business architecture models 

Creating inheritance relationships in business 


Creating a partition To create a complete or incomplete partition: 


46 

1 In the common toolbar, select the Complete Partition ( ) or 

Incomplete Partition ( ) tool, as applicable. 


the subactivities or subproducts you want in the partition. 

Then release the mouse button. 

3 Click on the superactivity or superproduct for the partition. 

Creating a generalization To create a generalization between two activities or two products: 

1 In the common toolbar, select the Generalization tool ( ). 

2 Click and hold on the subactivity or subproduct for the 

generalization. 

3 Drag onto the superactivity or superproduct and release the 

mouse button. 

For information on the forms you can use to view and modify 

information about inheritance relationships, see “Forms for 

inheritance relationships” in Chapter 5, “Business Object Models.” 

Modeling closed systems 

Often, the output from a system serves as input to the system as 

well. A system like this is called a closed system. To represent 

such a system, you can use a business architecture model with a 

closed loop. 

The business architecture diagram below shows a closed system. 

In this diagram, the activity Fulfill Orders starts a closed loop. The


product Fulfilled Orders generates income, which becomes capital 

that can be used as a resource for the activity Maintain Inventory. 

This activity provides the stock that allows you to fulfill orders. 


47



48

%XVLQHVV 2EMHFW 0RGHOV 

About business object models 

Description Business object models present a static view of the objects on which 

a system acts. They identify the kinds of objects involved in the 

processes within the system, the interrelationships among the 

objects, and the operations that affect them. In the context of a 

business system, this type of model is often used as a further 

breakdown of an activity or product to define its information 

requirements. For information on activities and products, see 

Chapter 4, “Business Architecture Models.” 

Building business object 

models 

Business object models are similar to class models, which are more 

often used in the context of application development. You can use 

the same classes in both types of models, supplying additional 

information as needed in the OOAD context. Alternatively, you can 

relate classes in business object models to those in class models 

through the refined by association end. For information on class 

models and the refined by association end, see Chapter 7, “Class 

Models (UML).” 

 

5 

To build a business object model, you typically create a business 

object diagram using tools in the Business Object Diagram Tools 

tool folder and the common toolbar. 


49

Sample business object diagram 

Support Direct support for business object models is provided in all three 

FrameWork products. 


Sample diagram The window below contains a sample business object diagram that 

shows the types of objects involved in the process of compensating 

sales representatives for their work. The name of this diagram is 

Compensation Objects. 

Compensation process 

objects 


50 

The Compensation Objects diagram shows that the following types 

of objects are involved in determining the compensation for a sales 

representative: the sales representatives’s territories and the 

revenue goals for those territories and the sales representatives 

compensation package. A compensation package can include 

multiple types of compensations: a base salary, a commission, and 

a bonus. The type of commission a sales representative receives

Business object diagram 

notations 


depends on whether that representative has achieved the quota 

specified for the compensation package. 

The Compensation Objects diagram also shows two of the 

operations that involve sales representatives — opening new 

accounts and taking orders. 

The Compensation Objects diagram shown above uses box 

notation. In box notation, each type of object is represented as a 

box. FrameWork supports an alternative notation for business 

object models called compartment notation. In compartment 

notation, each class is represented by a rectangle divided into three 

sections — one for the class itself, one for the attributes defined on 

the class, and one for the operations defined on the class. Here is 

the same Compensation Objects diagram shown using 

compartment notation. For more information on compartment 

notation, see “Sample class diagram” in Chapter 7, “Class Models 

(UML).” 


51

Model classes 

Model classes 

About classes and model 

classes 


52 

A class is a category of objects that have some properties or 

behaviors in common. The classes of which an object is a member 

determine the behavior of the object and the types of connections it 

can have to other objects. In some methodologies, the equivalent of 

a class is a concept or object type. 

FrameWork supports several types of classes. In a business object 

diagram, however, you typically use only model classes. A model 

class is a class with no language-specific characteristics and no 

specific purpose other than to categorize objects. All the classes in

Information about model classes 

the Compensation Objects model — Sales Rep, Territory, Revenue 

Goal, Compensation Package, and so forth — are model classes. 

Model classes belong to the #MODEL CLASS class. 

Class names The name of a class is typically a singular noun phrase, such as any 

of the class names in the Compensation Objects model. Class 

names must be unique within a KnowledgeBase. 


In addition to its name, a model class can have a variety of 

properties, some of which apply only in an OOAD context. In the 

context of a business system, a model class can have the following 

properties: 

■ Objects in the class (#instances association end). 

■ Association ends, attributes, and queries defined on the class 

(#functions association end). For information on association 

ends and attributes, see “Associations and attributes” later in 

this chapter. For information on using queries, Using 

FrameWork. For information on creating queries, Customizing 


■ Uniqueness constraints defined on the class (#uniqueness_ 

constraints association end). For information on uniqueness 

constraints, see “Uniqueness constraints” later in this chapter. 

■ Partitions and generalizations in which the class is a superclass 

(#partitions_defining association end) or subclass (#partitions_ 

including association end). For information on class partitions 

and generalizations, see “Inheritance relationships in business 

object models” later in this chapter. 

■ Intersections in which the class is a superclass (#intersections_ 

defining association end) or subclass (#intersections_including 


53



54 

association end). For information on class intersections, see 

“Intersections in business object models” later in this chapter. 

■ Operations defined on the class (#operations association end). 

For information about operations, see “Operations” later in this 

chapter. 

■ Operations for which the class is the result type (#opers_ 

producing association end). 

■ Operation arguments that can be assigned objects in the class 

(#arguments association end). 

■ Resources that make use of objects in the class (resources using 

association end). For information on resources, see Chapter 19, 

“Technology Architecture Models.” 

■ Conditions placed on objects in the class by various business 

rules (rule conditions association end). For information on 

business rules, see Modeling with Business FrameWork. 

■ Business rule consequences that create (create actions 

association end) or terminate (delete actions association end) 

objects in the class. For information on business rule 

consequences, see Modeling with Business FrameWork. 

■ Content functions created for association ends and attributes 

defined on the class (function assignments association end). For 

information on content functions, see “Focus objects and content 

functions” in Chapter 16, “Report Layout Models.” 

For information on other properties of model classes, see “Classes” 

in Chapter 7, “Class Models (UML).”

Creating model classes 

Forms for model classes 

The Basic Class 


To create a model class in a business object diagram: 

Creating model classes 

1 In the Business Object Diagram Tools tool folder, click and hold 

on the Model Class tool. 

2 Drag into your class diagram window and release the mouse 

button where you want to place the class graphic. 

3 Type a name for the class. Then click on the window 


You can use the Basic Class Information form to view and modify 

basic information about any type of class, including model classes. 

The sample form below shows information about the Sales Rep 

class. 


55

Forms for model classes 

The Class Instance Count 

form 


56 

You can use the Class Instance Count form to view the number of 

objects in any type of class, including model classes. The sample 

form below shows the number of objects in the Sales Rep class.

Associations and attributes 

About associations and 

association ends 


Associations define the types of connections that can exist 

between objects in a pair of classes. When two classes are related 

by an association, objects in those classes can be connected to each 

other through that association. Associations belong to the 

#ASSOCIATION class. 

An association is implemented by a pair of association ends. 

Each association end is defined on one of the classes involved and is 

a directional mapping from that class (called the source class) to 

the other (called the target class). Association ends belong to the 

#ASSOCIATION END class. 

The two association ends that implement an association are 

inverses of each other. That is, the source class of each is the target 

class of the other. In diagrams, the name of an association end 

appears at the target class end of the assocation graphic. 

In the association between the Sales Rep and Compensation Package 

classes shown below, the compensation package and sales reps 

association ends are inverses of each other. The source class for the 

compensation package association end is Sales Rep; the target class is 

Compensation Package. The source class for the sales reps 

association end is Compensation Package; the target class is Sales 

Rep. 

Source 

Target 

Target 

Source 


57


About attributes Attributes represent object properties that are literal values (that 

is, character strings or numbers). Each attribute is defined on a 

particular class and has a basic type of string (for character strings 

and fractional numbers) or integer (for whole numbers). When you 

assign a noninteger value to an integer attribute, FrameWork 

converts it to an integer. 


58 

Attributes belong to the #ATTRIBUTE class. 

Asserted functions Association ends and attributes are asserted functions. An 

asserted function is a direct mapping of objects in one class to 

objects in another class. While an association end is a mapping 

from one model class to another, an attribute is a mapping of a 

model class to a predefined class of either all possible character 

strings or all possible integers. 

Multiplicity Functions have a property called multiplicity. The multiplicity of 

a function specifies, for a given object in the source class, the 

minimum and maximum numbers of objects in the target class to 

which the object can be connected. If a function has no minimum 

(that is, the minimum is zero) or maximum, it is said to be 

unbounded. 

By default, when you create an association end, it is unbounded. 

When you create an attribute, it has a minimum of zero and a 

maximum of one. 

In diagrams, FrameWork shows the multiplicity of an association 

end after the association end name, using the UML format: 

minimum..maximum 

For example, if the minimum is zero and the maximum is five, 

FrameWork shows the multiplicity as 0..5. 

FrameWork uses an asterisk (*) to show that the multiplicity of a 

function has no upper bound. For example, if the minimum is one 

and the maximum is not set, FrameWork shows the multiplicity as 

1..*. If the minimum and maximum are the same, FrameWork


shows the number only once. For example, if the minimum and 

maximum are both three, FrameWork shows the multiplicity as 3. 

If the association end is completely unbounded, FrameWork shows 

the multiplicity as a single asterisk. 

Since most attributes have a multiplicity of 0..1, FrameWork does 

not show attribute multiplicity in diagrams. 

Variance Another property of functions is called variance. A function is 

either variant or invariant. The value of a variant function can 

change. The value of an invariant function cannot. When you first 

create an object, you need to assign values to its invariant 

functions. Afterwards, the values of these functions cannot change. 

Variant functions belong to the #VARIANT_FUNCTION class. 

Invariant functions belong to the #INVARIANT_FUNCTION class. 

Association end and 

attribute names 

By default, when you create an association end or attribute, it is 

variant. 

For an association end, FrameWork shows invariance by 

thickening the connection graphic at the source class end. In the 

example below, the ordering customer association end, whose source 

class is Customer Order, is invariant. FrameWork does not use any 

special notation to show an invariant attribute. 

While associations are usually not named, association ends and 

attributes are. The name of an association end or attribute is 

typically a noun phrase. Use a singular or plural noun to match the 

multiplicity. For example, a sales representative can have multiple 

territories, so the name of the association end mapping the Sales 

Rep class to the Territory class in the Compensation Objects model 

is plural — territories. On the other hand, a sales representative 

can have only one compensation package, so the name of the 


59

Information about associations, association ends, and attributes 


60 

association end mapping the Sales Rep class to the Compensation 

Package class is singular — compensation package. 

The name of an asosciation end or attribute should reflect its role in 

the model and, in fact, association end names are also called role 

names. Consider, for example, a model with two separate 

associations between the Customer and Customer Contact classes, 

one representing the primary contact, the other the secondary. You 

could name the association ends on the Customer class primary 

contact and secondary contact, respectively, to reflect the roles 

played by the customer contacts. 

Information about associations, association ends, 

and attributes 

Information about 

associations 


association ends and 

attributes 

An association is connected to the association ends that implement 

it through the #functions association end. 

In addition to its name, an association end or attribute can have a 

variety of properties, some of which apply only in an OOAD context. 

In the context of a business system, an association end or attribute 

can have the following properties: 

■ For an association end only, the association it implements 

(#association association end). 

■ The class on which the association end or attribute is defined 

(#source association end). 

■ The lower bound of the multiplicity for the association end or 

attribute (#min_of attribute). 

■ The upper bound of the multiplicity for the association end or 

attribute (#max_of attribute). 

■ Uniqueness constraints in which the association end or 

attribute participates (#uniqueness_constraints association end).

Creating associations and attributes 

For information on uniqueness constraints, see “Uniqueness 

constraints” later in this chapter. 

■ Business rule condition tests that apply to the association end 

or attribute (condition tests association end). For information on 

condition tests, see “Condition tests” in Chapter 6, “Business 

Rule Models.” 

■ Content functions created for the association end or attribute 

(function assignments association end). For information on 

content functions, see “Focus objects and content functions” in 

Chapter 16, “Report Layout Models.” 

For information on other properties of associations, association 

ends, and attributes, see “Associations and attributes” in Chapter 

7, “Class Models (UML).” 


Creating an association To create an association: 

1 In the common toolbar, select the Association tool ( ). 

2 Click and hold on one of two classes in the association (it doesn’t 

matter which one). 

3 Drag onto the second class in the association and release the 

mouse button. 

4 Optionally, edit the names FrameWork automatically assigns to 

the association ends. You can do this either by editing the text 

in place or by using the Graphic Properties dialog box or a form. 

5 Optionally, change the multiplicity and variance of the 

association ends, as described later in this section. 


61


Setting the display of 

association end labels 

Creating an attribute 

graphically 


62 

By default, FrameWork labels association ends with their names 

and multiplicity. You can choose to hide either piece of information 

for any given association. To do this: 

On the popup menu for the association, select Association End 

Label and then: 

● Role Name to display only the names of the association 

ends 

● Multiplicity to display only the multiplicity of the 


● Both to redisplay both the names and multiplicity of the 


To create an attribute graphically: 

1 In the common toolbar, select the String Attribute ( ) or 

Integer Attribute ( ) tool, depending on the type of attribute 

you want to create. 

2 Click and hold on the class on which you want to define the 

attribute. 

3 Drag to where you want to place the attribute graphic and 

release the mouse button. 

4 Type a name for the attribute. Then click on the window 


Creating attributes textually If a class has many attributes, you may find it easier to create them 

textually. You can then see them in your business object diagram 

by switching the class to compartment notation. The attributes you 

create in this way all have a basic type of string. 

Tip 

You can also create attributes graphically and then hide them 

to prevent your diagram from becoming too cluttered. For 

information on hiding objects in diagrams, see Using FrameWork.

To create one or more attributes textually: 


1 Select the class for which you want to create the attributes. 

2 On the Class menu, select Operations and Attributes. 

Alternatively, while holding down the Shift key, double-click on 

the class. 

3 For each attribute you want to create: 

a In the Name field on the Attributes page of the Operations 

and Attributes dialog box, type a name for the new 

attribute. 

b In the Lower and Upper fields in the Multiplicity area, 

specify the lower and upper bounds, respectively, for the 

attribute multiplicity. To make the attribute unbounded, 

type 0 in the Lower field and an asterisk (*) in the Upper 

field. 

c Press the Create button. 

Note 

The Type field in the Operations and Attributes dialog 

box shows the data type of an attribute, not its basic type. The 

data type is meaningful in OOAD modeling. FrameWork itself 

does not constrain attribute values based on the data type. 

4 When you’re done creating attributes, press the OK button. 

Setting multiplicity To set the multiplicity of an association end or attribute: 

On the popup menu for the association end or attribute, select 

Multiplicity. Then select: 

● 0..1 to set the minimum to zero and the maximum to one. 

● 0..n to set the minimum to zero and make the maximum 

unbounded. 


63

N-place associations 


64 

● 1..n to set the minimum to one and make the maximum 

unbounded. 

● 1..1 to set both the minimum and maximum to one. 

● Other to set the minimum or maximum to a number 

greater than one. In the Set Multiplicity dialog box: 

1 In the Lower Bound and Upper Bound fields, specify the 

lower and upper bounds, respectively, for the 

multiplicity. 

2 Press the OK button. 

Setting variance To set the variance of an association end or attribute: 

N-place associations 

Associations between more 

than two classes 

On the popup menu for the association end or attribute, select 

Variance. Then select Variant or Invariant. 

An association in FrameWork relate two classes to each other. 

Some relationships, however, involve objects from more than two 

classes. Such a relationship requires an n-place association, 

where n is the number of participating classes. 

In FrameWork, an n-place association is itself represented by a 

class that has an association with each of the other classes 

involved. For example, the figure below shows a class named 

Financial Security Purchase, which represents a three-place 

association between the classes Buyer, Seller, and Financial Security.

Symmetric associations 

Invariant association ends Each association end in an n-place association must be invariant. 

Thus, each object in the class representing the n-place association, 

in this case Financial Security Purchase, is related to a fixed 

grouping of objects. One such grouping, for example, might be Rock 

Solid Insurance, Inc. (buyer), MacroAssets Mutual, Inc. (seller), 

and AnyCorp Stock (security). A given security purchase can never 

change its objects. It can only be created and terminated. 

Symmetric associations 

Associations with two of the 

same association end 

A symmetric association has an association end that is its own 

inverse. In other words, the association consists of two of the same 

association end. For example, if Mary (an instance of the Person 

class) has a neighbor John, then John (also an instance of the 

Person class) by definition has a neighbor Mary. 


65

Ordering associations 

Creating a symmetric 

association 


66 

To create a symmetric association: 

1 In the common toolbar, select the Association ( ) tool. 

2 Position the cursor on the class for which you’re defining the 

association. 

3 Drag off and then back onto the class. 

4 Release the mouse button. 

Ordering associations 

Inverse association ends 

on one class 

Creating an ordering 

association 

Like a symmetric association, an ordering association involves 

only one class. However, unlike a symmetric association, an 

ordering association consists of two different association ends that 

together impose an order on objects in the class. For example, the 

relationship between parents and their children is represented by 

association ends whose domain and range are both Person. One 

maps people to their parents, the other to their children. 

To create an ordering association on a class: 

1 Create a copy of the class and place it in the same window, near 

the original class graphic. 

2 In the common toolbar, select the Association ( ) tool.

Forms for associations, association ends, and attributes 

3 Click and hold on one copy of the class (it doesn’t matter which 

one). 

4 Drag onto the second copy and release the mouse button. 

5 Delete the graphic for one copy of the class. 

6 In the common toolbar, select the Association ( ) tool. 

7 While holding down the Control key, position the cursor on the 

remaining copy of the class. 

8 Drag off and then back onto the class. 

9 Release the mouse button and the Control key. 

10 In the Select Association End dialog box, select either one of the 

association ends for the ordering association. Then press the 

OK button. 

Forms for associations, association ends, and 

attributes 

The Basic Association 


You can use the Basic Association Information form to view and 

modify information about an association. The sample form below 

shows information about an association between the Sales Rep and 

Compensation Package classes. 


67

Forms for associations, association ends, and attributes 

The Basic Association End 



68 

You can use the Basic Association End Information form to view 

and modify information about an association end. The sample form 

below shows information about the compensation package 

association end defined on the Sales Rep class.

The Basic Attribute 


Operations 

Operations 

You can use the Basic Attribute Information form to view and 

modify information about an attribute. The sample form below 

shows information about the sales quota attribute defined on the 

Compensation Package class. 

About operations Operations define the ways in which processes can act on the 

objects in a class. A class can have any number of operations 

defined for it. The class on which an operation is defined is called 

the operation owner. In the Compensation Objects model, the 

Sales Rep class is the owner for two operations: Take Order and Open 

New Account. 

Internal and external 

operations 

Operations belong to the #OPERATION class. 

Operations can be internal or external. You use an operation model 

to describe the interface of an internal operation. The definitions of 

external operations are outside the scope of the system being 

modeled. 

External operations belong to the #EXTERNAL_OPERATION class. 


69

Information about operations 

Operation results The result of an operation can be the object for which it was 

originally invoked, or it can be another object entirely. For 

example, an operation that computes the net value of an order 

starts with the order and ends with the same order. On the other 

hand, an operation in which a sales representative takes an order 

from a customer starts with a sales representative, but ends with 

an order. The class of objects resulting from the application of an 

operation is called the range class or result type of the operation. 

Operation arguments Some operations require information in addition to that associated 

with their starting object. For example, in order to take an order 

from a customer, a sales representative needs to know who the 

customer is. Operation arguments are placeholders for the 

additional information that an operation needs. Each argument is 

associated with the class whose objects provide the needed 

information. When an operation is executed, its arguments are 

assigned objects from their associated classes. 

Operation names The name of an operation is usually a verb phrase that clearly 

indicates what the object is doing (for example, the Take Order 

operation defined on the Sales Rep class) or what is being done to it 

(for example, the Compute Net Value operation defined on the 

Customer Order class). Use the simple form of the verb, optionally 

followed by a singular noun. 

Information about operations 


70 

In addition to its name, an operation can have a variety of 

properties, some of which apply only in an OOAD context. In the 

context of a business system, an operation can have the following 

properties: 

■ The class on which the operation is defined (#owner association 

end). 

■ The class of objects resulting from the application of the 

operation (#range association end).

Creating operations 

Creating an operation 

graphically 


textually 


■ Additional information required by the operation (#arguments 

association end). 

For more information on these and other properties of operations, 

see “Operations” in Chapter 7, “Class Models (UML).” 

To create an operation in a business object diagram: 


on the Operation or External Operation tool, depending on the 

type of operation you want to create. 

2 Drag onto the class on which you want to define the operation 

and release the mouse button. 

3 Click where you want to place the operation graphic. 

4 Type a name for the operation. Then click on the window 


Tip 

You can also use either operation tool to create an operation 

that’s not connected to a class. Afterwards, you can connect it to its 

owner class either through a form or by using the Line Connect tool 

in the common toolbar. 

You can also create operations textually. To do this: 

1 Select the class for which you want to create the operations. 

2 On the Class menu, select Operations and Attributes. 

Alternatively, while holding down the Shift key, double-click on 

the class. 


71

Form for operations 

Form for operations 

The Basic Operation 



72 

3 For each operation you want to create: 

a In the Name field on the Operations page of the Operations 

and Attributes dialog box, type a name for the new 

operation. 

b Optionally, specify the range class for the operation in the 

Return Type field. 

c Optionally, create arguments for the operation in the 

Arguments field. 

d Press the Create button. 

4 When you’re done creating operations, press the OK button. 

You can use the Basic Operation Information form to view and 

modify basic information about an operation. The sample form 

below shows information about the Take Order operation.

Uniqueness constraints 

About uniqueness 

constraints 


Multiplicity and variance (both of which are described under 

“Associations and attributes” earlier in this chapter) constrain the 

ways in which objects in different classes relate to each other. 

Uniqueness constraints constrain the relationhips between objects 

and the classes they’re in. A uniqueness constraint requires 

each object in a class to be unique for a given combination of one or 

more association end and attribute values. For example, the Sales 

Rep class in the Compensation Objects model has a uniqueness 

constraint requiring that each sales representative be assigned a 

unique set of territories. 

Uniqueness constraints belong to the #UNIQUENESS_CONSTRAINT 

class. 


73

Information about uniqueness constraints 

Nonempty uniqueness 

constraints 


74 

A nonempty uniqueness constraint is a uniqueness constraint 

that applies only to those objects in a class that have a nonnull 

value for each of the functions involved. For example, you could 

place a nonempty uniqueness constraint on the Person class 

requiring that the value of the social security number attribute, if 

present, be unique. This would allow you to create objects in the 

Person class without supplying social security numbers for them 

right away. 

Nonempty uniqueness constraints belong to the #NON_EMPTY_ 

CONSTRAINT class. 

Information about uniqueness constraints 

Uniqueness constraints are usually unnamed and exist only in 

connection with a specific class (#class association end) and 

combination of association ends and attributes (#functions 

association end). Once you create a uniqueness constraint, you 

cannot change the class or combination of association ends and 

attributes specified for it. If you want to modify a constraint in that 

way, you need to terminate and recreate it. 

For more information on uniqueness constraints, see “Uniqueness 

constraints” in Chapter 7, “Class Models (UML).” 

Creating uniqueness constraints 

Creating a single-function 

constraint graphically 

A single-function constraint is a uniqueness constraint that 

involves only one association end or attribute. You can create 

single-function constraints either graphically or textually. To 

create a single-function constraint graphically in a business object 

diagram: 

1 In the Class Diagram Tools tool folder, click and hold on the 

Uniqueness Constraint or Nonempty Uniqueness Constraint 

tool, depending on the type of constraint you want to create.

Creating a uniqueness 

constraint textually 

Form for constraints 


2 Drag onto the class on which you want to define the constraint 


3 Click on the association end or attribute involved in the 

constraint. 

If a uniqueness constraint involves more than one association end 

or attribute, you need to create it textually. To do this: 

1 Select the class on which you want to define the constraint. 

2 On the Class menu, select Constraints. 

3 In the Constraints dialog box: 

a In the Constraint field, type a name for the constraint. 

b Optionally, select Nonempty to create a nonempty 

uniqueness constraint. 

c In the Association Ends and Attributes list, select the 

association ends and attributes involved in the constraint. 


4 Optionally, repeat step 3 to create additional constraints on the 

class. 

5 When you’re done creating constraints, press the Close button. 

You can use the Uniqueness Constraint Information form to view 

and modify information about a constraint. For example, the form 


75

Inheritance relationships in business object models 


76 

below shows information about the uniqueness constraint defined 

on the Sales Rep class. 

Inheritance relationships in business 

object models 

You can use partitions, generalizations, and intersections to define 

inheritance relationships among the classes in a class model. In 

an inheritance relationship, all of the properties (that is, the 

association ends, attributes, operations, and constraints) defined 

for objects in the superclass apply to the objects in the subclass. 

The subclass, however, can have properties that don’t apply to the 

superclass. 

Partitions in business object models 

Complete partitions A partition is a breakout of the objects in a class (the superclass) 

into two or more other mutually exclusive classes (the subclasses). 

Partitions can be either complete or incomplete. In a complete

Partitions in business object models 

partition, each object in the superclass must also be a member of 

one subclass. In the Compensation Objects model, the Commission 

class has a complete partition in which the subclasses are Under- 

Quota Commission and Over-Quota Commission. Any object in the 

Commission class must be either an under-quota commission or an 

over-quota commission. 

Superclass 

Complete partition 

Subclasses 

Complete partitions belong to the #COMPLETE_PARTITION class. 

Incomplete partitions In an incomplete partition, the superclass can have some objects 

that are not in any of the subclasses. In the Compensation Objects 

model, the Compensation class has a complete partition in which the 

subclasses are Bonus, Commission, and Base Salary. Objects in the 

Compensation class can be bonuses, commissions, base salaries, or 

some other type of compensation not represented by any of the 

three subclasses. 

Superclass 

Incomplete partition 

Subclasses 


77

Generalizations in business object models 


78 

Incomplete partitions belong to the #INCOMPLETE_PARTITION 

class. 

Decision functions You can associate a decision function with a complete or 

incomplete partition. A decision function specifies the conditions 

that determine which subclass, if any, each object in the superclass 

belongs to and serves as the basis for dynamic reclassification of 

objects in the subclasses. In the Compensation Objects model, for 

example, the complete partition defined on the Commission class 

has a decision function named Quota Achieved?. For sales 

representatives who achieve their quota, their commission is in the 

Over-Quota Commission class. For those who don’t, their commission 

is in the Under-Quota Commission class. 

The name of a decision function should clearly state the condition 

that determines which subclass each object is in. This often takes 

the form of a singular noun phrase ending with a question mark, 

like Quota Achieved?. Another common way to name a decision 

function is to identify the object property that determines its 

classification. For example, you could create a decision function 

named Compensation Type? for the incomplete partition defined on 

the Compensation class. 

Decision functions belong to the #RUNTIME_ONLY_FUNC class. 

Generalizations in business object models 

A generalization represents an inheritance relationship between 

a single superclass and a single subclass. It is similar to an 

incomplete partition in that the superclass can contain objects that 

are not in the subclass. However, a generalization makes no 

statement of relationship between its subclass and any other 

subclasses of its superclass. For example, you could create a 

generalization in which the Compensation class is a superclass of a 

class named Direct Deposit. Any particular compensation object 

may or may not be in the Direct Deposit class. It can also be in any 

other subclass of Compensation (such as Commission or Base Salary) 

at the same time.

Intersections in business object models 

Like incomplete partitions, generalizations belong to the 

#INCOMPLETE_PARTITION class. 

Intersections in business object models 

An intersection represents an inheritance relationship between 

two or more superclasses and a single subclass. In an intersection, 

the subclass inherits all the properties of each superclass. It also 

can have additional properties of its own. 

The figure below shows a sample intersection in which the 

superclasses are Sales Rep and Manager and the subclass is Sales 

Manager. A sales manager has all the properties of both sales 

representatives and managers. 

Information about inheritance relationships 

Information about partitions 

and generalizations 

Superclass 

Generalization 

Subclass 

Intersection 

Subclass 

Superclasses 

Partitions and generalizations are usually unnamed and can a 

variety of properties, some of which apply only in an OOAD context. 


79

Creating inheritance relationships in business object models 


intersections 


80 

In the context of a business system, a partition or generalization 

can have the following properties: 

■ The superclass of the partition or generalization (#superclass 


■ The subclasses of the partition or generalization (#subclasses 


■ For a partition only, the condition that determines which 

subclass each object is in (#decision_function association end) 

Intersections are usually unnamed and can have the following 

properties: 

■ The superclasses of the intersection (#superclasses association 

end) 

■ The subclass of the intersection (#subclass association end) 

Creating inheritance relationships in business 

object models 

Creating a partition To create a complete or incomplete partition: 

1 In the common toolbar, select the Complete Partition ( ) or 

Incomplete Partition ( ) tool, as applicable. 


the subclasses you want in the partition. Then release the 

mouse button. 

3 Click on the superclass for the partition.

Creating a decision 

function 

Creating inheritance relationships in business object models 

To create a decision function for a partition in a business object 

diagram: 


on the Decision Function tool. 

2 Drag onto the partition graphic and release the mouse button. 

3 Click where you want to place the decision function graphic. 

4 Type a name for the decision function. Then click on the 


Tip 

You can also use the Decision Function tool to create a 

decision function that’s not connected to a partition. Afterwards, 

you can connect it to a partition either through a form or by using 

the Line Connect tool in the common toolbar. 

Creating a generalization To create a generalization between two classes: 

1 In the common toolbar, select the Generalization tool ( ). 

2 Click and hold on the subclass for the generalization. 

3 Drag onto the superclass and release the mouse button. 

Creating an intersection To create an intersection: 

1 In the common toolbar, select the Intersection ( ) tool. 


the superclasses you want in the intersection. Then release the 

mouse button. 

3 Click on the subclass for the intersection. 


81

Forms for inheritance relationships 


The Basic Inheritance 


Intersection Information 

form 


82 

You can use the Basic Inheritance Information form to view and 

modify information about a partition or generalization. The sample 

form below shows information about the partition defined on the 

Commission class 

You can use the Intersection Information form to view and modify 

information about an intersection. For example, the form below 

shows information about the sample intersection shown under 

“Intersections in business object models” earlier in this chapter.



83



84

%XVLQHVV 5XOH 0RGHOV 

About business rule models 

Description Information on this topic is not yet available. 

Building business rule 

models 


Support Direct support for business rule models is provided in all three 


Sample business rule diagram 


 

6 


85

Business rules 

Business rules 

Rule sets 

Rule conditions 

Condition tests 


86 




Information on this topic is not yet available.

Actions 


Actions 


87

Actions 


88

&ODVV 0RGHOV 80/ 

About class models 

 

7 

Description Class models present a static view of the objects on which a system 

acts. They identify the kinds of objects involved in the processes 

within a system, the interrelationships among the objects, and the 

operations that affect them. In the context of a business system, 

this type of model is often used as a further breakdown of an 

activity or product to define its information requirements. In an 

OOAD context, class models define classes for which you can 

generate code. 

Building class models You build class models in class diagram windows, using tools in the 

UML Class Diagram Tools tool folder and the common toolbar. 

For more information on generating code from class models, see 

Generating CORBA IDL Code with FrameWork, Generating C++ 

Code with FrameWork, and Generating Java Code with 


Support Direct support for class models is provided only in Technology and 

Enterprise FrameWork. 


89

Sample class diagram 

Sample class diagram 

Class diagram notations Information on this topic is not yet available. 

Sample diagram using box 

notation 

Sample diagram using 

compartment notation 

Classes 


90 

The window below shows a sample class model. 


A class categorizes objects that have some properties or behaviors 

in common. The classes of which an object is a member determine 

the behavior of the object and the types of connections it can have to

Model classes 

External classes 

Model classes 

other objects. In a class diagram, a class can be a model class, an 

external class, or an interface class. 

A model class is a class with no language-specific characteristics. 

To create a model class: 

1 In the UML Class Diagram Tools tool folder, click and hold on 

the Model Class tool. 

2 Drag to your class diagram window and release the mouse 




An external class is a class that exists outside the scope of the 

class diagram but affects objects within the diagram. 

To create an external class: 


the External Class tool. 

2 Drag to your class diagram window and release the mouse 





91

Interface classes 

Interface classes 


92 

An interface class is a class that defines a set of operations and 

functions but does not implement them. In a class diagram, 

interface classes are implemented by model classes. 

To create an interface class: 


the Interface Class tool. 

2 Drag to the model class that implements the interface and 


3 Click where you want to place the interface class graphic. 

4 Type a name for the interface class. Then click on the window 


Tip 

You can also use the Interface Class tool to create an interface 

class that’s not connected to a model class. Afterwards, you can 

connect it to a model class either through a form or by using the 

Realizes tool or Line Connect tool. 

Information about classes 

■ Operations for which the class is the result type 

(#opers_producing association end). 

■ Operation methods defined for the class (#methods association 

end). 

■ Operation arguments that can be assigned objects in the class 

(#arguments association end).

Forms for classes 

The Basic Class 


The Class Additional 


The Class Instance Count 

form 

Forms for classes 

You can use the Basic Class Information form to view and modify 

information about a class. 

You can use the Class Additional Information form to view and 

modify information about the implementations and signal 

receptions of a class. 

You can use the Class Instance Count form to view and modify 

information about the number of objects contained in a class. 

Realizes relationships 

A realizes relationship connects a model class with the interface 

class it implements. 

To create a realizes relationship: 

Uses relationships 


the Realizes tool. 

2 Drag to the implementing model class and release the mouse 

button. Then click on the interface class implemented by the 

model class. 

A uses relationship connects one class to another that includes its 

behaviors. 

To create a uses relationship: 


the Uses tool. 


93



94 

2 Drag to the using model class and release the mouse button. 

Then click on the class being used. 


About associations An association defines the types of connections that can exist 

between objects in one class and objects in another. An association 

is implemented by a pair of association ends. An association end 

is a named, directional mapping from one class to another. 

About attributes An attribute represents object properties that are literal values. 

Each attribute defined for the objects in a class has a basic type of 

integer or string, depending on which tool you use to create it. 

Associations and attributes are both asserted functions. An 

asserted function maps one class to another. While an association 

maps a class to another class defined in the model, an attribute 

maps a class to a predefined class for the attribute type. In other 

words, the range of an attribute is the class of integers, the class of 

real numbers, or the class of character strings. 

Multiplicity Functions have a property called multiplicity. The multiplicity of 

a function specifies, for a given object in the domain, the minimum 

and maximum numbers of objects in the range that the object can 

be connected to. There are four types of multiplicity: 

■ Equal to or greater than zero (if the maximum is zero or 

unspecified, the number of objects is unconstrained) 

■ Equal to or greater than one (or another specified number) 

■ Zero or one 

■ Exactly one 

On the connecting line that represents an association, the 

multiplicity of each association end is notated at the end attached

Creating an association 

to the domain class. There is no graphical representation for the 

cardinality of an attribute. 

Variance Another property of functions is called variance. A function is 

either variant or invariant. For a given object, the value of a 

variant function can change. The value of an invariant function 

cannot. When you first create an object, you need to assign values 

to its invariant functions. Afterwards, the values of these functions 

cannot change. 

Setting function multiplicity 

and variance 

Creating an association 

To set the multiplicity or variance of an association end or attribute 

in an object model, you can use the Multiplicity and Variance 

options on its popup menu. For details on doing this, see the online 

help. 

To create an association: 

Form for associations 

Creating an attribute 

1 In the common toolbar, select the Association tool. 

2 Click and hold on one of two classes in the association (it doesn’t 

matter which one). 

3 Drag to the second class in the association and release the 

mouse button. 

You can use the Basic Association End Information form to view 

and modify information about an association end. 

To create an attribute: 

1 In the common toolbar, select the tool representing the type of 

attribute you want to create. 


95

Form for attributes 

Form for attributes 


96 

2 Click and hold on the class to which you want to assign the 

attribute. 

3 Drag to where you want to place the attribute graphic and 


4 Type a name for the attribute. Then click on the window 


You can use the Basic Attribute Information form to view and 

modify information about an attribute. 

Inheritance relationships in class models 

Superclasses and 

subclasses 

You can use partitions, generalizations, and intersections to show 

inheritance relationships among the classes in a class model. In 

an inheritance relationship, all of the properties (that is, the 

associations, attributes, and operations) defined for objects in the 

superclass apply to the objects in the subclass. The subclass, 

however, can have properties that don’t apply to the superclass. 

Partitions in class models 

Like activity and product partitions, class partitions can be 

complete or incomplete, and the subclasses in a partition are 

mutually exclusive. In a complete partition, each object in the 

superclass must also be a member of one subclass. In an 

incomplete partition, the superclass can have some objects that are 

not in a subclass. 

To create a partition: 


partition you want to create.

Generalizations in class models 


the subclasses contained in the partition. 

3 Click on the superclass of the partition. 

Generalizations in class models 

A generalization in an class model represents an inheritance 

relationship between a single superclass and a single subclass. 

To create a generalization: 

1 In the common toolbar, select the Generalization tool. 

2 Click and hold on the subclass. 

3 Drag to the superclass and release the mouse button. 

Intersections in class models 

An intersection represents an inheritance relationship between 

two or more superclasses and a single subclass. In an intersection, 

the subclass inherits all the properties of each superclass. 

To create an intersection: 

1 In the common toolbar, select the Intersection tool. 


the superclasses contained in the intersection. Then release the 

mouse button. 

3 Click on the subclass. 


The Basic Inheritance 


You can use the Basic Inheritance Information form to view and 

modify information about an inheritance relationship. 


97

Operations 

The Partition State Flags 


Intersection Information 

form 

Operations 



98 

You can use the Partition State Flags Information form to view and 

modify information about a complete or incomplete partition. 

You can use the Intersection Information form to view and modify 

information about an intersection. 

An operation defines the ways in which processes can act on the 

objects in a class. A class can have any number of operations 

defined for it. Operations can be internal or external. You use an 

operation model to describe the interface of an internal operation. 

The definitions of external operations are outside the scope of the 

system being modeled. 

To create an operation: 


the tool representing the type of operation you want to create. 

2 Drag to the class to which you want to assign the operation and 


3 Click where you want to place the operation graphic. 



Tip 

You can also use either operation tool to create an operation 

that’s not connected to a class. Afterwards, you can connect it to a 

class either through a form or by using the Line Connect tool.

Forms for operations 

The Basic Operation 



You can use the Basic Operation Information form to view and 

modify information about an operation. 

The Operation Body form You can use the Operation Body form to view and modify 

information the body of an operation. 

Decision functions 

You can associate a decision function with a partition in an object 

model, just as you can in process model. The decision function 

determines which subclass, if any, objects in the superclass belong 

to. 

To create a decision function: 


the Decision Function tool. 

2 Drag to the partition graphic and release the mouse button. 





About uniqueness 

constraints 

You can place two kinds of constraints on the objects in a class: 

uniqueness constraints and nonempty uniqueness constraints. A 

uniqueness constraint requires each object in the class to be 

unique for a given combination of one or more association end and 

attribute values. For example, you could define a uniqueness 

constraint requiring each order in the Order class to have a unique 

value assigned to its order number attribute. 


99

Creating a single-function constraint graphically 

Nonempty uniqueness 

constraints 


100 

A nonempty uniqueness constraint is a uniqueness constraint 

that applies only to those objects in a class that have a nonnull 

value for each of the functions involved. For example, you could 

place a nonempty uniqueness constraint on the class Person 

requiring that the value of the social security number attribute, if 

present, be unique. This would allow you to create objects in the 

Person class without supplying their social security numbers right 

away. 

Creating constraints You can create uniqueness constraints textually or, for singlefunction 

constraints, graphically. A single-function constraint is a 

constraint that involves only one association end or attribute. After 

you define a constraint textually, you can represent it graphically 

in your model. 

Modifying constraints Once a constraint is defined, you can change its name, but you 

cannot change the combination of association ends and attributes 

defined for it. If you want to modify a constraint in that way, you 

need to terminate and recreate it. The following sections explain 

how to create, terminate, and relax uniqueness constraints. 

Creating a single-function constraint graphically 

To create a single-function constraint constraint by using the 

Uniqueness Constraint or Nonempty Uniqueness Constraint tool: 


the tool representing the type of constraint you want to create. 

2 Drag to the class on which you want to impose the constraint 


3 Click on the association end or attribute to which the constraint 

applies.

Creating a constraint textually 

Relaxing constraints 

To create a constraint textually: 

Creating a constraint textually 

1 Select the class to which you want to add the constraint. 

2 On the Class menu, select Constraints. 

3 In the Constraints dialog box: 

a In the Constraint field, type a name for the constraint. 

b Optionally, select Nonempty to create a nonempty 

uniqueness constraint. 

c In the Association Ends and Attributes list, select the 

association ends and attributes involved in the constraint. 


About relaxed constraints A uniqueness constraint applies to the class it’s defined on, as well 

as to the classes that inherit from that class. When generating 

code, you may not want the constraint to apply to every class in the 

inheritance hierarchy. Preventing an inherited constraint from 

applying to a class is called relaxing the constraint. 

What you do To relax an inherited constraint on a class: 

1 Open the Object Properties window for the constraint. 

2 Assign the class to the #relaxed_classes association end. 

3 Press the Apply button. 

Note 

Relaxing a constraint for a class applies only to code 

generation. Within FrameWork, the constraint applies to all the 


101




102 

classes in an inheritance hierarchy regardless of whether it is 

relaxed for any of them. 

You can use the Uniqueness Constraint Information form to view 

and modify information about a constraint.

&ROODERUDWLRQ 0RGHOV 

80/ 

About collaboration models 

Description Collaboration models show the relationships between objects that 

participate in or are otherwise affected by interactions. They can 

also specify the communications that pass from one object to 

another by means of these relationships. This type of model can 

help clarify complex interactions by highlighting the role of each 

participating object. 

Building collaboration 

models 

You build collaboration models in collaboration diagram modeling 

windows, using tools in the UML Collaboration Diagram Tools tool 

folder. 

Support Direct support for collaboration models is provided only in 

Technology and Enterprise FrameWork. 

Sample collaboration diagram 


8 


103

Class roles 

Class roles 

Creating a class role 


104 

A class role in a collaboration model is either a specific instance of 

a class or an unnamed, representative instance of a class. 

To create a class role: 

1 In the UML Collaboration Diagram Tools tool folder, click and 

hold on the Class Role tool. 

2 Drag to your collaboration diagram window and release the 

mouse button where you want to place the class role graphic. 

3 Type a name for the class role. Then click on the window 


Form for class roles 

Form for class roles 

You can use the Class Role Information form to view and modify 

information about a class role. 

Association end roles 

An association end role is a connection from one class role to 

another through a particular association. Typically, an association 

end role has the same name as the association end it implements. 

Creating an association end role 

To create an association end role: 

1 In the UML Collaboration Diagram Tools tool folder, click and 

hold on the Association End Role tool. 

2 Drag to one of the two class roles in the association (it doesn’t 

matter which one) and release the mouse button. 

3 Click on the second class role in the association. 

Form for association end roles 

You can use the Association End Information Role form to specify 

the base association end for an association end role, as well as the 

communications that pass from one object to another by means of 

the association. 


105

Form for association end roles 


106

&RPSRQHQW 0RGHOV 80/ 

About component models 

Description Component models identify software components, the dependent 

and containing relationships among them, and the functionality 

they require from each other. A component model can also show 

the types of devices on which software components reside and the 

communication paths between those devices. Using a component 

model, you can represent, for example, the functional composition 

of an application system or the logical distribution of a database 

system. Or you can document the development of a program from 

its source code files to its executable form. 

Building component 

models 

The objects in a component model are generic. For example, a 

component model might include an unnamed, representative PC as 

one of its devices, but it would not include Emma’s PC. To show 

such specific information about software implementations, you can 

use a deployment model instead. 

 

9 

To build a component model, you create a component diagram. You 

use the tools in the UML Component Diagram Tools tool folder to 

lay out the structure of the components graphically in the diagram. 

Then you use forms to supplement the information in your 

diagram. 


107

Sample component diagram 

Support Direct support for component models is provided only in Technology 


Sample component diagram 

Components 


108 


A component is a structural element of a software system. A 

component can be: 

■ A source code component such as a .cpp file containing 

uncompiled C++ statements

Creating a component 

Creating a component 

■ A binary component such as the compiled modules in a class 

library 

■ An executable component such as a runnable application 

like Microsoft Word 

You can also include components that are not specifically identified 

as any of the above. 

To create a component: 

1 In the UML Component Diagram Tools tool folder, click and 

hold on the tool representing the type of component you want to 

create. 

2 Drag to your component diagram window and release the mouse 

button where you want to place the component graphic. 

3 Type a name for the component. Then click on the window 


4 Optionally, create dependent components. To do this: 

a In the UML Component Diagram Tools tool folder, click and 

hold on the tool representing the type of dependent 

component you want to create. 

b Drag to the supporting component you created earlier and 


c Click where you want to place the dependent component 

graphic. 

d Type a name for the component. Then click on the window 



109

Forms for components 

Forms for components 

The Basic Component 


The Element Component 



110 

You can use the Basic Component Information form to view and 

modify information about a component. 

You can use the Element Component Information form to view and 

modify information about the containment of a component in other 

components. 

Component interfaces 

A component interface identifies services provided by one 

component and used by others. 

Creating a component interface 

To create a component interface: 


hold on the Component Interface tool. 

2 Drag to the component that provides the interface and release 

the mouse button. Then click where you want to place the 

component interface graphic. 

3 Type a name for the component interface. Then click on the 


Tip 

You can also use the Component Interface tool to create a 

component interface that’s not connected to a providing component. 

Afterwards, you can connect it to a providing component either 

through a form or by using the Line Connect tool. 

Form for component interfaces 

You can use the Component Interface Information form to view and 

modify information about a component interface.

Nodes 

Creating a node 

Form for nodes 

Nodes 

A node identifies the type of physical device on which components 

reside 

To create a node: 


hold on the Node tool. 

2 Drag to your component diagram window and release the mouse 

button where you want to place the node graphic. 

3 Type a name for the node. Then click on the window 


You can use the Basic Node Information form to view and modify 

information about a node. 

Contains relationships 

A contains relationship identifies components that are included 

in another component. An included component is called a 

subcomponent. 

To create a contains relationship: 


hold on the Component Contains tool. 


111

Depends-on relationships 


112 

2 Drag into your component diagram window and release the 

mouse button. 


the subcomponents. 

4 Click on the component that contains the subcomponents. 

Depends-on relationships 

A depends-on relationship shows how one components supports 

another. In a depends-on relationship, one component requires the 

presence of another in order to function as designed. 

To create a depends-on relationship: 


hold on the Depends On tool. 

2 Drag to the dependent component and release the mouse 

button. 

3 Click on the supporting component. 

Requires relationships 

A requires relationship connects a component to the interface it 

requires from another components. 

To create a requires relationship: 


hold on the Requires tool. 

2 Drag to the component that requires the interface and release 

the mouse button.

3 Click on the interface required by the component. 

Communicates-with relationships 

Communicates-with relationships 

A communicates-with relationship shows the path through 

which one nodes can communicate with another. 

To create a communicates-with relationship: 


hold on the Communicates With tool. 

2 Drag to one of the two nodes in the communicates-with 

relationship (it doesn’t matter which one) and release the mouse 

button. 

3 Click on the second node involved in the communicates-with 

relationship. 

Resides relationships 

A resides relationship connects one or more components to the 

node they run on. 

To create a resides relationship: 


hold on the Resident Component tool. 

2 Drag into your component diagram window and release the 

mouse button. 


the resident components. 

4 Click on the node that the components reside on. 


113

Resides relationships 


114

'HSOR\PHQW 0RGHOV 80/ 

About deployment models 

Description Deployment models show run-time implementations of software 

systems. This type of model is similar to the component model, 

except that the objects in a deployment model are specific while 

those in a component model are generic. For example, a 

deployment model might include a particular employee’s PC as one 

of its devices, but it would not include an unnamed, representative 

PC. 

Building deployment 

models 

You build deployment models in deployment diagram windows, 

using tools in the UML Deployment Diagram Tools tool folder. 

Support Direct support for deployment models is provided only in 


Sample deployment diagram 


 

10 


115

Executable component instances 

Executable component instances 


116 

An executable component instance is an instance of an 

executable component such as a runnable application like Microsoft 

Word. 

Creating an executable component instance 

To create an executable component instance: 

1 In the UML Deployment Diagram Tools tool folder, click and 

hold on the Executable Component Instance tool.

Form for executable component instances 

2 Drag to your deployment diagram window and release the 

mouse button where you want to place the executable 

component instance graphic. 

3 Type a name for the executable component instance. Then click 

on the window background to close the edit box. 

Form for executable component instances 

Interface instances 

You can use the Basic Component Instance Information form to 

view and modify information about an executable component 

instance. 

An interface instance is an instance of a component interface 

that identifies services provided by one component and used by 

others. 

To create an interface instance: 


hold on the Interface Instance tool. 

2 Drag to the component instance that provides the interface 

instance and release the mouse button. Then click where you 

want to place the interface instance graphic. 

3 Type a name for the interface instance. Then click on the 


Tip 

You can also use the Interface Instance tool to create an 

interface instance that’s not connected to a providing component 

instance. Afterwards, you can connect it to a providing component 

instance either through a form or by using the Line Connect tool. 


117

Node instances 

Node instances 


118 

A node instance is an instance of a node representing a physical 

device on which one or more component instances reside. 

Creating a node instance 

To create a node instance: 

Form for node instances 


hold on the Node Instance tool. 

2 Drag to your deployment diagram window and release the 

mouse button where you want to place the node instance 

graphic. 

3 Type a name for the node instance. Then click on the window 


You can use the Node Instance Information form to view and 

modify information about a node instance. 

Depends-on relationships in deployment 

models 

A depends-on relationship shows how one component instances 

supports another. In a depends-on relationship, one component 

instance requires the presence of another in order to function as 

designed.

To create a depends-on relationship: 

Requires relationships in deployment models 


hold on the Depends On tool. 

2 Drag to the dependent component instance and release the 

mouse button. 

3 Click on the supporting component instance. 

Requires relationships in deployment 

models 

A requires relationship connects a component instance to the 

interface instance it requires from another component instance. 

To create a requires relationship: 


hold on the Requires tool. 

2 Drag to the component instance that requires the interface 

instance and release the mouse button. 

3 Click on the interface instance required by the component 

instance. 

Deploys relationships 

A deploys relationship connects one or more component 

instances to the node instance they run on. A deploys relationship 

is the same as a resides relationship in a component model. 


119

Deploys relationships 


120 

To create a deploys relationship: 


hold on the Components Deployed tool. 

2 Drag into your deployment diagram window and release the 

mouse button. 


the deployed component instances. 

4 Click on the node instance that deploys the component 

instances.

,QVWDQFH ,QWHUDFWLRQ 

0RGHOV 80/ 

About instance interaction models 


Building instance 

interaction models 


Support Direct support for instance interaction models is provided only in 


Sample instance interaction diagram 

Instances 

Link ends 




11 


121

Message instances 

Message instances 


122 


2SHUDWLRQ 0RGHOV 

About operation models 

Description An operation model describes the interface of an operation defined 

in a class model. It shows what class of objects the operation 

applies to, what class of objects it returns, and what other 

information it requires. If the class to which an operation applies 

has subclasses, the operation may behave differently depending on 

the subclass of the object it’s acting on. In this case, the model can 

show which behavior of the operation is used for which subclass. 

If you’re modeling a business system rather than an application 

system, you may choose not to model your operation interfaces. 

However, if you’re planning to generate code from your models, you 

need to describe your operations in greater detail than object 

models allow. By building operation models, you can provide the 

necessary information for code generation. FrameWork can then 

use this information, for example, to produce the C++ signature of 

the operation. 

Building operation models You build operation models in operation diagram windows, copying 

some objects from class models and using a form and the tools in 

the Method Tools tool folder to create others. 

Support Direct support for operation models is provided in all three 


 

12 


123

Sample operation diagram 

Sample operation diagram 


124 

The window below shows a sample operation model. 

Operation model components 

In addition to the operation itself, the basic components of an 

operation model are the base and range classes, arguments, and 

methods: 

■ The base class of an operation is the class of objects on which 

the operation acts. An operation can have only one base class. 

■ The range class of an operation is the class of objects it 

produces. An operation can have only one range class. 

■ Arguments identify additional information required by an 

operation. An operation can have any number of arguments.

Arguments 

Arguments 

■ Methods identify the behaviors, or implementations, of an 

operation. An operation can have multiple methods. To show 

the details of a method, you can build a process or process step 

model and anchor it to the method. 

Defining arguments To specify the arguments for an operation, you use the Basic 

Operation Information form. On this form, you can name each 

argument and identify the class of objects that can be assigned to it. 

When you use FrameWork to generate code, this class is used as 

the data type of the argument. If you want, you can also provide an 

initial value for each argument. 

Methods 

Method domains The domain of each method (that is, the class of objects it applies 

to) for an operation must be either the base class of the operation or 

a subclass of the base class. Additionally, the domain must be 

different for each method. 

Creating multiple methods 

for an operation 

FrameWork uses the combination of the operation and domain to 

uniquely identify each method you create. As a result, when adding 

multiple methods to an operation, you need to specify the domain of 

each one as you add it. Otherwise, when you try to create the next 

method, it will initially have the same domain class (none) as an 

existing one and FrameWork will disallow the creation. 

Creating a method and connecting it to its domain class 

To create a method and connect it to its domain class: 

1 In the Method Tools tool folder, click and hold on the Method 

tool. 

2 Drag to your operation diagram window and release the mouse 

button where you want to place the method graphic. 


125

Methods 

Form for methods 


126 

3 Type a name for the method. Then click on the window 


4 Optionally, connect the method to its domain class. To do this: 

a In the Method Tools tool folder, click and hold on the 

Method Domain tool. 

b Drag to method and release the mouse button. Then click on 

the domain class of the method. 

You can use the Basic Method Information form to view and modify 

information about a method.

3DFNDJH 0RGHOV 80/ 

About package models 

Description Package models describe logical groupings of objects used in other 

models. They help organize the various elements of the system 

you’re modeling. In an OOAD context, package models group 

classes into namespaces or modules that are used in generating 

code. 

The semantics and notations for package models are prescribed by 

UML. For more information on the UML specification for this type 

of model, see the UML documentation made available by the OMG. 

Note To accommodate multiple target environments for code 

generation, the FrameWork implementation of package models is 

less restrictive than the UML specification. 

Building package models To build a package model, you typically create a package diagram 

using tools in the UML Package Diagram Tools tool folder. 

Support Direct support for package models is provided in all three 


 

13 


127

Sample package diagram 

Sample package diagram 

Sample diagram The window below shows a sample package diagram containing two 

packages. The name of this diagram is Application Portfolios. 

Packages of applications The Application Portfolios diagram shows two groupings of 

application systems used in an enterprise. The grouping on the left 

forms the Financial Systems package. These are the systems used 

for managing accounts receivable, accounts payable, and payroll 

processing. The grouping on the right forms the Sales Systems 

package. These systems support the activities involved in selling 

products. 

Packages, systems, and subsystems 

About packages A package is a grouping of objects that are logically or 

semantically related to each other. For example, the Accounts 

Receivable System, Accounts Payable System, and Payroll Processing 

System applications in the Financial Systems package all deal with 

money. 


128

About systems and 

subsystems 


Packages can be internal or external. The contents of an internal 

package are model elements that are defined in other models. 

Each model element can be in at most one package. Packages 

themselves are model elements and, as such, can be nested in other 

packages. For information on model elements, see “Model 

elements” in Chapter 2, “Cross-model Concepts.” 

Note 

According to the UML specification, a package owns its 

contents and, therefore, if the package is destroyed, so are its 

contents. FrameWork does not enforce this. 

An external package is a package supplied by a third party. Its 

contents typically are not described within FrameWork. 

Packages belong to the #PACKAGE class. External packages also 

belong to the #EXTERNAL PACKAGE class, which is a subclass of 

#PACKAGE. 

A system is a special type of package. It represents a collection of 

interconnected and interacting elements that fulfill a purpose or 

establish a context for a process or goal. A subsystem is a selfcontained 

part of larger system or subsystem. You can create use 

case models to describe the interactions that occur within 

subsystems. For information on use case models, see Chapter 20, 

“Use Case Models (UML).” 

Subsystems belong to the #SUBSYSTEM class, which is a subclass of 

#PACKAGE. Systems belong to the #SYSTEM class, which is a 

subclass of #SUBSYSTEM. 

Other types of packages FrameWork comes with other special types of packages for use in 

OOAD modeling for specific target environments. For example, you 

can use the Java packages when modeling for Java code generation 

or CORBA modules when modeling for CORBA IDL code 

generation. 

Java packages belong to the #JAVA PACKAGE class, which is a 

subclass of #PACKAGE. CORBA modules belong to the #CORBA 

MODULE class, also a subclass of #PACKAGE. 


129


Visibility of package 

contents 


130 

For more information on Java packages, see Generating Java Code 

with FrameWork. For more information on CORBA modules, see 

Generating CORBA IDL Code with FrameWork. 

The elements in a package have a property called visibility 

(element visibility association end) that determines whether 

elements in other packages can see them. The three basic types of 

visibility are public, protected, and private. 

Package elements are always visible to other elements within the 

same package. If an element is public, it’s also visible to elements 

in packages that import the package it’s in. Importing is a 

relationship between two packages that enables elements in the 

importing package to see the public elements in the imported 

package. 

A public element is also visible to elements in packages nested in 

the package it’s in, as is a protected element. A private element is 

visible only to other elements in the same package. 

Element references Sometimes, you may want an element to be visible to elements in 

one importing package, but not in another. To make this happen, 

you need to use an element reference. An element reference is an 

object that represents a particular model element to a particular 

importing package. By assigning a visibility to the element 

reference (visibility association end), you override the visibility 

setting for the element itself, but only for the specified importing 

package. 

For example, the diagram below shows that Package A imports 

Package B and Package C. The elements in Package B are all public, 

but Package A can see only elements B2 and B3. Package A cannot 

see element B1 because the element reference connecting them is 

protected. Conversely, the elements in Package C are all protected, 

but Package A can see element C1 because the element reference 

connecting them is public.

Package and element 

reference names 

Information about packages, systems, and subsystems 

The name of a package is typically a noun phrase the clearly 

reflects the package contents (for example, Financial Systems or 

Sales Systems). Element references are typically unnamed. 

However, you can assign an alias to an element reference (alias 

attribute). The alias is the name by which the referenced element 

is known to the importing package. An alias should follow the 

same naming guidelines as the element it applies to. 

Note 

According to the UML specification, the names of the objects 

in a package must be unique by type. FrameWork does not enforce 

this. 

Information about packages, systems, and 

subsystems 

In addition to its name, a package, system, or subsystem can have 

the following properties in an OOAD context: 

■ Elements in the package (elements contained association end). 

■ Other packages imported by the package (imported packages 



131

Creating packages, systems, and subsystems 


132 

■ Other packages that import the package (packages imported by 


■ References to elements in packages imported by the package 

(references association end). 

■ For use in modeling for Java code generation, classes that 

import the package (imported by association end). For 

information on using packages in Java models, see Generating 

Java Code with FrameWork. 

■ For use in modeling for Java code generation, classes imported 

by the package (imported classes association end). 


Creating a package, 

system, or subsystem 

To create an internal package, external package, system, or 

subsystem: 

1 In the UML Package Diagram Tools tool folder, click and hold 

on the Package, External Package, System, or Subsystem tool, 

depending on the type of package you want to create. 

2 Drag into your package diagram window and release the mouse 

button where you want to place the package graphic. 

3 Type a name for the package. Then click on the window 


Tip 

You can also use the Package tool to create a package and at 

the same time connect it to a package it imports. To do this, drag 

from the tool onto the imported package and click where you want 

to place the graphic for the new package.

Connecting a package to 

its contents 

Creating an import 

relationship 

Creating an element 

reference 


To connect a package to the model elements it contains: 


on the Package Contains tool. 

2 Drag into your package diagram window and release the mouse 

button. 


the model elements you want in the package. Then release the 

mouse button. 

4 Click on the package. 

Tip 

You can also use the Basic Package Information form to assign 

model elements to a package. For more information on this form, 

see “Forms for packages, systems, subsystems, and their elements” 

below. 

To create an import relationship between two packages: 


on the Imports tool. 

2 Drag onto the importing package and release the mouse button. 

3 Click on the imported package. 

To create an reference to an imported element: 


on the References tool. 


133

Forms for packages, systems, subsystems, and their elements 


134 

2 Drag onto the importing package and release the mouse button. 

3 Click on the model element to which you want to create the 

reference. 

Forms for packages, systems, subsystems, and 

their elements 

The Basic Package 


The Basic Subsystem 


You can use the Basic Package Information form to view and 

modify basic information about a package. The sample form below 

shows information about the Sales Systems package. 

You can use the Basic Subsystem Information form to view and 

modify information about the use cases associated with a

The Related Packages 

form 


subsystem. The sample form below shows this information for a 

subsystem named Sell Products. 

You can use the Related Packages form to view and modify package 

information about a model element. The sample form below shows 

this information for the OrderAdmin System element in the Sales 

Systems package. 


135



136

About process models 

3URFHVV 0RGHOV 

Description Process models show the dynamic behavior of a business or 

application system; that is, they show how the system works. They 

show the sequence and timing of operations and their effect on the 

state of the objects involved. This type of model is used primarily to 

define the implementation of methods for operations. 

Process models are an alternative to process step models, which are 

used primarily to describe business processes. 

Building process models You build process models in process diagram windows, using tools 

in the Process Diagram Tools tool folder and the common toolbar. 

Support Direct support for process models is provided in all three 


Sample process diagram 

The window below shows a sample process model. 

 

14 


137

Process model components 

Process model components 


138 

The basic components of a process model are events, operations, 

and trigger rules: 

■ Events represent changes in the state of an object. These 

changes occur as the result of the completion of operations. 

■ Operations define the actions that cause events to occur. A 

process model can include representations of user-defined 

operations that you create in class models and whose interfaces 

you define in operation models. These representations are 

called operation references. 

■ Trigger rules show the flow of control from events to the 

operations they cause to be invoked. A trigger rule also carries 

information about the object on which the invoked operation 

acts and the arguments passed to the operation. 

Note 

The combination of an operation and its resulting event is 

equivalent to a process step in a process step model. A trigger rule 

is equivalent to a next-step relationship in a process step model.

Operations 

Operations 

Operations define the actions that cause events to occur. 

FrameWork provides support for several primitive operations. A 

primitive operation is a basic operation that directly affects the 

state of an object and whose behavior is consistent regardless of the 

type of object it applies to. A primitive operation can be: 

■ A create operation, which creates a new object in a class 

■ A terminate operation, which destroys an object 

■ A classify operation, which assigns an object to an additional 

class 

■ A declassify operation, which removes an object from a class 

■ A reclassify operation, removes an object from one class and 

assigns it to another 

■ A connect operation, assigns a value to an association or 

attribute of an object 

■ A disconnect operation, removes a value from an association 

or attribute of an object 

■ A reconnect operation, which removes one value from an 

association or attribute of an object and assigns another to the 

same or different association or attribute 

■ An assign return object operation, which assigns an object 

to be returned when the process completes 

Note 

The combination of an operation and its resulting event is 

equivalent to a process step in a process step model. 


139

Operation references 




140 

To create an operation 

1 In the Process Step Diagram Tools tool folder, click and hold on 

the tool representing the type of operation you want to create. 

2 Drag to your process diagram window and release the mouse 

button where you want to place the operation graphic. 



Primitive operation forms FrameWork provides several forms that you can use to view and 

modify information about a primitive operation. 

Basic Create Information 

form 

Basic Declassify 


Basic Clasify Information 

form 

Basic Connect Information 

form 

Basic Disconnect 



You can use the Basic Create Information form to view and modify 

information about a create operation. 

You can use the Basic Declassify Information form to view and 

modify information about a declassify or terminate operation. 

You can use the Basic Classify Information form to view and modify 

information about a classify or reclassify operation. 

You can use the Basic Connect Information form to view and 

modify information about a connect or reconnect operation. 

You can use the Basic Disconnect Information form to view and 

modify information about a disconnect operation. 

A process model can include representations of user-defined 

operations that you create in operation models. These 

representations are called operation references.

Creating an operation reference 

Form for operation references 

Events 

Process initiation events 

Events 

1 In the Process Diagram Tools tool folder, click and hold on the 

Operation Reference tool. 


button where you want to place the operation reference graphic. 

3 Type the name for the operation being referenced. Then click 


You can use the Operation Reference Information form to view and 

modify information about an operation reference. 

FrameWork provides support for six types of events for use in 

process models. These events can be categorized as: 

■ Process initiation events 

■ Operation completion events 

■ Process completion events 

Starting a process A process initiation event is an event whose occurrence starts the 

process described by the model. Both start events and external 

events are process initiation events. 

A process model can include any number of process initiation 

events. Multiple process initiation events can provide alternative 

ways of starting a process, or they can indicate asynchronous 

processing of different paths to a single operation. 


141

Events 

Start events Start events occur within the system begin modeled. They can 

occur only at the beginning of a process. 

External events External events occur outside the scope of the system begin 

modeled. In addition to occurring at the beginning of a process, 

external events can occur at any other point in a process model. 

Operation completion events 

Completing an operation An operation completion event represents the successful or 

unsuccessful completion of an operation. The operation completion 

event types are success events and failed events. Both of these 

types of events can trigger further operations within an process 

model. A process model can include any number of operation 

completion events. 

Success events Success events are represented by the plain event graphic and can 

occur at any point within an event model. You can connect more 

than one event to an operation, but only one can be a success event. 

Failed events The operation triggered by a failed event specifies the action to be 

taken when the preceding operation fails. If an operation fails, but 

the model does not include a failed event for it, no further action 

occurs in the process defined by the model. 

Process completion events 

Completing a process A process completion event represents the completion of the process 

defined by the model. The process completion event types are goal 

events and abort events. A process model can include more than 

one process completion event, but only one will occur each time you 

run through the process. 

Goal events A goal event signifies that the entire process defined in the model 

has completed successfully. If the process model implements a 

method for an operation referenced in another process model, 

completion with a goal event causes that operation to result in a 

success event. 


142

Inheritance relationships in process models 

Abort events An abort event signifies that the entire process defined in the model 

has been unable to complete successfully. If the process model 

implements a method for an operation referenced in another 

process model, completion with an abort event causes that 

operation to result in a failed event. 

Creating an event 

Forms for events 


tool representing the type of event you want to create. 


button where you want to place the event graphic. 

3 Type a name for the event. Then click on the window 


You can use the Basic Event Information form to view and modify 

information about an event. 

Inheritance relationships in process models 

Superevents and 

subevents 

Partitions in process models 

You can use partitions and generalizations to show more detail 

about events. In a process model, partitions and generalizations 

represent the inheritance relationships between relatively 

general events (called superevents) and more specific forms of 

these events (called subevents). Superevents and their related 

subevents can each trigger different operations. 

Like other partitions, event partitions can be complete or 

incomplete, and the subevents in a partition are mutually 

exclusive. In a complete partition, each occurrence of the 

superevent must also be an occurrence of one subevent. In an 

incomplete partition, an occurrence of the superevent doesn’t have 

to be an occurrence of a subevent. 


143

Trigger rules 


144 

To create a partition: 

Generalizations in process models 


partition you want to create. 


the subevents contained in the partition. 

3 Click on the superevent of the partition. 

An event generalization shows the relationship between a 

superevent and a single subevent. 

To create a generalization: 

1 In the common toolbar, select the Generalization tool. 

2 Click and hold on the subevent. 


Trigger rules 

3 Drag to the superevent and release the mouse button. 

For information on the forms you can use to view and modify 

information about inheritance relationships, see “Forms for 

inheritance relationships” in Chapter 7, “Class Models (UML).” 

Cause and effect Trigger rules are the control flow elements of process models. Each 

trigger rule defines a cause and effect relationship between an 

event and an operation. The occurrence of the event causes the 

operation to be invoked as the effect. 

Showing concurrency One event can trigger multiple different operations that can 

execute concurrently. To show this, you use a separate trigger rule

Objects for operations 

for each operation. The trigger rules all have the same cause event, 

but different operations as their effect. 

Parallel trigger rules A plain trigger rule represents a single invocation of an operation. 

When an operation needs to be invoked multiple times (once for 

each object in a set), you use a parallel trigger rule. 

Creating a trigger rule 

Form for trigger rules 

Note 

A trigger rule is equivalent to a next-step relationship in a 

process step model. 

To create a trigger rule: 



Trigger Rule or Parallel Trigger Rule tool, depending on the 

type of trigger rule you want to create. 

2 Drag to the triggering event and release the mouse button. 

3 Click on the operation triggered by the event. 

You can use the Basic Trigger Rule Information form to view and 

modify information about a trigger rule. 

The underlying object In a process model, the trigger rule that invokes an operation also 

determines: 

■ The object or set of objects on which the operation acts 

■ The values of the arguments passed to the operation 

By default, a trigger rule passes the object identified by its cause 

event to the operation it invokes. This object is called the 

underlying object. For example, suppose the event Project 


145


Overriding the default 

object 

Base functions 


146 

Completed triggers the operation Evaluate Project. The underlying 

object passed by the trigger rule is the project that has been 

completed (for example, project MktgProj032). 

MktgProj032 

(underlying 

object) 

Cause event 

Trigger rule 

Operation 

invoked 

You can override the default object by specifying a base function 

and/or base input for the trigger rule. You use the Basic Trigger 

Rule Information form to specify this information. Base functions 

and base input are described in the following sections. 

About base functions You can specify a function that, when evaluated, identifies a 

different object or set of objects to be passed to the operation 

invoked by a trigger rule. This function is called the base 

function for the trigger rule. A base function can be an association 

end, attribute, or query, or it can be a function you define outside of 


Example For example, suppose that when a customer is indicted for forging 

checks, any accounts owned by that customer are frozen. The 

process model uses a parallel trigger rule from the Customer 

Indicted event to trigger the Freeze Account operation for each 

account. The underlying object for the Customer Indicted event is 

the indicted customer (for example, Fred Jones). The base function 

for the trigger rule is the accounts association end on the Customer 

class. When evaluated, this function yields the accounts that the 

customer owns, which are then passed to the Freeze Account 

operation.

Base input 

Fred Jones 

(underlying 

object) 

Base function 

Cause event 

Parallel trigger rule 

Accounts owned 

by Fred Jones 

Operation invoked 


Using the base object The input to the base function for a trigger rule is called the base 

input. By default, the base input is the underlying object 

identified by the cause event of the trigger rule. 

If the process model containing the trigger rule is the 

implementation of an operation, you can override the default base 

input in either of two ways. One way is to make the base input be 

the base object for the higher-level operation. The base object is 

the object for which the higher-level operation is invoked. It is in 

the base class of that operation. 


147


Using an argument value The other way to override the default base input for an operation is 

to use the value of an argument of the higher-level operation as the 

input. 


148 

Operation definition 

Underlying 

object 

Base class 

Base object 

Operation implementation 

Operation 

Base function 

Cause event 

Trigger rule 

Range class 

Output from 

base function 

Operation invoked

Base input without a base 

function 


Argument value 

Underlying 

object 

Base class 


Argument 

Base function 

Cause event 

Trigger rule 

Operation 

Range class 

Argument assignments for operations 

Output from 

base function 

Operation invoked 

You can specify base input for a trigger rule without a base function. 

In this case, the object passed to the operation invoked by the 

trigger rule is the base object or operation argument value itself. 


Arguments for operations Operations often require information in addition to which objects 

they act on. This additional information is supplied by the 

operation arguments. For an operation reference in a process 

model, the arguments are the ones specified in the definition of the 

referenced operation. The following primitive operations also have 

arguments: 

■ For the Create, Classify, and Reclassify operations, the 

arguments are the association ends or attributes defined for or 

inherited by the class specified in the operation definition. 


149



150 

■ For the Connect and Disconnect operations, the only argument 

is the association end or attribute specified in the operation 

definition. 

■ For the Reconnect operation, the arguments are the two 

association ends or attributes specified in the operation 

definition. 

Default argument values The default value for any argument is the underlying object 

identified by the cause event of the trigger rule. 

Overriding the default 

values 

Eval functions 

Underlying 

object Cause event 

Trigger rule 

Operation 

invoked 

Argument 

You can override the default value for an argument by specifying 

an eval function and/or eval function input for the trigger rule. You 

use the Basic Trigger Rule Information form to specify this 

information. Eval functions and eval function input are described 

in the following sections. 

About eval functions You can specify a function that, when evaluated, supplies a 

different value for an operation argument. This function is called 

the eval function for the argument. An eval function can be an 

association end, attribute, or query, or it can be a function you 

define outside of FrameWork. 

Example For example, the operation Freeze Account, which was used in the 

example under “Base functions” earlier in this chapter, needs to

Eval function input 


know about any such previous actions against the customer’s 

accounts. This information is provided by the previous suspensions 

argument. The eval function for the argument is the Account 

Suspensions association end on the Customer class. When evaluated 

for the underlying object (for example, for the customer Fred 

Jones), this function yields the set of suspensions associated with 

that object. 

Fred Jones 

(underlying 

object) 

Parallel trigger rule 

Cause event 

Operation 

invoked 

Eval function 

Argument 

Fred Jones’ account 

suspensions 

Using the base object By default, the input to an eval function is the underlying object 

identified by the cause event of the trigger rule. If the process 

model containing the trigger rule is the implementation of an 

operation, you can override the default input for an eval function in 

either of two ways. One way is to make the input be the base object 

for the higher-level operation. 


151


Using an argument value The other way to override the default input for an eval function is 

to use the value of an argument of the higher-level operation as the 

input. 


152 


Base class 

Underlying 

object 

Base object 


Operation 

Eval function 

Range class 

Cause event Operation 

invoked 

Trigger rule 

Argument 

Output from 

base function

Eval function input without 

an eval function 



Argument value 

Base class 

Underlying 

object 


Argument 

Eval function 


You can specify eval function input for an argument without an 

eval function. In this case, the value assigned to the argument is 

the base object or the value of an argument for the higher-level 

operation. 

You can associate a decision function with a partition in a 

process model. The decision function determines which subevent, if 

any, each superevent is an occurrence of. 

To create a decision function: 

Range class 

Cause event Operation 

invoked 

Trigger rule 

Argument 

Operation 

Output from 

base function 


Decision Function tool. 


153

Filters 

Filters 

Creating a filter 

Form for filters 


154 

2 Drag to partition graphic and release the mouse button. 




Process models can include filters that specify the conditions 

under which operations are triggered. Each filter represents a 

boolean function that, if true, results in the invocation of its 

associated operation. 

By default, the condition for a filter is that all the cause events for 

the trigger rules leading to it must have occurred. You can override 

this default by naming a different condition. 

To create a filter: 


Filter tool. 

2 Drag to cause event or operation and release the mouse button. 

3 Click where you want to place the filter graphic. 

4 Type a name for the filter. Then click on the window 


You can use the Basic Filter Information form to view and modify 

information about a filter.

About project models 

3URMHFW 0RGHOV 


Building project models Information on this topic is not yet available. 

Support Direct support for project models is provided only in Business and 

Enterprise FrameWork. 

Sample project diagram 


 

15 


155

Projects 

Projects 


156 


Project tasks and milestones 

Project teams 



Implemented strategies 




157



158

5HSRUW /D\RXW 0RGHOV 

About report layout models 

Description Report layout models specify the content and structure of 

information contained in FrameWork Document reports. You use a 

report layout model to describe the sections and subsections you 

want in a report, as well as to identify the objects and properties 

you want to report on. You even use the model to specify the 

presentation format for each piece of information in the report. 

Building report layout 

models 

Running the Document 

report 

To build a report layout model, you create a report layout diagram. 

You use the tools in the Report Layout Diagram Tools tool folder to 

lay out the structure of your report graphically in the diagram. 

Then you use forms to describe the content and presentation format 

you want for each element of the report. 

 

16 

After building a report layout model, you run the Document report 

on the object that represents the report itself. FrameWork uses 

your specifications in the model to generate the report output. For 

more information on running the Document report, see Using 


Support Direct support for report layout models is provided in all three 



159

Sample report layout diagram 

Sample report layout diagram 

Sample diagram The window below shows a sample report layout diagram named 

SuccessTech Document Overview. 

The report structure The SuccessTech Document Overview diagram defines the 

structure of a Document report. The top left object, SuccessTech 

Overview, represents the report itself. The report has a preface and 

four chapters — Mission and Goals, Organization Structure, Business 


160

Reports 

Reports 

Architecture, and Business Objects. The objects aligned below each 

chapter (for example, Mission&Vision and Goals&Objectives) 

represent sections within the chapter. The remaining objects 

represent paragraphs within the preface, chapters, and sections. 

About reports A report represents the output generated by the FrameWork 

Document report. When you build a report layout diagram, the 

report is typically the first object you create. While a report can 

contain many chapters, the report object in a model is directly 

connected to at most one. That one is the first chapter in the 

report. 

A report can also have a preface. In the generated Document 

report, the preface precedes the first chapter. 

Report information In addition to its name, you can supply the following information 

for a report: 

■ A title. The title can be the same as or similar to the report 

name. FrameWork uses the report title as the heading for the 

report in the generated Document report. If you don’t supply a 

title, FrameWork uses the report name as the heading. 

■ The author. FrameWork prints the author you specify below 

the report heading in the generated Document report. 

■ The date the report was created or last modified. FrameWork 

prints the date you specify below the author in the generated 

Document report. 

When generating a Document report, FrameWork uses Document_ 

followed by the name of the report object as the name of the first 

file of the generated report. For example, if the name of the report 

object is SuccessTech Overview, the first file of the generated report 

is Document_SuccesstechOverview.html. 


161

Creating a report 

Creating a report 

Form for reports 


162 

To create a report: 

1 In the Report Layout Diagram Tools tool folder, click and hold 

on the Output Report tool. 

2 Drag into your report layout diagram window and release the 

mouse button where you want to place the report graphic. 

3 Type a name for the report. Then click on the window 


You can use the Output Report Information form to view and 

modify information about a report. The sample form below shows 

information about the SuccessTech Overview report in the sample 

report layout diagram shown earlier in this chapter.

Sample first page of a Document report 

Prefaces 

Sample first page of a Document report 

The figure below shows the first page of the Document report 

FrameWork generates from the report in the sample report layout 

diagram shown earlier in this chapter. 

About prefaces The preface is one of the highest-level divisions of a report. You 

can use it to provide introductory or explanatory information that 

applies to the rest of the report. 

A report can have at most one preface. In the report layout model, 

the preface is directly connected to the report object. In the 

generated Document report, the preface, if present, is at the same 

level as the chapters. It also comes before all chapters. 

A preface can contain both paragraphs and sections. In the 

generated Document report, all the paragraphs directly included in 

a preface come before the sections of the preface. While a preface 

can contain many paragraphs and sections, only the first one of 

each is directly connected to the preface. 


163

Creating a preface 

Preface information In addition to its name, you can supply the following information 

for a preface: 


164 

■ The author 

Creating a preface 

Form for prefaces 

■ The date the preface was created or last modified 

In a generated Document report, the heading for the preface is 

Preface. 

To create a preface in a report: 


on the Preface tool. 

2 Drag onto the containing report and release the mouse button. 

Then click where you want to place the preface graphic. 

3 Type a name for the preface. Then click on the window 


You can use the Document Element Information form to view and 

modify information about a preface. The sample form below shows 

information about the Preface preface in the sample report layout 

diagram shown earlier in this chapter.

Sample preface from a Document report 

Chapters 

Sample preface from a Document report 

The figure below shows the page of the Document report 

FrameWork generates from the Preface preface in the sample 

report layout diagram shown earlier in this chapter. 

About chapters Chapters, along with the preface, are the highest-level divisions of 

a report. Each chapter in a report is connected to the chapters that 

precede and follow it. Only the first chapter is directly connected to 

the report itself. 


165

Creating chapters 


166 

A chapter can contain both paragraphs and sections. In the 

generated Document report, all the paragraphs directly included in 

a chapter come before the sections of the chapter. While a chapter 

can contain many paragraphs and sections, only the first one of 

each is directly connected to the chapter. 

Chapter information In addition to its name, you can supply the following information 

for a chapter: 

■ A title. The title can be the same as or similar to the chapter 

name. FrameWork uses the chapter title as the heading for the 

chapter in the generated Document report. If you don’t supply a 

title, FrameWork uses the chapter name as the heading. 

■ The author. 

Creating chapters 

Creating the first chapter in 

a report 

Creating additional 

chapters 

■ The date the chapter was created or last modified. 

To create the first chapter in a report: 


on the Chapter tool. 

2 Drag onto the containing report and release the mouse button. 

Then click where you want to place the chapter graphic. 

3 Type a name for the chapter. Then click on the window 


To create an additional chapter in a report: 


on the Chapter tool. 


mouse button where you want to place the chapter graphic.

3 Type a name for the chapter. Then click on the window 


Connecting chapters To connect a chapter to the chapter that follows it: 

Form for chapters 

Form for chapters 


on the Next Chapter tool. 

2 Drag onto the chapter that comes first and release the mouse 

button. Then click on the following chapter. 


modify information about a chapter. The sample form below shows 

information about the Organization Structure chapter in the sample 

report layout diagram shown earlier in this chapter. 

Sample chapter from a Document report 


FrameWork generates from the Organization Structure chapter in 

the sample report layout diagram shown earlier in this chapter. 


167

Sections 

Sections 

About sections Sections are divisions of chapters as well as of other sections. 

Sections within another section are called subsections. Each 

section within a chapter or other section is connected to the sections 

that precede and follow it at the same level. Only the first section 

within a chapter is directly connected to that chapter. Only the 

first subsection within a section is directly connected to that 

section. 


168 

A section can contain paragraphs as well as subsections. Only the 

first paragraph in a section is directly connected to the section. In 

the generated Document report, all the paragraphs directly 

included in a section come before the subsections. 

Section information In addition to its name, you can supply the following information 

for a section: 

■ A title. The title can be the same as or similar to the section 

name. FrameWork uses the section title as the heading for the 

section in the generated Document report. If you don’t supply a 

title, FrameWork uses the section name as the heading. 

■ The author. 

■ The date the section was created or last modified.

Creating sections 

Creating the first section in 

a chapter 

Creating the first 

subsection in a section 


sections 

To create the first section in a chapter: 

Creating sections 


on the Section tool. 

2 Drag onto the containing chapter and release the mouse button. 

Then click where you want to place the section graphic. 

3 Type a name for the section. Then click on the window 


To create the first subsection in a section: 


on the Subsection tool. 

2 Drag onto the containing section and release the mouse button. 

Then click where you want to place the subsection graphic. 

3 Type a name for the subsection. Then click on the window 


To create an additional section in a chapter or other section: 


on the Section tool. 


mouse button where you want to place the section graphic. 

3 Type a name for the section. Then click on the window 


Connecting sections To connect a section to the section that follows it at the same level: 


on the Next Section tool. 


169

Form for sections 

Form for sections 


170 

2 Drag onto the section that comes first and release the mouse 

button. Then click on the following section. 


modify information about a section. The sample form below shows 

information about the Mission&Vision section in the sample report 

layout diagram shown earlier in this chapter. 

Sample section from a Document report 


FrameWork generates from the Mission&Vision section in the 

sample report layout diagram shown earlier in this chapter.

Paragraphs 

Paragraphs 

About paragraphs Paragraphs are the information-bearing components of a report. 

They identify the objects to be reported on as well as the format of 

the information presented. Each paragraph in a report must be 

part of a preface, chapter, or section. The report itself cannot 

directly contain paragraphs. 

General paragraph 

information 

Each paragraph within a preface, chapter, or section is connected to 

the paragraphs that precede and follow it. Only the first paragraph 

is directly connected to the preface, chapter, or section itself. 

FrameWork supplies a variety of paragraph types. The type you 

assign to a paragraph determines the format of the paragraph 

information in the generated Document report. It also determines 

what additional information you need to provide about the 

paragraph. 

In addition to the paragraph name, you can supply the following 

information for all types of paragraphs: 

■ A title. The title can be the same as or similar to the paragraph 

name. FrameWork uses the paragraph title as the heading for 


171

Creating paragraphs 

Creating paragraphs 

Creating the first paragraph 

in a preface, chapter, or 

section 


paragraphs 


172 

the paragraph in the generated Document report. If you don’t 

supply a title, FrameWork generates the paragraph without a 

heading. 

■ The paragraph type. This information is required for all 

paragraphs. FrameWork supplies the following paragraph 

types: Text, Model Diagram, Image File, Data File, Simple List, 

Merged List, Horizontal Table, Vertical Table, Two-Dimensional 

Table, and Cross-Reference Table. Each of these types is 

described in detail later in this chapter. 

To create the first paragraph in a preface, chapter, or section: 


on the Paragraph tool. 

2 Drag onto the containing preface, chapter, or section and 

release the mouse button. Then click where you want to place 

the paragraph graphic. 

3 Type a name for the paragraph. Then click on the window 


To create an additional paragraph in a preface, chapter, or section: 


on the Paragraph tool. 


mouse button where you want to place the paragraph graphic. 

3 Type a name for the paragraph. Then click on the window 


Focus objects and content functions 

Connecting paragraphs To connect a paragraph to the paragraph that follows it in the same 

preface, chapter, or section: 


on the Next Paragraph tool. 

2 Drag onto the paragraph that comes first and release the mouse 

button. Then click on the following paragraph. 

Focus objects and content functions 

Focus objects Most paragraph types require you to specify a focus object. This 

is the object FrameWork uses as a starting point for retrieving 

information to display in the paragraph. 

Note 

If the focus object for a paragraph can be a metamodel class, 

the form FrameWork provides for the paragraph type has a 

separate field in which you need to specify the class. 

Content functions A content function identifies an association end, attribute, or 

query that FrameWork evaluates to retrieve information for 

display in a paragraph. FrameWork can evaluate the function 

either on a focus object or on the result of a previous function 

evaluation. 

Content function 

information 

Content functions are reusable. In other words, once you create a 

content function, you can use it in the specification of multiple 

paragraphs. 

You can supply the following information for a content function: 

■ The function (that is, the association end, attribute, or query) 

assigned to it. This information is required for all content 

functions. 

■ An alias. The alias can be the same as or similar to the name of 

the content function or its assigned function. For some 

paragraph types, FrameWork uses the alias to label 

information retrieved by the assigned function in the generated 


173

Text paragraphs 


174 

Document report. If you don’t supply an alias, FrameWork uses 

the name of the assigned function as the label. 

■ The owner class of the assigned function (also called the domain 

class). This information is required when the assigned function 

is an association end or attribute and should be omitted when 

the assigned function is a query. 

■ A cross-reference indicator for use in cross-reference table 

paragraphs. For more information on cross-reference 

indicators, see “Cross-reference table paragraphs” later in this 

chapter. 

Form for content functions You can use the Content Function Information form to view and 

modify information about a content function. The sample form 

below shows information about a content function named AP Vision. 


Description A text paragraph generates plain text in a Document report. The 

source of the text depends on the information you supply in the 

paragraph definition:


■ If the paragraph definition specifies a focus object without a 

content function, the generated output is the object name. (The 

focus object is required for a text paragraph.) 

■ If the paragraph definition specifies a primary content function, 

the generated output is the value that results from evaluating 

the content function on the focus object. If the value consists of 

more than one object, FrameWork lists them all. 

■ If the paragraph definition specifies a secondary content 

function, the generated output is the value that results from 

evaluating that function on the result of the primary content 

function. (A primary function is required if you provide a 

secondary function.) 

Form for text paragraphs You can use the Text Paragraph Information form to view and 

modify information about a text paragraph. The sample form below 

shows information about the Mission Statement paragraph in the 

sample report layout diagram shown earlier in this chapter. 

Sample text paragraph 

from a Document report 

The figure below shows the output FrameWork generates from the 

Mission Statement paragraph in the sample report layout diagram 

shown earlier in this chapter. 


175

Image/data file paragraphs 


Model diagram paragraphs A model diagram paragraph generates a picture of a 

FrameWork diagram in a Document report. For this type of 

paragraph, you need to specify only the diagram you want to use. 

Image file paragraphs An image file paragraph inserts either an external graphic or a 

link to an external graphic into a Document report. For this type of 

paragraph, you need to supply a data file object whose name is the 

full path and filename of the graphic file. If the graphic itself is to 

be inserted into the report, it should be a type that your HTML 

browser can display (that is, GIF or JPEG). 

Data file paragraphs A data file paragraph inserts either the contents of an external 

file or a link to an external file into a Document report. For this 

type of paragraph, you need to supply a data file object whose name 

is the full path and filename of the external file. If the contents of 

the file are to be inserted directly into the report, the file should be 

a type that your HTML browser can display (for example, HTML or 

plain text). 

Form for image/data file 

paragraphs 


176 

You can use the Image/File Paragraph Information form to view 

and modify information about a model diagram, image file, or data 

file paragraph. The sample form below shows information about 

the Corporate Strategic Plan Model paragraph in the sample report 

layout diagram shown earlier in this chapter.

Sample model diagram 

paragraph from a 

Document report 


The figure below shows the output FrameWork generates from the 

Corporate Strategic Plan Model paragraph in the sample report 

layout diagram shown earlier in this chapter. 


177

List paragraphs 

Sample linked data file 





178 

The figure below shows the output FrameWork generates from a 

data file paragraph with the Linked option selected. 

Simple list paragraphs A simple list paragraph generates a list of objects in a Document 

report. For this type of paragraph, you need to specify both a focus 

object and a primary content function. The objects in the list are 

those that result from evaluating the primary content function on 

the focus object. 

Merged list paragraphs A merged list paragraph generates a two-level list of objects in a 

Document report. For this type of paragraph, you need to specify a 

focus object, a primary content function, and a secondary content 

function. The first level of the list contains the objects that result 

from evaluating the primary content function on the focus object. 

For each of those objects, the second level of the list contains the 

objects that result from evaluating the secondary content function 

on the object.

Sorting lists Not yet available. 


List headings In a generated Document report, both simple and merged lists have 

headings of the form: 

primary-function-alias for focus-object 

If the primary content function doesn’t have an alias, FrameWork 

uses the name of the assigned function in the list heading. 

Form for list paragraphs You can use the List Paragraph Information form to view and 

modify information about a simple or merged list paragraph. The 

sample form below shows information about the Org. Structure 

paragraph in the sample report layout diagram shown earlier in 

this chapter. 

Sample merged list 



The figure below shows the merged list FrameWork generates from 

the Org. Structure paragraph in the sample report layout diagram 

shown earlier in this chapter. 


179

Table paragraphs 


Horizontal table 

paragraphs 


180 

A horizontal table paragraph displays selected properties of its 

focus object (or metamodel class) in a one-row table in a Document 

report. Each property is identified by a content function in the 

paragraph definition. FrameWork uses the content function alias 

as the column heading for the property in the generated table. If 

the content function doesn’t have an alias, FrameWork uses the 

name of the assigned function. 

Vertical table paragraphs A vertical table paragraph displays selected properties of its 

focus object (or metamodel class) in a one-column table in a 

Document report. For this type of paragraph, FrameWork uses the 

content function aliases as row labels. 

Two-dimensional table 

paragraphs 

A two-dimensional table paragraph generates a multirow 

horizontal table in a Document report. For this type of paragraph, 

you need to supply a primary content function in addition to the 

focus object (or metamodel class) and properties. Each row displays 

selected properties of an object resulting from the evaluation of the 

primary content function on the focus object. 

Table headings In a generated Document report, both horizontal and vertical tables 

have headings of the form:

Object Properties Report for: focus-object 


FrameWork does not automatically generate headings for twodimensional 

tables. 

Form for table paragraphs You can use the Table Paragraph Information form to view and 

modify information about a horizontal, vertical, or two-dimensional 

table paragraph. The sample form below shows information about 

the Process Information paragraph in the sample report layout 


Tip 

After creating a new content function in the Properties field, 

use the Content Function Information form to assign it a function, 

alias, and owner class. 


181


Sample vertical table 



Sample two-dimensional 

table paragraph from a 



182 

The figure below shows the vertical table FrameWork generates 

from the US Sales Information paragraph in the sample report layout 


The figure below shows portions of the two-dimensional table 

FrameWork generates from the Process Information paragraph in 

the sample report layout diagram shown earlier in this chapter. 

. 

.

Cross-reference table paragraphs 


Description A cross-reference table paragraph generates a cross-reference 

table in a Document report. In a cross-reference table, each row 

represents an object, as does each column. At the intersection of 

each row and column, FrameWork places an indicator if the row 

object is connected to the column object through a particular 

function. 

Cross-reference table 

headings 

Form for cross-reference 

paragraphs 

For a cross-reference table paragraph, you need to specify: 

■ A focus object (or metamodel class) and content function for the 

rows. The row objects are the ones that result from evaluating 

the row content function on the row focus object. 

■ A focus object (or metamodel class) and content function for the 

columns. The column objects are the ones that result from 

evaluating the column content function on the column focus 

object. 

■ A cross-reference content function. This is the function 

FrameWork checks to see whether the row objects and column 

objects are connected to each other. FrameWork marks the 

intersection of connected objects with the cross-reference 

indicator you assign to the cross-reference content function. 

The cross-reference indicator can be any character string. 

In a generated Document report, cross-reference tables have 

headings of the form: 

The Cross-Reference Table Function is "cross-ref-assigned-func" 

Cross-ref-assigned-func is the name of the association end, 

attribute, or query assigned to the cross-reference content function. 

You can use the Cross-Reference Table Paragraph Information 

form to view and modify information about a cross-reference table 

paragraph. The sample form below shows information about a 


183


Sample cross-reference 




184 

cross-reference table paragraph named US Sales Processes and 

Resources. 

The figure below shows the cross-reference table FrameWork 

generates from the US Sales Processes and Resources paragraph 

shown in the form above.



185



186

5RDG 0DS 0RGHOV 

About road map models 

Description A road map model provides access to some or all of the models in a 

modeling project. It can show the logical connections between the 

models, as well as establish navigation paths among the model 

diagrams. A well-designed road map model can provide an 

overview of the content and scope of the system being modeled and 

be an invaluable tool for organizing and maintaining your models. 

You can implement the relationships in a road map model through 

KnowledgeBase connections between model diagrams. 

Alternatively, you can represent these relationships graphically in 

a road map diagram without storing their semantics in the 

KnowledgeBase. 

Building road map models To build a road map model, you typically create a road map 

diagram using tools in the Diagram Tools tool folder. 

Support Direct support for road map models is provided in all three 


 

16 


187

Sample road map diagram 

Sample road map diagram 

Sample diagram The window below contains a sample road map diagram that 

provides access to the main models for a company named 

SuccessTech. The name of this diagram is Road Map. 

Groups of models The Road Map diagram groups models by logical areas at two 

levels. At the higher level, the models are assigned to one of three 

categories: Missions, Strategies, and Structure; Business 

Architecture and Process Modeling; or Analysis, Design, and 

Deployment. Within these categories, the models are further 

organized into subcategories such as Strategic Planning, Value- 

Chain Modeling, and Technology Implementation. 


188 

The logical relationships among the models in the Road Map 

diagram are represented graphically only. The diagram uses 

freestanding text to label the categories of models and background 

color on the text anchors to visually group the graphic references to

Road map model contents 

the model diagrams at the lower level. These groupings of models 

have no corresponding implementation in the KnowledgeBase. 

Road map model contents 

Graphic references to 

diagrams 

A road map model contains models. The diagram of a road map 

model contains graphic references to diagrams of those models. 

Each graphic reference lets you both open the referenced diagram 

and view and modify information about that diagram. 

Diagram relationships A road map model also contains the relationships you create among 

the diagrams in the model. Diagrams can have parent/child 

relationships, or they can simply be attached to other diagrams. 

Parent/child relationships establish diagram hierarchies. Attached 

diagrams establish navigational paths. 

For more information on diagram relationships, see the discussion 

about organizing diagrams in Using FrameWork. 

Information about diagrams 

In addition to its name, a diagram can have the following 

properties: 

■ Diagram types that apply to the diagram (#diagram types 

association end). For information on diagram types, see Using 


■ Objects represented graphically in the diagram (#contains 


■ Objects to which the diagram is connected as a subdiagram 

(#anchor association end). For information on subdiagrams, see 


■ Objects to which the diagram is attached (#related_objects 



189

Information about diagrams 


190 

■ Diagrams to which the diagram is a child (#parent diagrams 


■ Diagrams to which the diagram is a parent (#child diagrams 


■ The collaboration represented by the diagram (collaboration 

association end). For information on representing 

collaborations, see Chapter 8, “Collaboration Models (UML).” 

■ The interaction represented by the diagram (interaction 

association end). For information on representing interactions, 

see Chapter 17, “Sequence Models (UML).” 

■ Model diagram paragraphs that generate a picture of the 

diagram (dgm_paragraphs association end). For information on 

model diagram paragraphs, see “Image/data file paragraphs” in 

Chapter 16, “Report Layout Models.” 

■ In the context of the Zachman framework, the owner of the 

diagram (accountable party association end). 

Note 

The Zachman framework is a classification scheme for 

enterprise information developed by John A. Zachman of 

Zachman. Support for the Zachman framework is included only 

in Ptech Enterprise FrameWork. 

■ In the context of the Zachman framework, the questions 

answered by the diagram (questions answered association end). 

■ In the context of the Zachman framework, the points of view 

presented by the diagram (view perspectives association end). 

For information on other properties of diagrams, see Modeling with 

Technology FrameWork.

Creating road map diagrams 

Creating a graphic 

reference 

Creating a parent/child 

relationship 

Creating road map diagrams 

To create a graphic reference to the diagram in the active window: 

On the View menu, select Create Reference. 

To create a parent/child relationship between two diagrams: 

1 Place a graphic reference to each diagram in your road map 

diagram window. 

2 In the Diagram Tools tool folder, click and hold on the Parent 

Diagram tool. 

3 Drag onto the graphic reference to the child diagram. 

4 Click on the graphic reference to the parent diagram. 

Attaching a diagram To attach one diagram to another and, thereby, enable navigation 

from the second diagram to the first: 

1 Place a graphic reference to each diagram in your road map 

diagram window. 

2 In the Diagram Tools tool folder, click and hold on the Related 

To tool. 

3 Drag onto the graphic reference to one of the diagrams. 

4 Click on the graphic reference to the other diagram. 


191

Form for diagrams 

Form for diagrams 


192 

You can use the Basic Diagram Information form to view and 

modify information about a diagram. The sample form below 

shows information about a diagram named

6HTXHQFH 0RGHOV 80/ 

About sequence models 

Description Sequence models show the order of communications within 

interactions. In a sequence model, each communication is 

represented as a message that is passed from one object to another 

(or to itself). This type of model can help clarify complex 

interactions by breaking them down visually into discrete, 

sequenced communications. Additionally, you can add freestanding 

text to indicate time requirements for the communications. 

Sequence models show how objects participate in interactions, but 

do not show the relationships among those objects. To represent 

these relationships, you can use collaboration models. 

Building sequence models You build sequence models in sequence diagram windows, using 

tools in the UML Sequence Diagram Tools tool folder. 

Support Direct support for sequence models is provided only in Technology 


Sample sequence diagram 

The window below shows a sample sequence model. 

 

17 


193

Objects 

Objects 

Creating an object 


194 

An object in a sequence model is either a specific instance of a 

class or an unnamed, representative instance of a class. 

To create an object: 

1 In the UML Sequence Diagram Tools tool folder, click and hold 

on the Object tool. 

2 Drag to your sequence diagram modeling window and release 

the mouse button where you want to place the object graphic. 

3 Type a name for the object. Then click on the window 


Form for objects 

Lifeline points 

You can Basic Object Information form to view and modify 

information about an object. 

Form for objects 

About lifeline points A lifeline represents the existence of an object through time. A 

lifeline point is the intersection of a lifeline and a message. 

Lifeline points occur whenever an object either sends or receives a 

message. Their positions on the lifeline indicate the sequence in 

which they occur. 

The first lifeline point is the first point at which the object either 

sends or receives a message. Each lifeline point after the first one 

is a point at which the object either sends or receives a message. 

Creating a first lifeline point To create a first lifeline point: 

Creating subsequent 

lifeline points 


on the First Lifeline Point tool. 

2 Drag to the object and release the mouse button. 

3 Click where you want to place the first lifeline point graphic. 

4 Type a name for the first lifeline point. Then click on the 


To create a subsequent lifeline point: 


on the Lifeline Point tool. 

2 Drag to the preceding lifeline point and release the mouse 

button. 


195

Messages 

Messages 

Creating a message 


196 

3 Click where you want to place the lifeline point graphic. 

4 Type a name for the lifeline point. Then click on the window 


A message is a named communication from one object to another. 

A return message is a named communication that is the response 

to a message. 

To create a message: 

Form for messages 


on the tool representing the type of message you want to create. 

2 Drag to the lifeline point that send the message and release the 

mouse button. 

3 Click on the lifeline point that receives the message. 

4 Type the name of the message. Then click on the window 


You can use the Message Instance Information form to view and 

modify information about a message.

6WDWHFKDUW 0RGHOV 80/ 

About statechart models 

Description Statechart models show the changes an object can undergo during 

its lifetime. Objects change in response to actions performed by 

other objects or themselves. Statechart models can include 

information about the events that trigger each change. 

A statechart model applies to a particular class of objects, and the 

changes represented in the model often correspond to subclasses of 

that class. To establish a connection between a statechart model 

and the class it applies to, you can attach the model diagram to the 

class. 

Building statechart models You build statechart models in user-defined windows, using tools in 

the UML Statechart Diagram Tools tool folder. 

Support Direct support for statechart models is provided only in Technology 


Sample statechart diagram 

 

18 

The window below shows a sample strategic planning diagram. 


197

States 

States 

Creating a state 


198 

A state represents a condition that describes an object for some 

finite amount of time. 

To create a state: 

1 In the UML Statechart Diagram Tools tool folder, click and hold 

on the State tool. 

2 Drag into your statechart diagram window and release the 

mouse button where you want to place the state graphic. 

3 Type a name for the state. Then click on the window 


State actions and internal transitions 

State actions and internal transitions 

Entry, do, and exit actions While an object is in a given state, it can cause or be affected by a 

variety of actions, including: 

■ Entry actions, which are performed once immediately after 

the object transitions to the state 

■ Do actions, which are ongoing actions performed while the 

object is in the state 

■ Exit actions, which are performed once immediately before the 

object transitions out of the state 

Internal transitions An object can undergo an internal transition while in a given 

state. When an internal transition occurs, the exit and entry 

actions for the state are not invoked. An internal transition differs 

from a self-transition, in which the object actually exits and 

reenters the same state, thereby invoking the exit and entry 

actions for the state. 

Form for states 

Transitions 

To specify entry, do, and exit actions and internal transitions for a 

state, composite state, or a submachine state, you use the Basic 

State Information form. 

A transition shows the ways in which objects can change from one 

state to another. 


199




200 

To create a transition: 


on the Transition tool. 

2 Drag to the state from which the object transitions and release 

the mouse button. Then click on the state to which the object 

transitions. 

Events, actions, and guards 

Events and actions In the context of a state model, an event is an occurrence that 

triggers a transition. For example, the event Account Reconciled 

would cause an object in the Bank Account class to transition from 

the Frozen state to the Active state. Additionally, the transition 

triggered by an event can invoke an action. For example, the 

transition of a Bank Account object from the initial state to the 

Active state, triggered by the Initial Deposit event, would invoke the 

Post Deposit action. 

Guards Some events trigger a transition only under certain circumstances. 

For example, the Frozen 90 Days event would cause a Bank Account 

object to transition from the Frozen state to the final state only if 

the condition Appeal Denied is true. A boolean condition that 

determines whether an event triggers a transition is called a 

guard. 


To associate events, actions, and guards with transitions, you use 

the State Transition Information form. The information you supply 

on this form is stored in the KnowledgeBase, but is not 

automatically displayed in the modeling window. You can use 

freestanding text to represent this information textually in the 

window.

Synchronization bars 

Initial states 

Synchronization bars 

A synchronization bar is a complex transition, drawn 

horizontally or vertically, indicating either the simultaneous 

convergence of multiple transitions into a single source state or the 

simultaneous divergence of a single transition into multiple source 

states. 

To create a synchronization bar: 


on the horizontal Synchronization Bar tool if you want to draw 

the graphic horizontally in your diagram, or the vertical 

Synchronization Bar tool if you want to draw the graphic 

vertically. 


mouse button where you want to place the synchronization bar 

graphic. 

3 Type a name for the synchronization bar. Then click on the 


4 Optionally, use the Transition tool to show the simultaneous 

convergence of multiple transitions into a single source state or 

the simultaneous divergence of a single transition into multiple 

source states. 

An initial state indicates a starting point for a state model (for 

example, the point at which the object is created). The object is 

never actually in an initial state. Rather, the initial state provides 

an anchor for the transition to the first state in a series of state 

transitions. 


201

Final states 

Final states 


202 

To create an initial state: 


on the Initial State tool. 


mouse button where you want to place the initial state graphic. 

3 Type a name for the initial state. Then click on the window 


A final state indicates the ending point for a state model (for 

example, the point at which the object is terminated). As with an 

initial state, the object is never actually in a final state. Rather, the 

final state provides a terminus for the transition from the last state 

in a series of state transitions. 

To create a final state: 

Composite states 


on the Final State tool. 


mouse button where you want to place the final state graphic. 

3 Type a name for the final state. Then click on the window 


A composite state is a state that encompasses two or more other 

states, called substates. When an object is in a composite state, it 

is in at least one of the substates as well. The relationship between

Submachine states 

Submachine states 

a composite state and its substates is similar to the relationship 

between a superclass and its subclasses in a complete partition. 

To create a composite state and connect it to substates: 


on the Composite State tool. 


mouse button where you want to place the composite state 

graphic. 

3 Type a name for the composite state. Then click on the window 



on the Substates tool. 


mouse button. 


the substates. Thren click on the composite state. 

A submachine state is a complex state that is described by 

another statechart diagram. After you have created a submachine 

state, you can build and anchor to it another statechart diagram 

that describes its structure in greater detail. 

Creating a submachine state 

To create a submachine state: 


on the Submachine State tool. 


203

Form for submachine states 


204 


mouse button where you want to place the submachine state 

graphic. 

3 Type a name for the submachine state. Then click on the 


Form for submachine states 

In addition to the Basic State Information form, you can use the 

Basic Submachine State Information form to view and modify 

information about a submachine state.

7HFKQRORJ\ $UFKLWHFWXUH 

0RGHOV 

About technology architecture models 

Description Technology architecture models identify resources and the 

dependent and cooperative relationships among them. You can use 

technology architecture models, for example, to represent the 

infrastructure of the technical assets in your enterprise or to 

describe the hardware and software requirements of an application. 

Building technology 


To build a technology architecture model, you typically create a 

technology architecture diagram using tools in the Technology 

Architecture Diagram Tools tool folder. 

Support Direct support for technology architecture models is provided in all 

three FrameWork products. 

Sample technology architecture diagram 

Sample diagram The window below shows a sample technology architecture 

diagram. The name of this diagram is OrderAdmin System. 

19 


205

Sample technology architecture diagram 

Types of resources The OrderAdmin diagram shows the technology resources used in 

the process of creating and tracking orders. The focus of the 

diagram is the OrderAdmin System application, a software 

resource. Most of the other resources used in order processing are 

software, like the Order DB database and the OrbixWeb development 

environment. However, two of the resources, the NT Server and 

Desktop PC machines, are hardware. 

Resource relationships The OrderAdmin diagram also shows the ways in which the order 

processing resources interact. The OrderAdmin System and Act! 3.0 

applications work together in a cooperative relationship, as do the 

Windows NT and Windows 95 operating systems. The other 

connections shown in the diagram represent dependencies among 

the resources. For example, the Order DB, Windows NT, OrbixWeb 

and PartsForJava resources all serve to support the OrderAdmin 

System application. 


206

Resources 

Resources 

About resources Resources represent assets that can be used within your 

enterprise to add value to activities and processes. A resource can 

be: 

Cooperative resource 

relationships 

Supporting resource 

relationships 

■ A hardware resource such as a particular network server or 

the second-floor printer 

■ A software resource such as Windows 95 or a particular 

CORBA compiler 

■ A human resource such as an employee with knowledge of 

labor law or a consultant with C++ programming expertise 

■ An enterprise resource such as the company phone system or 

a confidential customer list 

Resources belong to the *ENTERPRISE RESOURCE class. 

Cooperative resource relationships show how resources work 

together. In a cooperative relationship, each resource adds value 

and neither depends on the other (for example, a drawing program 

and a desktop publishing program that can import the pictures 

created by that program). 

Supporting resource relationships show how resources depend 

on each other. In a supporting relationship, one resource requires 

the other in order to be of value (for example, an application 

program and the operating system it runs under). 

Resource names Resources can be specific or generic. The name of a specific 

resource is usually the same as the name of the real object it 

represents (for example, the Act! 3.0 application or the consultant 

Susan Gold). The name of a generic resource is typically a noun that 

identifies the resource type (for example, Database Management 

System or C++ Consultant). 


207

Information about resources 

Information about resources 


208 

In addition to its name, a resource can have the following 

properties in an OOAD context: 

■ The resource type (resource type association end). Framework 

comes with several predefined resource types, such as 

Hardware, Human, and Packaged Application. You can also create 

new ones to meet the needs of your enterprise. 

■ Other resources with which the resource works cooperatively 

(works with association end). 

■ The other resources that depend on the resource (capabilities 

supported association end). 

■ Classes whose objects serve as input to the resource (information 

used association end). For information about classes, see 

“Model classes” in Chapter 5, “Business Object Models.” 

■ The age of the resource (age attribute). 

■ The stage of the resource within its life cycle (lifecycle stage 

attribute). For example, the life cycle stage of a software 

application might be Beta or Final Release. 

■ The amount of money the resource initially cost (purchase cost 

attribute). 

■ The cost of using the resource (use cost attribute). For example, 

the use cost for a consultant might be $1000/Day. The use cost 

for a photocopy machine might be $.05/Page. 

■ In workflow modeling, the unit of time to which the use cost 

applies (use cost time unit association end). Framework comes 

with several predefined time units, such as Hour, Day, and Year. 

You can also create new ones to meet the needs of your 

enterprise.

Creating resources 

Creating a resource To create a resource: 

Creating a cooperative 

resource relationship 

Creating resources 

When you specify a value for the use cost time unit association 

end, you should omit the measurement unit from the value of 

the use cost attribute. 

■ Assessment of the quality of the resource (quality attribute). 

For example, the quality of a software application might be 

Excellent, Good, Fair, or Poor. 

1 In the Technology Architecture Diagram Tools tool folder, click 

and hold on the Enterprise Resource, Software Resource, 

Hardware Resource, or Human Resource tool, depending on the 

type of resource you want to create. 

2 Drag into your technology architecture diagram window and 

release the mouse button where you want to place the resource 

graphic. 

3 Type a name for the resource. Then click on the window 


Tip 

You can also use a resource tool to create a resource and at the 

same time connect it to a supporting resource. To do this, drag 

from the tool onto the supporting resource and click where you 

want to place the graphic for the new resource. 

To create a cooperative relationship between two resources: 


and hold on the Works With tool. 


209

Forms for resources 

Creating a supporting 

resource relationship 


The Enterprise Resource 

Properties form 


210 

2 Drag onto one of the resources in the cooperative relationship (it 

doesn’t matter which one) and release the mouse button. 

3 Click on the other resource in the relationship. 

To create a supporting relationship between two resources: 


and hold on the Supports tool. 

2 Drag onto the supporting resource and release the mouse 

button. 

3 Click on the dependent resource. 

You can use the Enterprise Resource Properties form to view and 

modify basic information about a resource. The sample form below 

shows information about the OrderAdmin System application.

The Enterprise Resource 

Relationships form 


You can use the Enterprise Resource Relationships form to view 

and modify the relationships a resource has with other objects. The 

sample form below shows the relationships in which the 

OrderAdmin System application participates. 


211

Locations in technology architecture diagrams 

Locations in technology architecture 

diagrams 

About locations A location is a place where resources are based. For example, a 

location can be the city in which a network server is resides, the 

office in which a person sits, or the cubicle in which a printer is 

installed. 


212 

Locations belong to the *LOCATION class. 

Location names The name of a location is usually the same as the name of the real 

place it represents (for example, San Francisco or Room 331). If the 

real place is unnamed, the location name should clearly identify 

where it is (for example, 2nd-Floor Main Hallway).


Creating a location To create a location for a resource in a technology architecture 

diagram: 

Connecting a resource to a 

location 


and hold on the Location tool. 

2 Drag onto the resource for which you’re creating the location 


3 Click where you want to place the location graphic. 

4 Type the name of the location. Then click on the window 


Tip 

You can also use the Location tool to create a location that’s 

not connected to a resource. Afterwards, you can connect it to a 

resource either through a form or by using the Located At tool, as 

described below. 

To connect a resource to a location: 


and hold on the Located At tool. 

2 Drag onto the resource and release the mouse button. 

3 Click on the location. 


213



214

8VH &DVH 0RGHOV 80/ 

About use case models 

Description Use case models show the types of interactions that can occur 

between a subsystem and the users of the subsystem. Within a use 

case model, interactions are represented nonsequentially, placing 

the focus on their structure rather than their dynamic behavior. 

This focus enables the model to present an easy-to-understand view 

of the requirements of an existing or proposed subsystem. 

Building use case models To build a use case model, you create a use case diagram. You use 

the tools in the UML Use Case Diagram Tools tool folder to lay out 

the structure of the subsystem graphically in the diagram. Then 

you use forms to supplement the information in your diagram. 

Support Direct support for use case models is provided in all three 


Sample use case diagram 

 

20 

The window below shows a sample use case diagram. The diagram 

shows the usage scenarios of the subsystem based on the Sell 

Products activity. The Sell Products activity has two use cases, 

Establish Initial Contact and Project Account Revenue, and a 

composite use case, Qualify Leads. 


215

Subsystems 

Subsystems 


216 

The diagram includes three actors, Salesperson, Sales Manager, and 

Direct Sales Customer. The Direct Sales Customer actor has a 

bidirectional communication with the Establish Initial Contact use 

case and a communication with the Qualify Leads composite use 

case in which messages flow in one direction from the use case to 

the actor. The Salesperson actor has bidirectional communications 

with both Establish Initial Contact and Qualify Leads, while the Sales 

Manager actor has a bidirectional communication with the Project 

Account Revenue use case and, like Direct Sales Customer, a 

communication with Qualify Leads in which messages flow in one 

direction from the use case to the actor. 

About subsystems A subsystem is an organized, integrated group of processes and/or 

resources that, as a whole, serves some purpose within an 

enterprise. FrameWork also recognizes individual activities, 

process steps, and resources as subsystems.

Creating a subsystem and connecting it to use cases 

Subsystem information In addition to its name, you can supply the following information 

for a subsystem 

■ Projects. You can identify the enterprise or enterprises for 

which the subsystem serves as a resource. 

■ A textual description of the subsystem that provides more 

details about the role it plays within an enterprise. 

Creating a subsystem and connecting it to use 

cases 

The Susbsystem tool creates a subsystem that you can connect to 

one or more use cases. The Subsystem Use Cases tool connects the 

subsystem to those use cases. 

To create a subsystem and connect it to one or more use cases: 

1 In the UML Use Case Diagram Tools tool folder, click and hold 

on the Subsystem tool. 

2 Drag into your use case diagram window and release the mouse 

button where you want to place the subsystem graphic. 

3 Type a name for the subsystem. Then click on the window 



on the Subsystem Use Cases tool. 


button. 

6 While holding down the right mouse button, drag a box around 

the use cases you want to connect to the subsystem and release 

the mouse button. 


217

Form for subsystems 

Form for subsystems 

The Basic Subsystem 



218 

7 Click on the subsystem to which you want to connect the use 

cases. 

You can use the Basic Subsystem Information form to view and 

modify information about a subsystem. The sample form below 

shows information about the Sell Products activity in the sample use 

case diagram shown earlier in this chapter.

Use cases 

Use cases 

About use cases A use case represents a type of interaction that can occur between 

a subsystem and its users (called actors). A use case presents a 

static view of an interaction without showing the sequence of 

actions that comprise the interaction. You can use another type of 

model, such as an activity model, to show the dynamic behavior of a 

use case. 

Composite use cases A use case that incorporates one or more additional subsystems is 

called a composite use case. You can anchor additional use case 

diagrams to a composite use case to show the interactions for these 

subsystems. 

Communications between 

use cases and actors 

Extending and using use 

cases 

Instances of a use case and an actor may communicate with each 

other. These communications take the form of requests that an 

actor makes of a subsystem to perform a service and the responses 

that a use case makes to an actor when performing these services. 

Two use cases may be connected to each other through either an 

extends or a uses relationship. An extends relationship connects 

one use case to another that has the same behaviors, plus some of 

its own. In this type of relationship, the use case with the 

additional behaviors is said to extend the other use case. The 

relationship between one use case and another that extends it is 

similar to the relationship between a superclass and a subclass. 

A uses relationship connects one use case to another that includes 

its behaviors. The relationship between one use case and another 

that it uses is similar to the relationship between a process and a 

subprocess. 

Use case information In addition to its name, you can supply the following information 

for a use case: 

■ Use case steps. A use case step is an action that causes the 

invocation of another use case. 


219

Creating and relating use cases 


220 

■ A scenario description that provides a textual account of 

situations in which the type of interaction represented by the 

use case occurs. 

■ Business rules 

■ Initiating business events 

■ Preconditions 

■ Postconditions 

■ Snapshot scenarios 

Creating and relating use cases 

Creating a use case or 

composite use case 

Creating an extends 

relationship 

To create a use case or composite use case: 


on the Use Case tool or Composite Use Case tool. 


button where you want to place the use case or composite use 

case graphic. 

3 Type a name for the use case or composite use case. Then click 


To create an extends relationship: 


on the Extends tool. 

2 Move your cursor to the extending use case and release the 

mouse button. Then click on the extended use case.

Creating a uses 

relationship 

Forms for use cases 

The Basic Use Case 


To create a uses relationship: 



on the Uses tool. 

2 Move your cursor to the using use case and release the mouse 

button. Then click on the use case that is used. 

You can use the Basic Use Case Information form to view and 

modify information about a use case or a composite use case. The 

sample form below shows information about the Establish Initial 

Contact use case in the sample use case diagram shown earlier in 

this chapter. 


221


The Use Case 

Documentation form 


222 

You can use the Use Case Documentation form to view and modify 

information about a use case. The sample form below shows 

information about the Establish Initial Contact use case.

The Composite Use Case 

Objects form 


You can use the Composite Use Case Objects form to view and 

modify information about the objects incorporated by a composite 

use case. The sample form below shows information about the 

objects contained Qualify Leads composite use case. 


223

Actors 

Actors 

About actors An actor identifies a role in which people, jobs, organizations, or 

even other subsystems can interact with use cases. Actors must be 

external to each use case with which they interact. 


224 

Tip 

You can copy organizations, jobs, and resources from other 

models into your use case diagrams to serve as actors. For 

example, the Direct Sales Customer organization functions as an 

actor in the sample use case diagram shown earlier in this chapter. 

Actor information In addition to its name, you can supply the following information 

for an actor: 

Creating an actor 

■ The messages sent from an actor to a use case. These messages, 

which are defined by bidirectional communications or 

communications from the actor to the use case, take the form of 

requests that the actor sends to the subsystem to perform some 

specified service or action. 

■ The messages sent from a use case to an actor. These messages, 


communications from the use case to the actor, take the form of 

requests that the actor receives from the subsystem to perform 

some specified service or action. 

To create an actor: 


on the Actor tool. 


button where you want to place the actor graphic.

Form for actors 

The Basic Actor 


Communications 

3 Type a name for the actor. Then click on the window 


Form for actors 

You can use the Basic Actor Information form to view and modify 

information about an actor. The sample form below shows 

information about the Salesperson actor in the sample use case 


Communications establish relationships between actors and use 

cases. A communication can be: 

■ A Communication from Actor, in which messages flow from 

the actor to the use case 

■ A Communication from Use Case, in which messages flow 

from the use case to the actor 


225

Communications from actors and use cases 


226 

■ A Bidirectional Communication, in which messages flow 

both ways between the actor and the use case 

Communication information You can supply the following information for a communication: 

■ The messages sent from an actor to a use case. These messages, 


communications from the actor to the use case, take the form of 

events that the actor requests the subsystem to perform. 

■ The messages sent from a use case to an actor. These messages, 


communications from the use case to the actor, take the form of 

events that the subsystem requests the actor to perform. 

Communications from actors and use cases 

To create a communication from an actor: 


on the Communication from Actor tool. 

2 Move your cursor to the communicating actor and release the 

mouse button. Then click on the use case that the actor 

communicates with. 

To create a communication from a use case: 


on the Communication from Use Case tool. 

2 Move your cursor to the communicating use case and release 

the mouse button. Then click on the actor that the use case 

communicates with.

Bidirectional communications 

To create a bidirectional communication: 

Form for communications 

The Communication 


Bidirectional communications 


on the Bidirectional Communication tool. 

2 Move your cursor to either the communicating actor or use case 

and release the mouse button. Then click on the opposing 

communicating actor or use case. 

You can use the Communication Information form to view and 

modify information about a communication from an actor, a 

communication from a use case or a bidirectional communication. 

The sample form below shows information about the bidirectional 

communication between the Salesperson actor and the Manage 

Account Information use case in the sample use case diagram shown 

earlier in this chapter. 


227

Form for communications 


228

Special Characters 

#relaxed_classes association 101 

A 

Abort events 143–?? 

Actions 

about 200 

do 199 

entry 199 

exit 199 

Activities 

about 35–?? 

Activity models 

about 33 

activities 35–?? 

building 33 

as closed systems 46–?? 

complete partitions ??–44 

incomplete partitions 44–?? 

Argument assignments 

about 149–150 

Arguments 

about 124 

as base input 148–149 

default value of 150 

defining 125–?? 

as eval function input 152–153 

eval function input for 151–153 

eval functions for 150–151 

overriding default value of 150 

Asserted functions ??–58, ??–94 

Associations 

#relaxed_classes 101 

as asserted functions ??–58, ??–94 

cardinality 58–??, 94–?? 

invariant in n-place relations 65 

variance 59–??, 95–?? 

Attributes 

as asserted functions ??–58, ??–94 


variance 59–??, 95–?? 

B 

,QGH[ 

Base class 124 

Base functions 

about 146–147 

Base input 

about 147–149 

Base object 

as base input 147–148 

Index 

229

as eval function input 151–152 

Base Trigger Rule Information form 146 

Basic Operation Information form 125–?? 

Binary components 109 

Building 

activity models 33 

collaboration models 103–?? 

component models 107–?? 

deployment models 115–?? 

object models 89–?? 

operation models 123–?? 

process models 137–?? 

sequence models 193–?? 

state models 197–?? 

technology architecture models 205–?? 

C 

Cardinality 

about 58–??, 94–?? 

setting 63, 64, 95 

Classes 

base for operations 124 

generalizations 76, 96 

intersections 76, 96 

for n-place relations ??–65 

partitions 76, 96 

range for operations 124 

Classify operation 

arguments for 149 

Closed systems 46–?? 

Code generation 

relaxed constraints 101 

Collaboration models 

about 103 

building 103–?? 

Complete partitions 

activity ??–44 

class 76–??, 96–?? 

Index 

230 

event 143–?? 

Component interfaces 

in component models 110 

Component models 

about 107–108 

binary components 109 


component interfaces 110 

executable components 109 

source code components 108 

Concurrency 144–?? 

Connect operation 


Constraints 

creating 100 

modifying 74, 100 

nonempty uniqueness 74, 100 

relaxing 101–102 

single-function 100 

uniqueness 73, 99 

Constraints menu option 75, 101 

Constraints window 75, 101 

Cooperative resource relationships 

about 210 

Create operation 


Creating 

constraints 100 

methods 125–?? 

n-place relations 64–65 

ordering relations 66–67 

symmetric relations 65–66 

D 

Defining 

arguments 125–?? 

Deployment models 

about 115

uilding 115–?? 

Dialog boxes 

Select Association 67 

Disconnect operation 


Do actions 199 

Domain 

methods 125 

E 

Enterprise resources 207 

Entry actions 199 

Eval functions 

about 150–151 

input to 151–153 

Events 

abort 143–?? 

external 142–?? 

failed 142–?? 

generalizations 143 

goal 142–143 

operation completion 142–?? 

partitions 143 

process completion 142–?? 

process initiation 141–?? 

in process models 138 

start 142–?? 

in state models 200–?? 

success 142 

types of 141 

Executable components 

in component models 109 

Exit actions 199 

External events 

in process models 142–?? 

F 

Failed events 142–?? 

Filters 

about 154–?? 

Forms 

Base Trigger Rule Information 146 

Basic Operation Information 125–?? 

Functions 

asserted ??–58, ??–94 

base 146–147 


eval 150–151 

invariant 59–??, 95–?? 

variant 59–??, 95–?? 

G 

Generalizations 

class 76, 96 

event 143, 144–?? 

product 43–?? 

Goal events 

in process models 142–143 

Guards 

about 200–?? 

H 

Hardware resources 207 

Human resources 207 

I 

Incomplete partitions 

activity 44 

class 76–??, 96–?? 

event 143–?? 


Inheritance 76–??, 96–?? 

Index 

231

Internal transitions 199–?? 

Intersections 76, 96 

Invariant functions 59–??, 65, 95–?? 

L 

Lifelines 195 

M 

Methods 

about 125 

creating 125–?? 

domain 125 

multiple 125–?? 

Models 

activity 33–?? 

collaboration 103–?? 

component 107–?? 

deployment 115–?? 

object 49–?? 

operation 123–?? 

process 137–?? 

sequence 193–?? 

state 197–?? 

technology architecture 205–?? 

Modifying 

constraints 74, 100 

Multiple methods 125–?? 

N 

Nonempty uniqueness constraints 74, 100 

N-place relations 64–65 

O 

Object modeling toolbar 

about 89 

Object models 

Index 

232 

about 49–89 

associations ??–64, ??–64, ??–95 

attributes ??–64, ??–64, ??–95 


complete partitions 76–??, 96–?? 

generalizations 76, 96 

incomplete partitions 76–??, 96–?? 

intersections 76, 96 

partitions 76, 96 

Objects 

base 147–148 

for operations 145–149 

underlying 145–146 

Operation completion events 142–?? 

Operation models 

about 123 

arguments 124, 125–?? 

base class 124 


methods 125, 125–?? 

range class 124 


about 138 


Operations 

argument assignments for 149–153 

arguments 124, 125–?? 

base class 124 

completing 142–?? 

interfaces 123 

methods 125, 125–?? 

objects for 145–149 

in process models 138 

range class 124 

Ordering relations 66–67 

P 

Parallel trigger rules 145–??

Parent/child relationships 66 

Partitions 

class 76, 96 

event 143 


Primitive operations 

about 139–?? 

Process completion events 142–?? 

Process initiation events 141–?? 

Process models 

about 137 


complete partitions 143–?? 

event types 141 

events 138 

filters 154–?? 

generalizations 143, 144–?? 

incomplete partitions 143–?? 

operation references 138 

operations 138 

parallel trigger rules 145–?? 

partitions 143 

primitive operations 139–?? 

trigger rules 138, 144–?? 

Processes 

completing 142–?? 

starting 141–?? 

Products 

generalizations 43–?? 

partitions 43–?? 

R 

Range 

for operations 124 

Reclassify operation 


Reconnect operation 


Relations 

n-place 64–65 

ordering 66–67 

symmetric 65–66 

Relaxing constraints 101–102 

Resources 

about 207 

cooperative relationships 210 

S 

Select Association dialog box 67 

Self-transitions 199 

Sequence models 

about 193 


lifelines 195 

Set Cardinality menu option 63, 64, 95 

Set Variance menu option 63, 64, 95 

Setting 

cardinality 63, 64, 95 

variance 63, 64, 95 

Single-function constraints 100 

Software resources 207 

Source code components 108 

Start events 

in process models 142–?? 

State models 

about 197 

actions 199, 200 


events 200–?? 

guards 200–?? 

internal transitions 199–?? 

self-transitions 199 

States 

actions 199 

internal transitions 199–?? 

self-transitions 199 

Index 

233

Subclasses 76–??, 96–?? 

Subevents 143–?? 

Subproducts 43–?? 

Substates 

transitions between 199–?? 

Success events 142 

Superclasses 

about 76–??, 96–?? 

Superevents 143–?? 

Superproducts 43–?? 

Symmetric relations 65–66 

T 

Team architecture models 

cooperative resource relationships 210 

resources 207 

Technology architecture models 

about 205 


Temporary windows 

Constraints 75, 101 

Transitions 

internal 199–?? 

self 199 

Trigger rules 

about 138, 144, 145–?? 

base functions 146–147 

base input 147–149 

concurrent operations 144–?? 

parallel 145–?? 

U 

UML 

collaboration models 103–?? 

component models 107–?? 

deployment models 115–?? 

sequence models 193–?? 

Index 

234 

state models 197–?? 

Underlying object 

about 145–146 

as default eval function input 151 

as base input 147 

as default argument value 150 


about 73, 99 

nonempty 74, 100 

V 

Variance 

about 59–??, 95–?? 

setting 63, 64, 95 

Variant functions 59–??, 95–??

Modeling with Technology FrameWork

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?