Using VisualAge UML Designer

Markus Muetschard, Byron Munday, Matthias Nieder, Wolfgang Sanyer

International Technical Support Organization http://www.redbooks.ibm.com

SG24-4997-00

SG24-4997-00

International Technical Support Organization Using VisualAge UML Designer

July 1998

Take Note! Before using this information and the product it supports, be sure to read the general information in Appendix D, “Special Notices” on page 219.

First Edition (July 1998) This edition applies to Version 4.5 of the VisualAge UML Designer, a feature of VisualAge Smalltalk Enterprise 4.5. The term VisualAge, as used in this publication, refers to the VisualAge Smalltalk product set. Portions of this book describe materials developed by Object Technology International Inc. of Ottawa, Ontario, Canada. Object Technology International Inc. is a subsidiary of the IBM Corporation. Comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. QXXE Building 80-E2 650 Harry Road San Jose, California 95120-6099 When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. © Copyright International Business Machines Corporation 1998. All rights reserved Note to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

Contents Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv How the Book Is Organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi The Team that Wrote this Redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi Comments Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Part 1. VisualAge UML Designer Introductory Tour . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Chapter 1. What Is VisualAge UML Designer? 1.1 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Browsing . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Relationship Browser . . . . . . . . . . . . . . 1.2.2 Focus Browser . . . . . . . . . . . . . . . . . . . 1.2.3 Path Browser . . . . . . . . . . . . . . . . . . . . 1.2.4 Hierarchy Browser . . . . . . . . . . . . . . . . 1.2.5 Edition Browser . . . . . . . . . . . . . . . . . . 1.3 Diagrammers . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Use Case Diagrammer . . . . . . . . . . . . . 1.3.2 Class Diagrammer . . . . . . . . . . . . . . . . 1.3.3 Sequence Diagrammer . . . . . . . . . . . . . 1.4 Publishing . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

.. .. .. .. .. .. .. .. .. .. .. .. ..

. . . . . . . . . . . . .

.. .. .. .. .. .. .. .. .. .. .. .. ..

. . . . . . . . . . . . .

.. .. .. .. .. .. .. .. .. .. .. .. ..

.. .. .. .. .. .. .. .. .. .. .. .. ..

. . . . . . . . . . . . .

.. .. .. .. .. .. .. .. .. .. .. .. ..

. . . . . . . . . . . . .

.. .. .. .. .. .. .. .. .. .. .. .. ..

. . . . . . . . . . . . .

. .3 . .4 . .4 . .4 . .5 . .6 . .7 . .8 . .9 . .9 . 10 . 11 . 11

Chapter 2. Before You Jump in: Work Path Guidelines . . 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Animation of the Model. . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Consistency Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.. .. .. .. .. .. ..

. . . . . . .

.. .. .. .. .. .. ..

. . . . . . .

.. .. .. .. .. .. ..

. . . . . . .

. 13 . 15 . 17 . 17 . 19 . 19 . 19

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. 21 . 21 . 22 . 23 . 25

Chapter 3. Case Study: The Library Management System. 3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Static Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

© Copyright IBM Corp. 1998

. . . . .

. . . . .

. . . . .

iii

Part 2. Using VisualAge UML Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Chapter 4. Requirements Analysis . 4.1 Getting Started . . . . . . . . . . . . . . . 4.2 Creating a New Model . . . . . . . . . 4.3 Identifying Requirements . . . . . . . 4.4 Defining Requirements . . . . . . . . .

. . . . .

.. .. .. .. ..

. . . . .

.. .. .. .. ..

.. .. .. .. ..

. . . . .

.. .. .. .. ..

. . . . .

.. .. .. .. ..

. . . . .

.. .. .. .. ..

.. .. .. .. ..

. . . . .

.. .. .. .. ..

. . . . .

.. .. .. .. ..

. . . . .

. 29 . 29 . 30 . 32 . 32

Chapter 5. Use Cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.1 Identifying Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.1.1 Defining Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.1.2 Link Use Cases to Requirements . . . . . . . . . . . . . . . . . . . . . . . . 40 5.2 Analyzing Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.2.1 Identifying Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.2.2 Identifying Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.2.3 Identifying Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.2.4 Identifying Used and Extends Use Cases . . . . . . . . . . . . . . . . . . 57 5.3 Two Complementary Approaches to Analyze Use Cases . . . . . . . . . . 65 Chapter 6. Use Case Diagrams . . . . 6.1 Creating a Use Case Diagram . . . 6.2 Adding a Group Figure . . . . . . . . . 6.3 Adding a Use Case Figure . . . . . . 6.4 Adding a Dependent Relationship

. . . . .

.. .. .. .. ..

. . . . .

.. .. .. .. ..

.. .. .. .. ..

. . . . .

.. .. .. .. ..

. . . . .

.. .. .. .. ..

. . . . .

.. .. .. .. ..

.. .. .. .. ..

. . . . .

.. .. .. .. ..

. . . . .

.. .. .. .. ..

. . . . .

. 67 . 67 . 68 . 70 . 71

Chapter 7. Responsibilities and Participants (Collaborators) . . . . . . . 77 7.1 Identifying and Assigning Responsibilities and Participants . . . . . . . . 77 7.2 Identifying Responsibilities and Doing Hypertext Links . . . . . . . . . . . . 78 7.3 Setting Up an Efficient Identification and Assignment Process . . . . . . 82 7.4 Assigning Action, Identifier, and Value Responsibilities to Things. . . . 83 7.5 Defining Participants in Action, Identifier, and Value Responsibilities . 85 7.6 Assigning Reference Responsibilities with Participants . . . . . . . . . . . 87 7.7 Hypertext Linking the Responsibilities in the Use Cases. . . . . . . . . . . 88 7.8 Defining All Types of Responsibilities and Participants at Once . . . . . 89 Chapter 8. Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 The Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Generating a Protocol Automatically. . . . . . . . . . . . . . . . . . . 8.3 Using Various Browsers with Various Settings . . . . . . . . . . . 8.4 Renaming Generated Model Elements (Messages) . . . . . . .

.. .. .. .. ..

. . . . .

.. .. .. .. ..

. . 95 . . 95 . . 97 . 102 . 102

Chapter 9. Initial Class Designs (Object Model) . . . . . . . . . . . . . . . . . 105 9.1 Class Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

iv

VisualAge Smalltalk UML Designer

9.2 Generating a Class Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 9.3 Making a Class Design Dependent on a Protocol . . . . . . . . . . . . . . . 109 Chapter 10. Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1 Creating a Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Add a Class Figure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Creating Associations among Classes . . . . . . . . . . . . . . . . . . . 10.4 Adding Figure Adornments and Editing Model Element Details

.. .. .. .. ..

. 111 . 111 . 112 . 116 . 118

Chapter 11. Interaction Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 11.1 Creating a Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 11.2 Adding an Object to the Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 122 11.3 Add Method Calls to the Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 124 11.4 Sequence Diagram with Calls to User-Created Class Method . . . . 127 Chapter 12. Refined Class Designs (Object Model) . . . . . . . 12.1 Class Redesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Inheriting Class Information . . . . . . . . . . . . . . . . . . . . . . . 12.3 Changing the Protocol of a Class Design . . . . . . . . . . . . . 12.4 Completing the Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.5 Creating a Class Diagram of the Refined Class Designs . 12.6 Setting Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

.. .. .. .. .. .. ..

. . . . . . .

. . . 131 . . . 131 . . . 131 . . . 134 . . . 137 . . . 138 . . . 138

Chapter 13. Extending the Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 13.1 Defining a New Class Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 13.2 Integrating a New Class Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 13.3 Creating a Class Diagram of the Extended Model. . . . . . . . . . . . . . 146 Chapter 14. Publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 14.1 Creating a Publication of a Model or Model Element. . . . . . . . . . . . 149 Part 3. Advanced Modelling Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Chapter 15. Modeling Alternatives and Extensions . . . . . . . . . . . . . . 157 15.1 Analysis of the Final Business Model . . . . . . . . . . . . . . . . . . . . . . . 158 15.2 The Subsystem "Banana Split" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 15.2.1 Identifying the Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 15.2.2 Splitting the Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 15.2.3 Generalizing the Remaining Subsystems . . . . . . . . . . . . . . . . 161 15.3 Protocols, Stereotypes, and Prerequisites . . . . . . . . . . . . . . . . . . . 162 15.4 Using Classes as Service Objects . . . . . . . . . . . . . . . . . . . . . . . . . 165 15.5 Implementing Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 15.6 Adding a History: Tracing Loans. . . . . . . . . . . . . . . . . . . . . . . . . . . 171 15.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

v

15.8 Applying the Changes in the Model . . . . . . . . . . . . . . . . . . . . . . . . 173 Chapter 16. Abstraction and Abstraction Levels . 16.1 Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.2 Kinds of Abstraction . . . . . . . . . . . . . . . . . . . . . 16.2.1 Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.2.2 Life-cycle . . . . . . . . . . . . . . . . . . . . . . . . . 16.2.3 Time Dependent . . . . . . . . . . . . . . . . . . . . 16.3 Creating a Stereotype . . . . . . . . . . . . . . . . . . .

. . . . . . .

.. .. .. .. .. .. ..

. . . . . . .

.. .. .. .. .. .. ..

.. .. .. .. .. .. ..

. . . . . . .

.. .. .. .. .. .. ..

. . . . . . .

.. .. .. .. .. .. ..

. 175 . 175 . 176 . 176 . 177 . 177 . 177

Chapter 17. Smalltalk Code Generation . . . . . . . . . . . . . . . . . . . . . . . 179 17.1 Generation of Smalltalk Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . 179 17.2 Configuring the System Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . 180 17.3 Generating Real Classes from Class Designs . . . . . . . . . . . . . . . . 182 17.4 Integration of Existing Smalltalk Classes . . . . . . . . . . . . . . . . . . . . 184 Chapter 18. Java Code Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 18.1 Generation of Java Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 18.1.1 Configuring System Settings. . . . . . . . . . . . . . . . . . . . . . . . . . 186 18.2 Generating Real Classes from Class Designs . . . . . . . . . . . . . . . . 187 18.3 Integration of Existing Java Classes . . . . . . . . . . . . . . . . . . . . . . . . 189 Chapter 19. Reverse Engineering and Integrating Existing Classes. 191 19.1 Retrieving Class Designs from Real Classes . . . . . . . . . . . . . . . . . 192 19.2 Retrieving Protocols from Real Classes . . . . . . . . . . . . . . . . . . . . . 193 19.3 Retrieving Class Designs and Protocols from Real Classes . . . . . . 195 19.4 Retrieving Things from Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Chapter 20. Team and Iterative Development . . . . . . . . . . . . . . . . . . . 199 20.1 Smalltalk System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 20.2 Models and Their Management in the Smalltalk Environment . . . . . 200 20.3 The Team Organization and Subsystem Building . . . . . . . . . . . . . . 200 20.3.1 The Prerequisite Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 20.3.2 The Proxy Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 20.3.3 The Hybrid Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 20.4 Iterative and Incremental Development . . . . . . . . . . . . . . . . . . . . . 202 Appendix A. How Do I? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 A.1 Create a Hypertext Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 A.2 Create a New Model Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 A.3 Create a New Protocol and Add Attributes and Message Specifications 206 A.4 Use the Path Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 A.5 Change a Parameter Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 A.6 Create a Link between Model Elements . . . . . . . . . . . . . . . . . . . . . . . . . 209

vi

VisualAge Smalltalk UML Designer

A.7 Delete a Figure Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 A.8 Delete a Relationship in a Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 A.9 Rename a Model Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 A.10 Make the Model Consistent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 A.11 Change Figure Fonts and Colors in Diagrams . . . . . . . . . . . . . . . . . . . 213 Appendix B. Installation of VisualAge UML Designer . . . . . . . . . . . . . 215 Appendix C. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 C.1 Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 C.2 UML Topics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 C.3 Code Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 C.4 Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 C.5 Publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 C.6 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Appendix D. Special Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Appendix E. Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 E.1 International Technical Support Organization Publications . . . . . . . . . . 221 E.2 Redbooks on CD-ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 E.3 Other Publications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 How To Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 How IBM Employees Can Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . 223 How Customers Can Get ITSO Redbooks. . . . . . . . . . . . . . . . . . . . . . . . . . . 224 IBM Redbook Order Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 List of Abbreviations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 ITSO Redbook Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

vii

viii

VisualAge Smalltalk UML Designer

Figures 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40.

The Relationship Browser with Text and Hypertext Links . . . . . . . . . . . . . . 4 The Focus [Xxxx...] Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 The Open [Xxxx...] Path Browser with Text Displayed in Summary Option. 6 The Open [Xxxx...] Hierarchy Browser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 The Edition Browser [Xxxx...]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 The Use Case Diagrammer [Xxxx...] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 The Class Diagrammer [Xxxx...] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 The Sequence Diagrammer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intended Work Paths of the VisualAge UML Designer . . . . . . . . . . . . . . . 13 Code Generation and Transformation Mechanism . . . . . . . . . . . . . . . . . . 20 Case Study: Context Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Case Study: A Sample Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . 23 Case Study: The Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Smalltalk System Transcript: VisualAge UML Designer Start Menu . . . . . 30 Relationship Browser: Create Model... . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Specify New Model Dialog: Names and Prefix . . . . . . . . . . . . . . . . . . . . . 31 Relationship Browser: A Library Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Relationship Browser: New Requirements . . . . . . . . . . . . . . . . . . . . . . . . 33 Information Required Dialog: New Requirement Name. . . . . . . . . . . . . . . 34 Relationship Browser: Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Relationship Browser: Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Relationship Browser: New Satisfied Requirement Link . . . . . . . . . . . . . . 41 Select the Requirement to link to for Satisfied Requirement . . . . . . . . . . . 42 Focus Browser: Use Case Satisfied Requirements Links . . . . . . . . . . . . . 43 Relationship Browser: Insert New Hypertext Link . . . . . . . . . . . . . . . . . . . 45 Select Object To Link To (Hypertext) Dialog . . . . . . . . . . . . . . . . . . . . . . . 46 Relationship Browser: Actor Hypertext Link and Index Hand Cursor . . . . 47 Relationship Browser: Actor and Thing Hypertext Links . . . . . . . . . . . . . . 54 Relationship Browser: Actor, Thing, and Concept Hypertext Links . . . . . . 57 Relationship Browser: All Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Use Case Diagrammer [Book Management]: Group/System Figure . . . . . 70 Library System Overview Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Use Case Diagram: Book Management . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Use Case Diagram: Customer Management . . . . . . . . . . . . . . . . . . . . . . . 74 Use Case Diagrammer: Book Loan Management . . . . . . . . . . . . . . . . . . . 75 Relationship Browser: All Use Case Diagrams . . . . . . . . . . . . . . . . . . . . . 75 Responsibles with Responsibilities and Use Cases . . . . . . . . . . . . . . . . . 82 Specify New Responsibility Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 The Select the Role To Link To For Participants Dialog . . . . . . . . . . . . . . 86 Remove Book Use Case: Responsibility Hypertext Link As Insert . . . . . . 89

© Copyright IBM Corp. 1998

ix

41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83.

x

Generate Protocols for Book File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Generate Protocols for Library Model (All Things). . . . . . . . . . . . . . . . . . . 99 Focus []: Messages after Protocol Generation . . . . . . . . . . . 100 Parameters of the addBook Message Specification . . . . . . . . . . . . . . . . 101 Open [Xxxx...] Path Browser (Model... Parameter) . . . . . . . . . . . . . . . . . 101 Open [Xxxx...] Hierarchy Browser (Model... Message) . . . . . . . . . . . . . . 103 Generate Class Design for Protocol Xxxx Dialog . . . . . . . . . . . . . . . . . . 107 Focus [Book File] Browser: Class Design with Instance Methods . . . . . . 109 Class Diagram: Drop, Attach, Edit, and Format Class Figure . . . . . . . . . 113 Class Diagrammer Figure Pop-Up Menu with Submenus . . . . . . . . . . . . 114 Filtering Options for Class Figure Detail Presentation . . . . . . . . . . . . . . . 115 Class Diagrammer [Initial Class Designs] (Object Model) . . . . . . . . . . . . 117 Relationship Figure Pop-Up Menu (Sample for Title-Book). . . . . . . . . . . 119 Initial Class Designs and Diagram: Adjusted and Complemented. . . . . . 120 Sequence Diagrammer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Choose a Method Dialog in the Sequence Diagrammer . . . . . . . . . . . . . 126 Choose a Method Dialog in the Sequence Diagrammer . . . . . . . . . . . . . 126 Sequence Diagrammer: Add First Book of a Title Diagram . . . . . . . . . . . 128 Sequence Diagram: Alternative Invocation Points of assignIdTo: . . . . . . 129 Class Diagram of the Refined Class Designs . . . . . . . . . . . . . . . . . . . . . 139 Class Diagram of the Extended Model . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Model Element Description with Embedded Diagram Hypertext Link.. . . 150 Publishing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Output Sample of Input displayed in Figure 62 on page 150. . . . . . . . . . 151 Publication Cover Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Published Use Case with Hypertext Links . . . . . . . . . . . . . . . . . . . . . . . . 153 Class diagram of the Library Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Subsystems of the Library Management System . . . . . . . . . . . . . . . . . . 158 Pool of Generalized Subsystems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Uses Subsystems Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Protocol Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Merging Object’s Services Into Object’s Class . . . . . . . . . . . . . . . . . . . . 166 Class and Instance Methods of the New Book Class . . . . . . . . . . . . . . . 167 Creating a TitleCategory Association 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Creating a TitleCategory Association 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Relationship Browser:Stereotypes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 System Settings: Choosing Smalltalk as the Programming Language . . 181 Generate a Real Smalltalk Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Create Real Smalltalk Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Choosing Java As the Programming Language . . . . . . . . . . . . . . . . . . . 186 Create Real Java Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Creating a New Class Design for an Existing Smalltalk Class. . . . . . . . . 193

VisualAge Smalltalk UML Designer

84. 85. 86. 87. 88.

Retrieving Protocol from Smalltalk Class. . . . . . . . . . . . . . . . . . . . . . . . . 195 Retrieving Class Designs and Protocols from Real Classes . . . . . . . . . . 197 The Retrieve Process: Mapping of Real Class - Protocol - Class Design 198 Edit Dialog for Changing Figure Settings. . . . . . . . . . . . . . . . . . . . . . . . . 214 Font Selection and Choose a Color Dialogs . . . . . . . . . . . . . . . . . . . . . . 214

xi

xii

VisualAge Smalltalk UML Designer

Tables 1. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36.

Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi Task Assignments and Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Requirements for the Library System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Use Cases and Satisfied Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Actors with General Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Things 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Things 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Things 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Concepts 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Concepts 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Use Cases with Hyperlink Marks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Extending and Used Use Cases 1 with Hypertext Link Marks. . . . . . . . . . 63 Extending and Used Use Cases 2 with Hypertext Link Marks. . . . . . . . . . 64 Use Case Diagrammer: Figures and Creation Tools . . . . . . . . . . . . . . . . . 69 Responsibilities Defined by VisualAge UML Designer. . . . . . . . . . . . . . . . 77 Thing Responsibilities 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Thing Responsibilities 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Thing Responsibilities 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 State and Visual Clue of Attributes and Methods . . . . . . . . . . . . . . . . . . 106 Class Diagrammer: Figures and Creation Tool . . . . . . . . . . . . . . . . . . . . 112 Object Interaction Diagrammer: Figure Creation Tools . . . . . . . . . . . . . . 123 Things 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Thing Responsibilities 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Refining Attribute Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Refining Message Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Thing Responsibilities 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Message Parameter and Return Types 1 . . . . . . . . . . . . . . . . . . . . . . . . 140 Message Parameter and Return Types 2 . . . . . . . . . . . . . . . . . . . . . . . . 141 Message Parameter and Return Types 3 . . . . . . . . . . . . . . . . . . . . . . . . 141 Message Parameter and Return Types 4 . . . . . . . . . . . . . . . . . . . . . . . . 141 Messagel Parameter and Return Types 5 . . . . . . . . . . . . . . . . . . . . . . . . 142 Thing Responsibilities 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Message Parameter and Return Types 6 . . . . . . . . . . . . . . . . . . . . . . . . 144 Thing Responsibilities 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Message Parameter and Return Types 7 . . . . . . . . . . . . . . . . . . . . . . . . 145 Subsystem, Use Case and Object Cluster Pattern . . . . . . . . . . . . . . . . . 159

© Copyright IBM Corp. 1998

xiii

xiv

VisualAge Smalltalk UML Designer

Preface VisualAge UML Designer is a full-life cycle tool for object-oriented development. It covers requirements analysis, analysis, design, and code generation. The tool also provides mechanisms for maintenance, reengineering, consistency checking, configuration, and version and release management. Code can be generated for either Smalltalk or Java. VisualAge UML Designer complements the VisualAge product family in the early phases of object-oriented application development. The output of VisualAge UML Designer is the input for VisualAge ObjectExtender, the persistence and transaction framework and tool, that is also member of the IBM VisualAge product family. VisualAge UML Designer integrates analysis and design into the VisualAge development environment. The sample case study presented in the book is based on the UML notation, and the goal is to implement as much as possible using the tool. The concepts of object-oriented analysis (OOA) and object oriented-design (OOD) are stressed. Integration of all phases of object-oriented development are taken into consideration. After reading this book and following the steps provided, the reader should be able to understand and perform object-oriented analysis and design using VisualAge UML Designer. This redbook is intended for analysts, designers, software developers, application experts, and technical project managers who want to become familiar with VisualAge UML Designer. A basic understanding of object technology is assumed, although the book may also help to introduces some methodological analysis and design.

How the Book Is Organized The book is divided into three parts: • Part 1 contains an introduction to VisualAge UML Designer, describes the concepts and functions of the tool including its look and feel, and provides a general understanding and work path guidelines on how to use the tool to go through the modeling process. Part 1 also includes the very basics of the case study for the sample application to be implemented using VisualAge UML Designer. Some of the analysis and design artifacts are described using the Unified Modeling Language (UML) as the notation method. We recommend reading Part 1 before Part 2.

© Copyright IBM Corp. 1998

xv

• Part 2 maps the work path guidelines into the tool. It provides "how-to" steps iterating through the development cycle in the context of a case study. Requirements gathering, analysis, writing use cases, and designing classes are covered. The sections in part 2 of the book are structured like this: • • • •

Introduction to the topic Methodological step with explanation and mapping to the tool Step-by-step description of how to use VisualAge UML Designer Description of the results of the step

• Part 3 covers advanced topics that might be of interest to the experienced analyst, designer, implementer and project leader. It also covers some aspects that are not extensively discussed for the sample application used in the case study. The appendixes contain a collection of how tos, which are referenced in Part 2, and serve as a reference for daily modeling activities. Some information about the installation and limitations of the tool are included.

Naming Conventions Table 1 lists the naming conventions used throughout the book. Table 1. Naming Conventions

Style

Item

Examples

Bold

Elements of the tool

Window Titles and Menu Items

Italics

System names

Application Name

Bold & Italics

User-defined objects

Library Model

Example

Text you have to type in

Text to type in

The Team that Wrote this Redbook This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, San Jose Center. Markus Muetschard is an IT and Object-Oriented Consultant at the IBM International Technical Support Organization, San Jose Center. He writes extensively and teaches IBM classes worldwide on all areas of object-oriented technology, with a focus on the VisualAge (Smalltalk) product

xvi

VisualAge UML Designer

family. Before joining the ITSO, Markus worked in the IT Consulting department of IBM Switzerland, consulting and mentoring for object-oriented customer projects. Byron Munday is an Advisory IT Specialist at IBM South Africa. He has 12 years of experience in object technology. Byron holds a National Diploma in Computer Science from the Pretoria Technocon. He is responsible for object technology training in South Africa. Matthias Nieder is an IT Specialist at IBM Germany. He has four years of experience in object technology. Matthias holds a Diploma in Mathematics. Matthias’ areas of expertise include object-oriented analysis and design. Wolfgang Sanyer is an IT Specialist at IBM North America. He has eight years of experience in object-oriented technology. Wolfgang holds a Bachelor of Science degree in Computer Science from Polytechnic University in New York. His areas of expertise include client/server architecture development, artificial intelligence, and object-oriented development. Thanks to the following people for their invaluable contributions to this project: Marianne Schmid, Credit Suisse Group and OTI Zurich, Switzerland Dr. Peter Meyer, LogicLine, Aidlingen, Germany Nick Knowles, OTI (Object Technology International Inc., Canada) in England Ueli Kaempfer and Rene Pletschet, IBM Switzerland Bernd Kaponig, IBM Austria Pat Huff, Alan Hui, Brian Lang, and Holger Schwarzer of the IBM VisualAge Development and Services in the RTP (Research Triangle Park), Raleigh, NC, USA and last, but not least: Elsa Barron, Mary Comianos, Maggie Cutler, Pat McCarthy, Ueli Wahli, and Laymond M. Pon of the International Technical Support Organization, San Jose Center.

Comments Welcome Your comments are important to us!

xvii

We want our redbooks to be as helpful as possible. Please send us your comments about this or other redbooks in one of the following ways: • Fax the evaluation form found in “ITSO Redbook Evaluation” on page 245 to the fax number shown on the form. • Use the electronic evaluation form found on the Redbooks Web sites: For Internet users For IBM Intranet users

http://www.redbooks.ibm.com http://w3.itso.ibm.com

• Send us a note at the following address: [email protected]

xviii

VisualAge UML Designer

Part 1. VisualAge UML Designer Introductory Tour

© Copyright IBM Corp. 1998

1

2

VisualAge Smalltalk UML Designer

Chapter 1. What Is VisualAge UML Designer? VisualAge UML Designer, a member of the VisualAge product family, complements and completes the full development life cycle. It provides capabilities to capture requirements, build analysis and design models, and generate code for Smalltak and Java. You can create models interactively, using browsers and diagramers, and publish them as hardcopy or HTML documents. You can also use VisualAge UML Designer to analyze and document existing Smalltalk applications. Reverse modeling for Java is in plan as well as the integration into the VisualAge Java Integrated Development Environment (IDE). The output of VisualAge UML Designer is the input for the VisualAge ObjectExtender, the persistence and transaction framework and tool, which is also a member of the VisualAge product family. VisualAge UML Designer is tightly integrated with the VisualAge Smalltalk IDE. All models are stored in the VisualAge Smalltalk repository. This integration provides several significant benefits: • Models can be treated as software components. The VisualAge Smalltalk repository provides configuration management and version control of all design artifacts in the model, including import, export, compare, and reconcile capabilities. Individual model elements, as well as entire models, can evolve through many versions, and previous versions are retrievable. • Model elements can be related to their implementations, and implementations can be explained in terms of higher level abstractions. • Traceability links make it possible to navigate between the model and implementation entities. • The tool enables the propagation of adjustments from implementation to the model, so it supports the so-called round-trip engineering metaphor. • The transformation from model to implementation is very straightforward. The Smalltalk language enables an object-oriented implementation. VisualAge UML Designer provides design artifacts and flexible tools and prescribes no specific object-oriented methodology; it supports those artifacts of object-oriented analysis and design that are common to the major methodologies and have generally proved most useful to programmers. VisualAge UML Designer supports an evolutionary approach to software development, where the design undergoes continual revision even after implementation has begun.The VisualAge UML Designer features discussed in the next sections are modeling, browsing, drawing, and publishing.

© Copyright IBM Corp. 1998

3

1.1 Modeling Distinct model and design elements are provided for each of the separate stages of the modeling process: requirements capture, analysis, design, and implementation. Traceability links make it possible to maintain connections between design elements and eventual implementation elements. Elements are organized into models representing subsystems.

1.2 Browsing Specialized browsers make it possible to organize object-oriented model and design artifacts as named model elements. Each element can have a natural-language description and hypertext links to other related elements.

1.2.1 Relationship Browser

Figure 1. The Relationship Browser with Text and Hypertext Links

4

VisualAge UML Designer

The Relationship Browser (Figure 1) is the heart of VisualAge UML Designer. It shows the available models, the design elements that exist in each model, and the relationships that exist among them. From the Relationship Browser, you can create, change, and browse design elements, create, change, and browse their relationships, and launch the other VisualAge UML Designer browsers, diagrammers, and editors.

1.2.2 Focus Browser The Focus [Xxxx...] browser (Figure 2) is structured nearly the same as the Relationship Browser. In fact it also browses relationships. The only difference is that the focus browser focuses on one single model element.The focus browser is the default browser for all nondiagramming elements in VisualAge UML Designer. When you double-click on an element, it opens with the focus browser—except for diagrams, in which case the element opens with the appropriate diagrammer.

Figure 2. The Focus [Xxxx...] Browser

What Is VisualAge UML Designer?

5

1.2.3 Path Browser The Open [Xxxx...] path browser (Figure 3) is similar to the focus browser in that it lists relationships for a model element. In contrast to the focus browser, you can open the path browser for more than one element. You can then select the specific model element in the path browser and compare relationships within one browser. You can also browse more than one level with the path browser. For example, on the first level you can get a list of all associated relationships, and then select an element and get information about it, all within the same browser. The path browser supports up to four levels.

Figure 3. The Open [Xxxx...] Path Browser with Text Displayed in Summary Option

6

VisualAge UML Designer

1.2.4 Hierarchy Browser The Open [Xxxx...] hierarchy browser is quite different from the Relationship Browser, focus browser, and path browser. It consists of only two panels. One panel shows a description of the element currently selected in the other panel, which is in fact only a textual based tree view of your selected elements that shows dependencies to other elements through expansion (Figure 4).

Figure 4. The Open [Xxxx...] Hierarchy Browser

What Is VisualAge UML Designer?

7

1.2.5 Edition Browser The Edition Browser [Xxxx...] (Figure 5) is a specialized browser, that you use only if you want to load another edition of a specific component, such as a model, a model element, or a text.

Figure 5. The Edition Browser [Xxxx...]

8

VisualAge UML Designer

1.3 Diagrammers Three graphical editors support the drawing of diagrams in the Unified Modeling Language (UML) notation. These editors are the class diagrammer, the sequence diagrammer, and the use case diagrammer. Diagrams are, in effect, tightly integrated views of the underlying model, and they automatically reflect changes to design elements. You also can create new model and design elements.

1.3.1 Use Case Diagrammer With the Use Case Diagrammer [Xxxx...] (Figure 6) you create graphical views of your use cases.

Figure 6. The Use Case Diagrammer [Xxxx...]

What Is VisualAge UML Designer?

9

The use case diagramer supports representations of actors, use cases, groups (systems and subsystems), and annotations, and the connections between them as defined in the underlying model. You also can create new actors, use cases, groups (systems and subsystems), and annotations to your model.

1.3.2 Class Diagrammer With the Class Diagrammer [Xxxx...] (Figure 7) you create a static class diagram as a view of the underlying model.

Figure 7. The Class Diagrammer [Xxxx...]

10

VisualAge UML Designer

1.3.3 Sequence Diagrammer The Sequence Diagrammer [Xxxx...] (Figure 8) is the only kind of interaction diagram tool included in VisualAge UML Designer.

Figure 8. The Sequence Diagrammer

1.4 Publishing VisualAge UML Designer can generate documentation from models and the design elements they contain. Supported output formats include HyperText Markup Language (HTML), and Rich Text Format (RTF).

What Is VisualAge UML Designer?

11

12

VisualAge UML Designer

Chapter 2. Before You Jump in: Work Path Guidelines In this chapter we address our discussion to experienced analysts and designers who have already worked with other modeling tools. Many modeling tools are based on a single source concept: changes you make in one place in the tool are visible in all parts and views. For example, changes in a class diagram show up immediately in the class design. VisualAge UML Designer differs from these tools in exactly this point. At first glance you might think (as we did) that this is a disadvantage. But when you take a closer look at how to use VisualAge UML Designer to get the most out of it, you will find it a very powerful tool. See the text boxes related to Requirements, Analysis, and Design later on in this chapter). To show you how VisualAge UML Designer differs from other tools with which you might be familiar, we give you a short overview of how VisualAge UML Designer expects you to develop your applications in the early phases. Figure 9 shows the work paths of VisualAge UML Designer.

Class Design -> Link to Protocols -> Link to Real Class

Noneditable Editable

Thing

Protocol

Real Class

-Responsibilities

- Message Specifications - Attributes

- Methods - Attributes

Transformation Generating

Retrieving

Figure 9. Intended Work Paths of the VisualAge UML Designer

© Copyright IBM Corp. 1998

13

The most important aspect of the mechanism introduced by class designs is decoupling. You really do not have to document every implementation detail in the "classes" you have in your analysis. Besides model elements, VisualAge UML Designer also provides diagrams, which consist of figures. Diagrams are only views to your model in VisualAge UML Designer. There is no way to diagram something that is not represented in the underlying model. If you create a new element or relationship during diagramming, it is first created in your model. Conversely, not every model element or relationship shows up in a diagram. You select only the elements you want to document graphically in your diagrams. Therefore VisualAge UML Designer distinguishes between model elements, which belong to the underlying model, and figure elements, which are in fact the views of the model elements in the diagrams. A figure element cannot exist without its model element. Table 1 gives an overview of the modeling tasks, that constitute these development phases: • Requirements - describing the a system the user wants to have • Analysis - describing in detail what the system must be able to do • Design - describing how the system should fulfill the requirements The table shows the assignment of tasks for the typical phases of object-oriented application development and for the VisualAge UML Designer phases using the task filter in the Options menu. NOTE: We take you through the case study, using the order of the Typical Phase column. Using the tool’s filter options takes you in another direction. Recognize, however that neither in object-oriented development nor in the tool are you forced to adhere to the order introduced by the phases, as long as you have complete cycles—which underscores the iterative character of object-oriented development, where definitions are refined in each cycle. Throughout the book we focus on the forward modeling process in order to build a new application. Nevertheless the tool also supports reverse engineering (see Chapter 19, “Reverse Engineering and Integrating Existing Classes” on page 191).

14

VisualAge UML Designer

Table 1. Task Assignments and Phases

Task

Typical Phase

Phase in the tool

Requirements

Requirements

Requirements

Use cases

Analysis

Use case diagrams Actors Things Concepts Protocols Exceptions

Analysis Analysis/Design

Groups Prerequisite models

Requirements/Analysis Design

Requirements

Stereotypes Class diagrams

Analysis/Design

Class designs

Design

Sequence diagrams

2.1 Requirements For the requirements phase of application development, VisualAge UML Designer provides the following items: • Requirements: Textual description of what the application should be able to do (see Chapter 4, “Requirements Analysis” on page 29) • Use cases: Textual description of an interaction with the system (see Chapter 5, “Use Cases” on page 37) • Use case diagrams: Graphical representations of uses cases (see Chapter 6, “Use Case Diagrams” on page 67) • Actors: Real people who interact with the system (see 5.2.1, “Identifying Actors” on page 44) • Things: Candidate classes, something that looks as if it might become a real class later (see 5.2.2, “Identifying Things” on page 49)

Before You Jump in: Work Path Guidelines

15

• Concepts: Something the application should fulfill, but you are not sure whether it will be an actor, a thing, or something else (see 5.2.3, “Identifying Concepts” on page 54). For organizing your model, VisualAge UML Designer provides the following features: • Groups: Collections of objects with the same content (see 16.1, “Abstraction” on page 175) • Dependent/prerequisite models: Other parts of your overall model that either are prerequisites for your model (prerequisite models) or need your model as a prerequisite (dependent models) (see 15.3, “Protocols, Stereotypes, and Prerequisites” on page 162) As advanced options you can define: • Stereotypes: Classification of objects (see 15.3, “Protocols, Stereotypes, and Prerequisites” on page 162) From a data point of view, at the requirements stage, things are the most important elements. In fact, VisualAge UML Designer treats things as candidate objects and provides a generation option for generating protocols out of things. While identifying and defining things, you assign responsibilities to them. These responsibilities should fulfill some previously defined requirements and represent the first "methodlike" elements in your model. In fact VisualAge UML Designer uses the names of the responsibilities to generate the message specifications in protocols, which then are transformed into real methods later in the process (of course, it is always possible to change the names in that process). For this reason you should be specific when writing responsibilities. Responsibilities are not requirements. They "implement" requirements.

It is also possible to define collaborators, as you might be used to when working with Class Responsibility and Collaborator Cards (CRC Cards). VisualAge UML Designer implements this mechanism through participants in the responsibilities. Participants can be other things or actors. When generating protocols, the tool transforms participants into parameters in the message specifications. Message specifications are defined in protocols comparable to methods in classes.

16

VisualAge UML Designer

2.2 Analysis In the analysis phase of application development the following tasks should be dealt with: • Exceptions: Mechanisms for business-oriented and/or constraint-dependent alternative flow • Class diagrams: Graphical views of relationships between classes (see Chapter 10, “Class Diagrams” on page 111) • Protocols: The main artifacts of the analysis phase: definition of possible types, classes, and interfaces (see Chapter 8, “Protocols” on page 95) • Groups: Refinement of the analysis groups Although it is possible to generate protocols for every thing, to get useful protocols you first should define responsibilities for the things you have found (see Chapter 7, “Responsibilities and Participants (Collaborators)” on page 77).

Protocols are central to VisualAge UML Designer, because nearly every change that should be consistent in the whole model requires a change in a protocol. Protocols are used to type objects in VisualAge UML Designer, so a class cannot be completely defined in the tool unless there is a protocol for each of the classes the class uses in any way (aggregation, inheritance, or even as a parameter to a method). Therefore you must always create a protocol before you create a new class (real class or design only), or you must retrieve a protocol from an existing, real class that you want to include in your model (see 19.2, “Retrieving Protocols from Real Classes” on page 193).

2.3 Design When it comes to design, VisualAge UML Designer provides the following features: • Sequence diagrams: Graphical representations of message flows for use cases (see Chapter 11, “Interaction Diagrams” on page 121) • Class diagrams: Refined analysis class diagrams (see Chapter 10, “Class Diagrams” on page 111) • Class designs: Conceptual objects for integrating analysis artifacts and implementation aspects (sse 9.1, “Class Design” on page 105)

Before You Jump in: Work Path Guidelines

17

Do not make the same mistake we made while working with the tool: you cannot directly design a class with class designs!

In VisualAge UML Designer, class designs are used as a bridge between analysis and design and implementation. You can retrieve class design information from either a real Smalltalk class (not yet from a Java class) or from a protocol, but you cannot add features directly to a class design. Therefore, implementation specific details do not automatically show up in your analysis artifacts (protocols), as they do with other tools. See Figure 9 on page 13 for a structural overview of the intended work paths with VisualAge UML Designer. In class diagrams you can only add a method or an attribute to a class when you have generated a real class and identified the special class design with it. However, the straightforward way to add methods or attributes to a class design is to add them to your protocols before generating the class design based on the protocols. If you link the class design to a protocol (see Appendix A.6, “Create a Link between Model Elements” on page 209), every change to a protocol is then automatically reflected in the class design.

Note (for Smalltalk): When a class design is linked to a real class, the definition of the real class is always preferred to the model definition (see 17.1, “Generation of Smalltalk Classes” on page 179). For example, if a real class A of class design A is a subclass of a real class B of class design B, you cannot define class design A as a subclass of class design C with real class C. You must first unlink the real class A from the class design A, then let class design A inherit from class design C. Further on you must either: • Create a new real class A with name ANew inheriting from class C and link it to the changed class design A or • Unload (or delete) the real class A from the image, and Create the new class A from the changed class design A because a real class still exists in the image—it is just no longer linked to the class design.

18

VisualAge UML Designer

2.4 Animation of the Model VisualAge UML Designer provides no dynamic mechanism, such as an animator, to test or verify the model. You must rely on the gemerated code for something executable. For static checking see 2.5, “Consistency Check” on page 19. Walkthroug techniques with scenarios can be used to verify the rmodeling results. Use cases can be linked to scenario model elements. A scenario can be linked to groups (systems or subsystems), in which it may occur, and the description can have hypertext links to other model elements.

2.5 Consistency Check VisualAge UML Designer provides a function for consistency checking your model. The consistency check finds inconsistencies such as unresolved references to model elements. Deleting or changing a model element without saving the image or adjusting the affected diagram results in unresolved references. Figures are attached to the underlaying, deleted model element. The consistency check can be run at any time and on the whole or on parts of the model. For a description of how to check your model, see Appendix A.10, “Make the Model Consistent” on page 212.

2.6 Implementation Implementation is supported only through code generation and in Smalltalk by retrieving information from real classes for your model. All other implementation aspects are covered by the basic VisualAge family tools. Actually, VisualAge UML Designer generates pure Smalltalk or Java source files, but it still provides more meta information about your model. Every generation in VisualAge UML Designer is a transformation from a source to a specified target according to defined rules. The rules are implemented as template generation classes. Thus experienced Smalltalk developers can write their own plug-ins or generation frameworks. In fact, VisualAge UML Designer is intended to provide information for VisualAge ObjectExtender, which provides the persistence and (image or memory) transaction services to your application. Another possible plug-in is a public interface generator for VisualAge parts. Figure 10 depicts the code generation mechanism. See Chapter 17, “Smalltalk Code Generation” on page 179 and Chapter 18, “Java Code Generation” on page 185 for more about code generation.

Before You Jump in: Work Path Guidelines

19

Plug-Ins Frameworks Source (Class Design)

Target (Real Class) Transform

Figure 10. Code Generation and Transformation Mechanism

At first glance it might seem awkward to design classes only through protocols or implementation classes, but the more you think about it, the more sense it makes for big applications that really need analysis and design first. However, if your application is so small that you can directly decide which classes you need and what they must look like, you really do not need a class design first. You simply implement the class directly and, if you want, retrieve your class design from your real class (for documentation purposes).

20

VisualAge UML Designer

Chapter 3. Case Study: The Library Management System The case study used throughout the book to help illustrate most of the VisualAge Smalltalk UML Designer features is a library management system. We develop the case study without the tool before we started to work with VisualAge Smalltalk UML Designer. Therefore we describe in this chapter only analysis and design results we want to achieve with the tool.

3.1 Requirements Figure 11 shows the basic system requirements:

searches books on loan searches customers searches books/titles maintains customers

Librarian

maintains books manages book loans reserves books/titles

Library System

reserves books/titles searches books/titles

Customer searches books on loan

requests end-of-day processing

System Timer

Figure 11. Case Study: Context Diagram

The library management system, from here on called the system, consists of a library of books. A person, from here on called a customer, interacts with the system and, among other functions, should be able to borrow books for a period of time.

© Copyright IBM Corp. 1998

21

An authorized person, called a librarian, is the only person allowed to add or remove books from the library. The librarian should be able to make an entry in the system whenever a book is lost. Customers should be able to borrow books from the library. When a customer borrows a book or returns it, the librarian will update the loan information of the library system to keep the system consistent. A customer should be able to request a list of books he or she has on loan at the moment. The librarian should be able to provide such a list for any customer. Both the librarian and the customer should be able to search the library for book titles. All searches are performed on titles and not on physical copies of a title. But when a physical book is loaned that copy will be identified. Note the difference between a book title and a physical book copy. Each title in the library will have one or more physical copies—books—available for loan. A customer searches for the title of a book and then borrows a physical copy of that title. Each title will record the number of copies of the book it represents that are available in the library. The system should provide the capability of running an end-of-day process that includes going through the existing reservations and verifying whether they are still active. This task is triggered by the system timer. During the process of requirements gathering we identified the following actors: • Librarian: an administrative person who maintains the system data and lends books to customers. • Customer: any person who is registered within the system as an authorized library user. • System Timer: a time keeper that notifies the system of a date change

3.2 Interactions We identified the following interactions between the librarian and the library system: • The librarian requests all books on loan from the library system. • The librarian searches for customers in the library system. • The librarian searches for books in the library system. • The librarian maintains customers in the library system. • The librarian maintains books in the library system.

22

VisualAge Smalltalk UML Designer

• The librarian maintains book loans in the library system. We identified the following interactions between the customer and the library system: • The customer reserves a book in the library system (see Figure 12). • The customer searches for books in the library system (see Figure 12). • The customer requests a list of all books he or she has on loan from the library system. We identified the following interaction between the system timer and the library system: • The system timer requests end-of-day processing from the library system.

Library System

Use Case Customer

reserve a book

Used Use Case search for books

Figure 12. Case Study: A Sample Use Case Diagram

3.3 Static Model During the analysis phase our goal was to create an example that would be small enough to be understood easily and yet large enough to include at least one of each of the relationship types found in the UML standard. For a similar reason we wanted to model the state design pattern in a second step,

Case Study: The Library Management System

23

although in our example it would be possible to handle this information in the book class or by an additional loan or borrow class—adding history. Therefore we decided to: • Delay the introduction of the state design pattern until the design phase, where it then will be the contract between the customer and his or her books on loan (association instead of in Figure 13) • Cover modeling alternatives in a separate chapter (Chapter 15, “Modeling Alternatives and Extensions” on page 157). As a result the presented model does not imply to be the ultimate solution. It merely serves as a tool that will enable you to gain a common understanding and at the same time provides the flexibility necessary to showcase the functions of VisualAge UML Designer. Furthermore, the analysis does not imply or subscribe to any architectural bias or other analysis standard. During the analysis phase we identified the following candidate classes: • Customer: a class that is responsible for recording customer details • Title: a class that records a book’s title and the names of the authors • Book: a class that uniquely identifies a physical instance of a title • Category: a class that models a logical grouping of books • CategoryTitle: an association class that maps books into one or more categories • Reservation: a class that records titles that customers have reserved • Status: a class that represents the mutually exclusive states of a book • Available: a class that records the status of a book when it can be loaned • Borrowed: a class that records the status of a book when it has been borrowed. The class records the loan date, return date, and customer • Overdue: a class that records the status of a book when it is not returned by the return date • Lost: a class that records the status of a book that has been lost • Reserved: a class that records the status of a book that has been returned and then immediately held for a customer who has a reserved it Figure 13 shows the class diagram—classes and associations among the classes.

24

VisualAge Smalltalk UML Designer

Category

Title

CategoryTitle

Book



Customer

Status

Reservation



Available

Borrowed

Overdue

Lost

Reserved

Figure 13. Case Study: The Class Diagram

3.4 Assumptions The focus is on the analysis and design phases of the business model. The user interface design falls outside the scope of this book and is not discussed. All user information about the user interface is also not discussed. The user interface should be as simple as possible and defined during the implementation phase.

Case Study: The Library Management System

25

26

VisualAge Smalltalk UML Designer

Part 2. Using VisualAge UML Designer

© Copyright IBM Corp. 1998

27

28

VisualAge UML Designer

Chapter 4. Requirements Analysis The first step in the forward development process is to capture the requirements for the system being developed. The requirements are formulated by the users of the system and describe what the system must do. Based on written descriptions and conversations with users, you can then begin to derive a list of discrete requirements for the system. Requirements describe what functions the system must perform in order to meet its fundamental business objectives. They define the boundaries of the system, and some functions, though important, might turn out to be outside the scope of the system being developed. During the requirements analysis phase, analysis is fairly informal. There are no strict rules governing what you can include as a requirement, nor what level of detail is appropriate. Indeed, the list is very likely to change over time, as you gain a better understanding of the problem domain and the system boundaries. During the requirements analysis phase, requirement elements can be used to capture any statements that are useful for setting the system’s objectives. Ideally, requirements should be short, succinct, and focused on the essential purpose of the system. Often, a single sentence will suffice; other times, you might want to provide further explanation, which you can enter as hypertext in the Relationship Browser’s hypertext pane. The requirement text should avoid any unnecessary descriptions of how the system will be implemented; instead, it should describe what the system must do for the user in order to work successfully. If you have quantifiable requirements that must be met, such as response times or volume capacities, you can include those as well.

4.1 Getting Started To begin modeling a new system, you must first create a new model in the Relationship Browser. A model is a collection of related analysis and design artifacts. These artifacts may include but are not limited to requirements, use cases, objects, and diagrams. VisualAge UML Designer calls artifacts model elements. In the VisualAge team library, a model is stored within the context of a Smalltalk application. Models may have other models as prerequisites.

© Copyright IBM Corp. 1998

29

4.2 Creating a New Model Prerequisites 1. You should have VisualAge UML Designer installed successfully. Step 1: Start the Relationship Browser To start working in UML Designer, select UML Designer>Relationship Browser from the System Transcript window (Figure 14).

Figure 14. Smalltalk System Transcript: VisualAge UML Designer Start Menu

Step 2: Create a New Model In the Relationship Browser (Figure 15), select Source>Create Model.... You can also select Create Model... from the pop-up menu of the source list (leftmost list pane) in the Relationship Browser.

Figure 15. Relationship Browser: Create Model...

30

VisualAge UML Designer

Step 3: Capture Model Details In the Specify New Model dialog enter the information for the new model (Figure 16).

Figure 16. Specify New Model Dialog: Names and Prefix

1. The Specification Name of the model. This can be any name you want to use to identify the model (Note: We use ’A...’ to get on the top of the list...). A Library Model

2. The NameSpace Prefix for the model. This is an arbitrary string that will be used as a prefix to uniquely identify the model and its artifacts in the Smalltalk repository. You can accept the default value for this prefix, or you can add your initials or some other unique identifier if you share the same repository with other uses. Vam

3. The Application Name for the model. This is the name that will be used for the application containing the model elements. You will not normally need to access this application directly, so in most cases you can accept the default application name, which will be formed by appending the model name to the prefix and removing all spaces. VamLibraryModel

Step 4: Add the New Model Select OK. The new model appears in the list in the Relationship Browser (Figure 17). Results All of the models that are currently loaded into the image will appear in the top left pane. This includes the A Library Model you have just created.

Requirements Analysis

31

Figure 17. Relationship Browser: A Library Model

4.3 Identifying Requirements By analyzing the case study requirements specification in 3.1, “Requirements” on page 21, you can derive the following requirements for the library system: • Keep Book Information • Keep Customer Information • Keep Book Loan Information • Search Customers • Search Titles • Search Books On Loan • Reserve Titles • Perform End-Of-Day Processing

4.4 Defining Requirements Prerequisites 1. You should have created a model. Step 1: Select the Model Select A Lbrary Model from the list of models in the source list of the Relationship Browser (Figure 18).

32

VisualAge UML Designer

The middle pane or relationship list shows a list of possible relationships the model might have to the model elements it contains.

Figure 18. Relationship Browser: New Requirements

Step 2: Select Relationship In the middle pane or relationship list select the Requirements relationship. The rightmost pane or element list shows a list of requirements already defined for the model; since you have not created any yet, the list is empty, but on the bottom in the hypertext pane the definition of the term Requirement shows up. Step3: Open the Relationship Pop-Up Menu Right click on the Requirements relationship in the relationship list.

Requirements Analysis

33

Step 4: Create a New Requirement From the relationships list pop-up menu select New... Step 5: Capture Requirement Name In the Dialog in Figure 19 enter the Requirement Name : Book Information Keeping

Click on OK. The new requirement appears in the rightmost pane or element list of the Relationship Browser.

Figure 19. Information Required Dialog: New Requirement Name

Step 7: Capture Requirement Details Select the requirement Book Information Keeping in the element list and type in the description for that requirement in the hypertext pane at the bottom as follows: Keep information about the books of a library. Books have to be kept as titles and physical copies - the books themselves. Each must have its own unique identification.

Step 8: Save the Requirement Details Right click in the text pane and select Save from the pop-up menu. Step 9: Capture the Other Requirements Repeat step 5 through 8 to add all of the requirements listed in Table 2.

34

VisualAge UML Designer

Note: For your convenience, use the on-line version of the redbook - either html or pdf format, from which you can copy and paste the text to reduce your typing work. Table 2. Requirements for the Library System

Requirement Name

Details

Book Information Keeping

Keep information about the books of a library. Books have to be kept as titles and physical copies - the books themselves. Each must have his own unique identification.

Customer Information Keeping

Keep information about the customers of a library. Each customer must have a unique identification.

Book Loan Information Keeping

Keep book loan information. Distinguish among available, borrowed, overdue, reserved, and lost.

Books on Loan Searching

Support the search for books on loan (borrowed and/or overdue) of one title or of a customer.

Customer Searching

Support the search for customers.

Title Searching

Support the search for titles by words in the title and abstract, by author, and/or by category.

Title Reservation

Support the reservation of a title for a customer for a limited time up to a specific date, if all physical copies are loaned.

End-of-Day Processing

Perform end-of-day processing, which includes updating reservations and loans.

After you have added a requirement, it appears in the element list in the Relationship Browser (Figure 20). The text in the bottom pane can contain any kind of description you want to use for the requirement. It can also contain hypertext links to other model elements, as you will see later. You can change and extend the text at any time. Results All of the requirements for the selected model will appear in the element list. For the selected requirement, the detail text appears in the hypertext pane (Figure 20).

Requirements Analysis

35

Figure 20. Relationship Browser: Requirements

36

VisualAge UML Designer

Chapter 5. Use Cases Once you have captured your initial requirements, you can write the use cases for the system. A use case is the enumeration of steps performed to complete a specific task from start to finish. Rather than concentrating on how the system functions, use cases describe how the system will be used by its users—what the system must do from the user's perspective and what use cases the different users initiate or actors act in.

5.1 Identifying Use Cases Though more detailed than requirements, use cases are still quite informal. A use case should be a natural-language description, not pseudocode, and it should avoid any unnecessary assumptions about implementation. A use case should: • Help to capture the purpose of the system from the user's perspective • Define the system boundaries by identifying external agents (actors) The style and level of detail to use in writing use cases are matters of judgment and experience. The amount of detail you include depends on the novelty of the system and your familiarity with the problem domain. The level of detail can also vary from one use case to another. Some use cases might describe high-level interactions of real-world elements, while others might describe low-level interactions of actual system objects (when such objects are known). Try to avoid mixing levels of abstraction within a single use case. The contents of uses cases are not subject to any rigorous, programmable semantics. Therefore they may be less imprecise or even ambiguous, but they are succinct, high level, and can be understood and verified by the user. Here is a sample use case specification for the task of the librarian maintaining the information about the books in the library system: Maintain Books

© Copyright IBM Corp. 1998

The Librarian does maintain Book information in the Book File - Add Book, Update Book, and Remove Book information, and Print Book Labels. When adding a book, the Librarian has to be aware of the Book’s Title and its Categories.

37

5.1.1 Defining Use Cases Defining use cases is a straightforward task in VisualAge UML Designer and quite similar to defining requirements in 4.4, “Defining Requirements” on page 32. VisualAge UML Designer uses the same procedure to define any model element. We describe the procedure in a more general way, but step by step, in Appendix A.2, “Create a New Model Element” on page 206. Prerequisites 1. You should have created a model. 2. You should have created the requirements (recommended). Step 1: Select Relationship Select Use Cases in the relationship list of the Relationship Browser. Step 2: Create the New Use Case From the pop-up menu in the relationship list, select New... Step 3: Capture the Use Case Name When prompted, type: Maintain Books

as the name of the use case and click on OK. Step 4: Describe the Use Case Select the newly created use case Maintain books from the element list in the Relationship Browser and enter the following description in the hypertext pane: The Librarian does maintain Book information in the Book File Add Book, Update Book, and Remove Book information -, and Print Book Labels. When adding a book, the Librarian has to be aware of the Book’s Title and its Categories.

Step 5: Save the Use Case Select Save from the pop-up menu of the hypertext pane. Step 6: Create the Other Use Cases Repeat steps 1 through 5 to create all use cases listed in Table 3.

38

VisualAge UML Designer

Table 3. Use Cases

Use Case Name

Details

Maintain Books

The Librarian does maintain Book information in the Book File - Add Book, Update Book, and Remove Book information -, and print Book Labels. When adding a book, the Librarian has to be aware of the Book’s Title and Categorys.

Maintain Customers

The Librarian does maintain Customer information in the Customer File Add Customer, Update Customer, and Remove Customer information -, and print Library Membership Card.

Manage Book Loans

The Librarian does manage Book Loans through Check Out Books with a Customer individual maximum Number Of Items On Loan checked and a default Return Date, and through Return Books. This affects the Status of a Book in the Status File* according to Available, Borrowed, Overdue, Lost, or Reserved.

Search Books On Loan

The Librarian does search Books of a Title or a Customer has on loan, whereas the Customer does search Books of a Title or his or her Books on loan. - The Librarian optionally enters a Customer Identification whereas the Customer must enter his or her Identification, in order to start the search. - Search Customers and Search Titles are available.

Search Customers

The Librarian and Customer search Customers in Customer File, and can Look At Customer Details. A customer has restricted search only. - The Customer Search Criteria are: id Identification, firstname, middle initials, lastname, street, city, and Customer mandatory: ZIP, phone number, and SSN.

Search Titles

The Librarian and Customer search Titles in the Title Catalog. The Title Search Criteria are: words in the Title and Abstract, name of the Author, and by Categorys from the Category List*. - The Librarian and Customer enter the Title Search Criteria as Match Strings, start the search, get a list with Matching Titles presented, and can Look At Title Details.

Reserve Title

The Librarian and Customer create a Reservation of a Book Title in the (Reservation File)* in the event that all physical copies are on loan. - The Librarian and Customer enter the Customer and Title Identification. The Librarian can set the reservation Expiration Date, whereas the Customer has to use the default. - Search Customers and Search Titles are available.

Process End-Of-Day

The System Timer does start the Process End-Of-Day task of the Files: delete Expired Reservations Title/Book Reservations in the Title Catalog (Reservation File)* and update Expired Book Loans with Book Status changes Reserved/Available and Borrowed/Overdue in the Book File (Status File)*.

Note: Parts marked with an asterisk * are for later use.

Use Cases

39

Results The use cases are defined (Figure 21).

Figure 21. Relationship Browser: Use Cases

5.1.2 Link Use Cases to Requirements Use cases can be related to requirements. They elaborate what the requirements actually entail and in some cases help you discover additional requirements. Each use case satisfies one or more requirements. If a use case does not satisfy any requirement, either a new requirement should be added, or the use case is outside the scope of the system and should be dropped. Traceability In VisualAge UML Designer, you can create links between different model elements in order to show a "satisfies" relationship (as well as other relationships). Such links contribute to traceability: the ability to move between elements at different levels of abstraction, for example, between requirements and analysis. Now you can trace which use cases satisfy which requirement, or which requirements are satisfied by which use case. This traceability helps to clarify why the elements in the model are what they are, and how they became that way.

40

VisualAge UML Designer

Prerequisites: 1. You should have created use cases 2. You should have created requirements Step 1: Select the Relationship Select the Use Cases relationship in the relationship list of the Relationship Browser. Step 2: Select the Use Case Select the Maintain Books use case from the element list. Step 3: Select the Use Case to Requirement Relationship Select Link–>Satisfied Requirements... from the element pop-up menu for the selected use case. A window opens listing the available requirements (Figure 22).

Figure 22. Relationship Browser: New Satisfied Requirement Link

Use Cases

41

Step 4: Select the Satisfied Requirement(s) Select the Book Information Keeping requirement from the list.

Figure 23. Select the Requirement to link to for Satisfied Requirement

Step 5: Link the Satisfied Requirement(s) Click >> to add the selected requirement to the list of linked requirements. Step 6: Confirm the Link(s) Select OK. Step 7: Link the Other Use Cases to the Requirements Repeat steps 1 through 6 for the satisfying use cases and satisfied requirements in Table 4 to complete the use case satisfied requirements links. Note: This one-to-one mapping of satisfying use cases and satisfied requirements is atypical. Usually it takes several use cases to completely

42

VisualAge UML Designer

satisfy a requirement whereas a single use case satisfies several requirements partially. Table 4. Use Cases and Satisfied Requirements

Satisfying Use Case

Satisfied Requirement

Maintain Books

Book Information Keeping

Maintain Customers

Customer Information Keeping

Maintain Book Loans

Book Loan Information Keeping

Search Books On Loan

Books on Loan Searching

Search Customers

Customer Searching

Search Titles

Title Searching

Reserve Titles

Title Reservation

Process End-Of-Day

End-of-Day Processing

Results The use cases are trace linked to the requirements. To see this, double-click on the Maintain Books use case in the Relationship Browser. The Focus browser opens on the use case and has it selected (Figure 24). In the relationship list of the Focus browser select the Satisfied Requirements relationship. You should see the Book Information Keeping requirement in the element list. Select the requirement to view its text.

Figure 24. Focus Browser: Use Case Satisfied Requirements Links

Use Cases

43

5.2 Analyzing Use Cases Once you have a use case description, you can analyze the use case; that is, you identify, define, and describe the elements that play a part in the system or even "play" with the system. One way to start is to look for all of the nouns in the use case description to see which ones seem to refer to important elements of the system. Each time you find an important idea in the use case, you can classify it into one of the following categories of design artifacts: 1. 2. 3. 4.

Actors Things Concepts Use cases

A use case can use another use case, represented by a simple associated with relationship, and a use case can extend another use case, represented by an extends relationship. Note: In a small system with a slim analysis, you might use a very short description for an actor, thing, or concept—but not for the use cases—and argue: Read the hypertext linked passages in the use cases, which you can find in the Browse>Used By function. Now, let's take a look at the text of the Maintain Books use case to see to which design artifact it refers: Maintain Books:

The Librarian does maintain Book information in the Book File - Add Book, Update Book, and Remove Book information -, and print Book Labels. When adding a book, the Librarian has to be aware of the Book’s Title and Categories.

5.2.1 Identifying Actors The Maintain Books use case is initiated by a librarian, a human user. This person actually enters the information for maintaining books and initiates the add, modify, and delete operations. Because the librarian exists outside the system and provides the stimulus for setting the use case in motion, the librarian is an actor. Now create an actor element in the library model, to represent the librarian. Prerequisites 1. You should have defined the requirements. 2. You should have defined the use cases.

44

VisualAge UML Designer

Step 1: Create a New Actor Create the actor object for the Librarian in the same way you created use cases and requirements. See Appendix A.2, “Create a New Model Element” on page 206. In the hypertext pane you enter the general information (first part) about the librarian from Table 5 on page 48. Save the text. Step 2: Select the Use Case Select the Maintain Books use case in the Relationship Browser. Step 3: Insert a Hypertext Link Select Librarian - mark the word Librarian- in the hypertext pane and create a hypertext link to the Librarian actor, selecting Insert Link>Reference... in the hypertext pop-up menu (Figure 25).

Figure 25. Relationship Browser: Insert New Hypertext Link

Use Cases

45

Step 3: Select the Object to Link Because you already created an actor element to represent the librarian, you can now indicate the relationship between this actor and the use cases in which it participates. In the Select The Object To Link To dialog in Figure 26, select the element type in the left list and the element in the right list and click on OK. A double-click on the element does the select and OK in one step.

Figure 26. Select Object To Link To (Hypertext) Dialog

Note 1: If the object you want to link to does not show up in the list, you might remove or change the Match String. An asterisk (*) represents any character, whereas the number sign (#) represents exactly one character. Note 2: Create only one hypertext link from one model element to another, even though the text refers to the other one more than once. Note 3: Try to use the name of the referenced model element for the hypertext link label, even though it does not exactly match the original text. You might do some rewording of the surrounding text, for readability. Note 4: The Select The Object To Link To dialog in Figure 26 offers you the option of creating new model elements in flight. In other words, you can just start hypertext linking without creating the model elements you want to link to first, as you had to do in Step 1. See also “Creating While Linking” on page 50 and Appendix A.1, “Create a Hypertext Link” on page 205).

46

VisualAge UML Designer

The actor icon and the highlighted text mark the hypertext link in the text of the use case (see highlighted word Librarian in Figure 27). With a double-click on the icon or highlighted text, you navigate to the linked actor model element and open a browser on it.

Figure 27. Relationship Browser: Actor Hypertext Link and Index Hand Cursor

Step 5: Extend the Actor Description Extend the description of the Librarian actor with the information you find in the use case. Just double-click on the newly created Librarian hypertext link and append the new information in the opening browser. If you have not entered any description, do so now. Save the text. Step 6: Complete the Actor Description Go through the remaining use cases and complete the description of the Librarian with the information you find in the use cases, and insert the hypertext links. The use case descriptions in Table 11 on page 62 contain marks that indicate where to insert the hypertext links. Step 7: Create and Hypertext Link the Remaining Actors Go through all use cases and identify, define, and hypertext link the remaining actors. Table 5 lists the actors with their completed descriptions. Each description consists of three parts: the first part contains general information, the second contains the information gathered from the use cases in Table 3 on page 39, and the third contains the information gathered iterating over the extends and used use cases you will identify and define later on. The use case descriptions in Table 11 on page 62 contain marks that indicate where to insert the hypertext links.

Use Cases

47

Results The actors are defined and hypertext linked in the use cases. Table 5. Actors with General Information

Actor Name

Description

Librarian

Employee of a Book Library. Main user of the Book Loan System, having extended access to information and processes. Serving and helping the Library Customers in Book Loans and Returns, Title Searches and Reservations. Maintains Books - Add, Update, Remove -, sticks the printed Labels on the Book, is aware of the Book’s Title and the Title’s Categories. Maintains Customers - Add, Update, Remove -, hands out the printed Library Membership Card. Manages Book Loans - Check Out Books, Book Returns. Searches Books on Loan with Title or Customer information, Searches Customers and Searches Titles. Creates Reservation with Title and Customer information, can overwrite the Reservation Expiration Date. Enters and Looks at Book and Title Details. Enters and Looks at Customer Details. Maintains the Category List. Enters the condition of returned Books, if changed, and sets the Status of not returned Books to lost.

Customer

Customer borrowing Books from the Library. Casual user of the Library System, having restricted access to information and processes. Searches Books on Loan with his or her ID and Title information Searches Titles. Reserves Titles with his or her ID and Title information. -

System Timer

Device or Operator triggering predefined, scheduled tasks. Starts the daily Process End-Of-Day task. -

48

VisualAge UML Designer

5.2.2 Identifying Things The object model of an object-oriented system usually has a one-to-one correspondence with real-world entities: for each domain entity, there is generally one or more corresponding implementation objects. This natural model helps to make the system easier to understand, and it also means that the scope of changes to the problem domain map well to the scope of changes in the software. By real world we do not just mean tangible physical entities. We mean any element in the universe at hand that the model covers. This will often include intangible conceptual entities, such as a price or an insurance policy. To choose the correct objects for the system, you must identify the required behavior of the objects. With VisualAge UML Designer, you identify the required behavior by creating things (domain objects) and assigning responsibilities to them. Things are - only - candidate classes. At this point you are still at a conceptual level. If you are thinking of real classes already at this point, you get tempted to become prematurely physical, implementation language biased and - even worse - restricted. You may still decide later on that some of the things may not become real classes, though correctly identified. With concepts it is about the same: some may become real classes, and others may not (see 5.2.3, “Identifying Concepts” on page 54). About instance and class aspects of an object and a thing: VisualAge UML Designer transforms conceptual things with their responsibilities into protocols with messages, and later on transforms some of the protocols into class designs with the protocol’s messages as either instance or class messages, having other protocols as either instance or class message extensions. Hence the class kind of thing is a different thing from the instance kind of thing. If you identify different kinds of things concerning instance and class behavior of an object, define them as at least two different things. You can have more than one classlike thing with responsibilities for one kind of object. Hence you do not have to be stuck with one, and as well, you would rather name them differently than xyz class thing. A class is an abstract construct on a meta level, whereas in the real world you find a corresponding concrete thing for it, for example, for the car class you find the car factory or the conceptual thing like "the collection of all cars". While iterating through the steps of object-oriented analysis and design you have to be aware of the different levels of abstraction at which you are

Use Cases

49

looking at the problems. Therefore perfectly valid information available at one level of abstraction might not be that appropriate as it is on another level. In the Maintain Books use case, several terms refer to entities that exist within the system (unlike the librarian, who is outside the system). These terms typically are candidates to become classes in the implemented system. In the use case description you find the following things :

• Book • Book File Book File was intentionally chosen to avoid ambiguity between Book and Books. Book File represents the collection of books. The Book File thing is responsible for managing all list (collection) functions of books in the library system. The Book thing is responsible for maintaining book information.

Creating While Linking In 5.2.1, “Identifying Actors” on page 44 you created a new actor element for the Librarian, and after that you created a link to it. VisualAge UML Designer supports this in one step: Begin to create a hypertext link to a model element, you then will just create that model element in flight. See also Appendix A.1, “Create a Hypertext Link” on page 205. Prerequisites: 1. You should have created all of the use cases. Step 1: Set Up the Hypertext Link In the Maintain Books use case, select the word Book and use the Insert Link>Reference... in the pop-up menu (see Figure 25 on page 45) to open the Select Object To Link To dialog (see Figure 26 on page 46). Step 2: Specify the New Object to Link In the Specify New Item group box of the Select Object To Link To Dialog (see Figure 26 on page 46) select the relationship type the new model element will have to the model (Thing) and verify its name (Book). Step 3: Create and Link Click New. Step 4: Start to Describe the Thing Start the description of the Book actor with the information you find in the use case. Just double-click on the newly created Book hypertext link and append the new information in the opening browser. Save the text.

50

VisualAge UML Designer

Step 5: Complete the Thing Description Go through the remaining use cases and complete the description of the Book thing with the information you find in the use cases, and insert the hypertext links. Step 6: Create and Hypertext Link the Remaining Things Go through all use cases and identify, define, and hypertext link the remaining things. Table 6 lists the things with their completed descriptions. Each description consists of three parts: the first part contains the general information, the second contains the information gathered from the use cases in Table 3 on page 39, and the third contains the information gathered iterating over the extends and used use cases you will identify and define later on. The use case descriptions in Table 11 on page 62 contain marks, that indicate where to insert the hypertext links. Step 7: Create and Link the Other Things Repeat step 1 through 5 to link and hypertext link, create, and describe the things you find in Table 6, Table 7 on page 52, and Table 8 on page 53. Save the ones marked with two (**) asterisks for later on. The use case descriptions in Table 11 on page 62 contain marks that indicate where to insert the hypertext links. Table 6. Things 1

Thing Name

Details with Hypertext Links: (Thing), |Concept|, !Responsibility!

Book

Has state and behavior of a physical copy of a book. Knows !title! (Title), does !print Book Labels!*, knows !status! (Status), does !change Status! with requested discriminator string |Borrowed|, |Returned|, |Lost| Identifies by !id! |Identification|, keeps !entry Date!*, !condition!, returns !default Loan Period!* of the Title.

Book File

Maintains all books and supports access and search. Keeps !books! (Book) information, does !search Books!* and !search Books on Loan! with (Title) and (Customer)* information, !process End of Day!* and !change Expired Loans to Overdue!* with Date - later on done by the (Status File)* Does !assign Book ID!, !assign Entry Date!*

Note: * = hypertext links for later use in refinement and extension iterations

Use Cases

51

Table 7. Things 2

Thing Name

Details with Hypertext Links: (Thing), |Concept|, !Responsibility!

Customer

Has state and behavior of a customer. Does !print Library Membership Card!*, keeps !id! |Identification|, !firstname!, !middle Initial!*, !lastname!, !street!*, !city!*, !zip!* |ZIP|*, !phone Number!*, !ssn!*, |SSN|, !maximum Number of Items On Loan!* Keeps !state!* - books on regular loan, overdue and lost -, !member Since!* Date, returns !has To Print Library Membership Card!* - derived from changes, keeps !photo!*, returns !has Books On Loan!*

Customer File

Maintains all customers and supports access and search. Keeps !customers! (Customer) information, does !search Customers! with |Customer Search Criteria| Returns !default Maximum Number of Items On Loan!*, does !assign Customer ID!, !assign Member Since Date!*

Title

Has templatelike state and behavior for the books. Knows !books! (Book), keeps !title! |Title|, !abstract!* |Abstract|, !author! |Author|, !primary Category!, !secondary Categories!* |Category|, knows !reservations! (Reservation) Identifies by !id! |Identification|, keeps !publisher!*, !publication Date!*, !number of Pages!*, !isbn!* |ISBN|, !cover!*, !entry Date!*, derives from changes when the !books Have To Print Book Labels!*, does !books Print Book Labels!*, keeps optional !default Loan Period!* and !default Reservation Period!* in number of days - requirement from (Status) and (Reservation)

Title Catalog ****

Maintains all titles and supports access and search. Keeps !titles! (Title), does !search Titles! with |Title Search Criteria|, does !process End of Day!* and !remove Reservations!* with a Date Does !assign Title ID!, !assign Entry Date!*

Reservation

Reservation for the next available Book of a Title for a Customer. Knows !title!* (Title), !customer! (Customer), !status! (Status), keeps !expiration Date!*, derives !default Expiration Date!* from the current Date and the Title’s |Default Reservation Period| -

Note 1: * = hypertext links for later use in refinement and extension iterations Note 2: ****=see note below this table Note to Table 7: **** see “Step 5: Identify "Pattern" Things”

52

VisualAge UML Designer

Table 8. Things 3

Thing Name

Details with Hypertext Links: (Thing), |Concept|, !Responsibility!

Status

Is logically a part of the (Book). Complex state variable with behavior, managing loan state transitions - for example: discriminator |Borrowed| changes to |Reserved| when Book is |Returned| and (Title) (Reservation) is pending. Keeps !discriminator! |Available|, |Borrowed|, |Overdue|, |Lost|, !returnDate!, !numberOfLoans!, knows !book!* (Book), !customer!* (Customer), does !build Next Status! with a requested discriminator, !build Overdue Status!* with a Date, return !default Return Date!* from current Date and !default Loan Period!* of the Book Title -

Status File **

Maintains all Status and supports access and search. Keeps !stati! (Status), does !process End of Day! with Date, !change Borrowed to Overdue! with Date

Reservation File **

Maintains all Reservations and supports access and search. Keeps (Reservations), does !process End of Day! with Date, !remove Reservations! with Date.

Category ***

Information to categorize a (Title). Keeps !id! |Identification|, !keyword!, !text!

Category File ***

Keeps the (Cagegory List) with the |Category|s and supports access. Keeps the !category List! with the (Category)s and maintains them.

Category List ***

Maintains the categories while working with them and supports search. Keeps !categories! (Category) |Category|, does !search!

Notes: * = hypertext links for later use in refinement and extension iterations **= for later use in refinement iterations *** = for later use in extension interations

Use Cases

53

Step 5: Identify "Pattern" Things In the Search Titles use case you have identified a thing called Title . You will define a Title Catalog thing for titles, which will have the same responsibilities as the book file has with relation to books. In this specific use case, the term Titles or Title File does not appear. Therefore, we introduce a section we call Pattern Things, where we list a Title Catalog and make the hypertext link from there. Results The things are defined and hypertext linked in the use cases. A thing relationship icon and highlighted text mark the hypertext link (see highlighted Book and Book Files in Figure 28). A double-click on the icon or highlighted text navigates you to the linked thing model element and opens a browser on it.

Figure 28. Relationship Browser: Actor and Thing Hypertext Links

5.2.3 Identifying Concepts In addition to actors and things, there might be other important ideas in the use case that need to be documented. Going through the use case description, you can identify terms that need additional explanation. As you do this, you must use standard problem domain terminology, so that everyone understands the requirements in the same way. A careful definition of the terms in the textpane of the model element helps to overcome the imprecision and ambiguity inherent in natural language. As a general rule, each term should be used to refer to only one concept, and each concept should be described by only one term. In addition, any

54

VisualAge UML Designer

domain-specific terminology, or domain-specific usage of common terms, should be fully defined. In the Maintain Books use case, several phrases appear to be important concepts that should be documented. For example, Category is a domain-specific term that should be defined for the benefit of nonlibrarians. A definition will also help you to understand how you need to represent it in the system. Prerequisites: 1. You should have created all of the use cases. Step1: Create and Link the Concept Model Element Select the term Category in the Maintain Books use case and create a hypertext link. Create the hypertext link to the category with the relationship Concept. See Chapter A.1, “Create a Hypertext Link” on page 205. Step 2: Create and Link the Other Concepts Create and hypertext link the Concepts you find in the use cases with the hypertext link marks in Table 11 on page 62 (and things in Table 6 on page 51 through Table 8 on page 53). Table 9 and in Table 10 on page 56 list the concepts. Table 9. Concepts 1

Concept Name

Details (so far)

Available

A book available for any customer has the status available.

Borrowed

A book on loan - but not overdue - is in the status borrowed.

Overdue

A book longer on loan than agreed is in the status overdue.

Lost

A book on loan that the customer is unable to find and return.

Reserved

A book available for only that customer for whom the reservation was made.

Returned

A book just returned by a customer - becomes either available or reserved.

Book Loan

... the current and legal user (reader) is not the legal owner... Book borrowed from the Library for temporary use - up to the agreed return date.

Identification

Unique information to uniquely identify something. For example: Social Security Number (SNN), employee number or any serial number. Abbreviations used: ID or id.

Category

Contents qualification. For example: Science Fiction.

Use Cases

55

Table 10. Concepts 2

Concept Name

Details (so far)

Abstract

Short text about the book’s contents.

Author

Name of the person(s) who wrote the book.

Bar Code

Sequence of bars coding a number. Easy, fast, and reliable for machines to read.

Book Label

A label with the book’s identification in standard type face and as barcode, primary category (of the title), author, and some other pertinent information to stick on the book spine and on its first page.

Customer Search Criteria

A set of selection values used to search a specific customer in the customer file. It is obvious, that latest at implementation time it looks like an object.

Default Reservation Period

Number of days a Title can be reserved. Every Title can have its own default. If not set, the systemwide default is taken.

Expiration Date

of a Reservation: the date up to which a title reservation is kept.

Expired Book Loan

Book not returned before or at the agreed return date. An expired loan is overdue.

Expired Reservation

Reserved Book of a Title not picked up before or at the reservation expiration date. The reservation is removed.

ISBN

International Standardized Book Number, identification defined by the publishers

Library Membership

The state of being a member of the Library organization - the borrowing part.

Library Membership Card

A card in credit card size identifying a person or customer of the Library Membership. The customer id, firstname, middle initial, lastname, member Since date, and photo are printed on it. Id and member Since date are also printed as bar code.

Match String

A search criteria item that can have wildcards for fuzzy search. The number sign (#) represents any single character, whereas an asterisk (*) represents any character string.

Matching Title

A title which matches the match strings of the title search criteria.

Publisher

Name of person(s) or organization(s) publishing the book.

System

The group of the acting objects building a reasonable, complete unit. If a system is called doing this or that, in fact one of its objects is doing this or that.

Title Search Criteria

A set of selection values used to search a specific title in the title catalog. It is obvious, that latest at implementation time it looks like an object.

ZIP

5-digit postal delivery area. - ZIP Code - A trademark for a system to expedite the delivery of mail by assigning a 5-digit number to each postal delivery area in the U.S.

56

VisualAge UML Designer

Results The concepts are defined and hypertext linked in the use cases. A concept relationship icon and highlighted text mark the hypertext link (see highlighted Categorys in Figure 29). A double-click on the icon or highlighted text navigates you to the linked concept model element and opens a browser on it.

Figure 29. Relationship Browser: Actor, Thing, and Concept Hypertext Links

5.2.4 Identifying Used and Extends Use Cases Depending on the style, level of abstraction, and complexity of the use cases it may be necessary to break them down into smaller pieces: Extends Use Case An extends use case has an extends relationship to the use case it contributes to with alternate flow, with catching of exceptions, and with handling special situations (...an if then else like construct: When...). Used Use Case

A used use case has a used by relationship to the use cases it unconditionally contributes to (...an unconditional call subroutine like construct).

Note: One and the same use case can be a stand-alone use case, a used use case, and an extends use case. In Maintain Books you find the following extends use cases:

• Add Book • Update Book • Remove Book

Use Cases

57

And while wording the first one (together with your domain expert):

Add Book When the Library gets new books delivered, the Librarian does enter Book Details, add Book to the Book File, and print Book Labels to stick on the spine and first page of the Book. It might be that the Librarian must Maintain Categories first. you might identify candidate used use cases: • Enter Book Details • Print Book Labels After wording the Update Book extends use case, you know that they are use cases: • Enter Book Details is used by • Add Book • Update Book and • Print Book Labels • is used by Add Book • extends Update Book Table 12 on page 63 and Table 13 on page 64 list all used and extends use cases with hypertext link marks. From the hypertext link marks in Table 11 on page 62, you can see which use cases use or extend other use cases. For a project as small as this, you might be wondering why you have to define a use case like Maintain Books instead of simply writing separate use cases for add a book, delete a book, and modify book information. We ask you to write separate use cases because we want to show how to identify and create used and extending use cases. You might also be wondering why, if you have one use case that you can use, you also have to create a Maintain Customers use case. The answer is that as a rule you should attempt to keep each use case specified at the same level of abstraction. We selected a relatively high level of abstraction to provide a suitable example for VisualAge UML Designer. Creating Use Cases and Linking Them As Extends or As Used Create and link are two tasks: 1. You create a use case (for example, through hypertext linking).

58

VisualAge UML Designer

2. You link an extends use case from itself to the extended use case, whereas you link a used use case from the using use case to itself. Steps 1 and 6 in the following sequence cover task 1, whereas Steps 2 through 5 and Steps 7 through 10 cover task 2. Prerequisites: 1. You should have created the main use cases listed in Table 11 on page 62. Step 1: Create a New Use Cases through Hypertext Linking Select the phrase add Book in the hypertext pane of the Maintain Books use case to create a hypertext link to the corresponding extends use case. See Appendix A.1, “Create a Hypertext Link” on page 205. Step 2: Select the Use Case for an Extends Link For an extends link select the newly created Add Book extends use case in the element list of the Relationship Browser. Step 3: Create the Extends Link Select Link>Extends... from the element list pop-up menu. Step 4: Capture Link Details Move the Maintain Books use case to the Linked List and select OK. Step 5: Capture Use Case Information Select the newly created and extends-linked Add Book use case and type its definition into the hypertext pane. Choose Save from the pop-up menu in the hypertext pane. Step 6: Create New Use Cases through a Hypertext Linking Select the phrase enter Book Details in the hypertext pane of the Add Book use case to create a hypertext link to the corresponding used use cases. See A.1, “Create a Hypertext Link” on page 205. Step 7: Select the Use Case for a Used Link For a used link select the Add Book using use case in the element list of the Relationship Browser. Step 8: Create the Used Link Select Link>Associated With... from the element list pop-up menu.

Use Cases

59

Step 9: Capture Link Details Move the newly created Enter Book Details use case to the Linked List and select OK. Step 10: Capture Use Case Information Select the newly created and used-linked Enter Book Details use case and type its definition into the hypertext pane. Choose Save from the pop-up menu in the hypertext pane. Step 11: Create and Link the Other Extends and Used Use Cases Use the use cases in Table 11 on page 62 to: 1. Create the used and extends use cases while hypertext linking them 2. Link them as extends or as used and use the use cases in Table 12 on page 63 and Table 13 on page 64 to: 3. Type in the definition by repeating Steps 1 trough 5, and Steps 6 trough 10, respectively. Step 12: Analyze the Newly Created Use Cases Analyze the newly create use cases for: 1. 2. 3. 4.

Actors Things Concepts Use cases.

This is just restarting the work you are already doing and which is described in 5.2, “Analyzing Use Cases” on page 44 that you are reading now. Matter of fact, this is the matter of object-oriented, iterative life... Use Table 12 on page 63 and Table 13 on page 64 with all use cases to look for all hypertext linked Actors, Things, Concepts, and Use Cases. After this second lap you are done! Results The use cases are defined with a decent granularity and linked with extends, used, and hypertext links - see Figure 30 and following tables (with use case descriptions and hypertext link marks): • Table 11 on page 62 (Main use cases) • Table 12 on page 63 (Book and Title related extending/used use cases) • Table 13 on page 64 (Customer and Loan related extending/used use cases)

60

VisualAge UML Designer

Figure 30. Relationship Browser: All Use Cases

Use Cases

61

Table 11. Use Cases with Hyperlink Marks

Name

Details with Hypertext Links: (Thing) |Concept| {extends} [used]

Maintain Books

The does maintain (Book) information in the (Book File) - {Add Book}, {Update Book}, and {Remove Book} information -, and print |Book Label|s. When adding a book, the Librarian has to be aware of the Book’s (Title) and |Category|s.

Maintain Customers

The does maintain (Customer) information in the (Customer File) {Add Customer}, {Update Customer}, and {Remove Customer} information -, and print |Library Membership Card|.

Manage Book Loans

The does manage |Book Loan|s through {Check Out Books} with a default Return Date and a (Customer) individual maximum Number Of Items On Loan check, and through {Return Books} - affecting (Book) (Status) in the (Status File)* according to |Available|, |Borrowed|, |Overdue|, |Lost|, or |Reserved|.

Search Books On Loan

The does search (Books) of a (Title) or a (Customer) has on loan, whereas the does search Books of a Title or his or her Books on loan. - The Librarian optionally enters a Customer |Identification| whereas the Customer must enter his or her Identification, in order to start the search. - {Search Customers} and {Search Titles} are available.

Search Customers

The and search (Customer)s in (Customer File) and can {Look At Customer Details}. A customer has restricted search only. - The |Customer Search Criteria| are: id |Identification|, firstname, middle initials, lastname, street, city, and Customer mandatory: |ZIP|, phone number, and |SSN|.

Search Titles

The and search (Title)s in the (Title Catalog). The |Title Search Criteria| are: words in the |Title| and |Abstract|, name of the |Author|, and by |Category|s from the (Category List)*. - The Librarian and Customer enter the Title Search Criteria as |Match String|s, start the search, get a list with |Matching Title|s presented, and can {Look At Title Details}.

Reserve Title

The and create a (Reservation) of a (Book) (Title) for a (Customer) in the (Reservation File)* in the event that all physical copies are on loan. - The Librarian and Customer enter the Customer and Title |Identification|. The Librarian can set the reservation |Expiration Date|, where as the Customer has to use the default. - (Search Customers) and (Search Titles) are available.

Process End-Of-Day

The does start the Process End-Of-Day task of the Files: delete |Expired Reservation|s (Title)/(Book) (Reservation)s in the (Title Catalog) (Reservation File)* and update |Expired Book Loan|s with (Book) (Status) changes |Reserved|/|Available| and |Borrowed|/|Overdue| in the (Book File) (Status File)*.

Note: The hypertext links marked with an asterisk * are for later use.

62

VisualAge UML Designer

Table 12. Extending and Used Use Cases 1 with Hypertext Link Marks

Name

Details with Hypertext Links: (Thing) |Concept| {extends} [used]

Add Book

When the Library gets new books delivered, the does {Enter Book Details} and add (Book) to the (Book File), and [Print Book Labels]. The System - Book File - does assign Book ID |Identification| and entry Date.

Update Book

When a Book information needs corrections, the does enter the Book ID |Identification| directly or via {Search Books}, [Enter Book Details], and update the (Book) in the (Book File), and when necessary, re{Print Book Labels}.

Remove Book

When a Book is no longer up to date or is damaged, the does enter the Book ID |Identification| directly or via {Search Books}, [Look At Book Details], and remove the (Book) from the (Book File).

Search Books

The enters the (Title) |Identification| directly or via {Search Titles} to search (Book)s in the (Book File).

Enter Book Details

The assigns the (Title) directly or via {Search Titles} to the (Book), then enters its (Status), and condition. The Librarian might {Maintain Titles} first.

Look at Book Details

The and look at the Book Information: (Title), (Status) with (Customer) reference, if any and Librarian only, condition, and entry Date.

Print Book Labels

The prints the |Book Label|s to stick on the spine and the first page: (Book) ID, (Title) ID, title, |Author|, and primary |Category| - IDs also as |Bar Code|.

Maintain Titles

The does maintain (Title) information in the (Title File) - {Add Title}, {Update Title}, and {Remove Title} information. When adding a Title, the Librarian has to be aware of its primary and secondary |Category|s.

Add Title

If the Title of a new delivered book is not yet in the system, the does {Enter Title Details} and add the (Title) to the Title File, called (Title Catalog). The System - Title Catalog - does assign Title ID - |Identification| - and entry Date.

Update Title

When a Title information needs corrections, the does enter the Title ID |Identification| directly or via {Search Titles}, [Enter Title Details], and update the (Title) in the Title File, called (Title Catalog). The (Book) labels might be reprinted.

Remove Title

If there are no Books of that Title in the Library anymore, the title might be removed: the does enter the Title ID |Identification| directly or via {Search Titles}, [Look At Title Details] and remove the (Title) from the Title File, called (Title Catalog).

Enter Title Details

The enters the |Title| details - title, |Author|, |ISBN|, |Abstract|, number Of Pages, |Publisher|, publication Date - Table 6 , assigns one primary and none to many secondary |Category|s from the (Category List)*, and scans or shoots an image of the cover. The Librarian might {Maintain Category List} first.

Look at Title Details

The or look at the (Title) details, on request including cover image, and number of (Book)s |Available|, |Reserved| and total in Library.

Note: The hypertext links marked with an asterisk * are for later use.

Use Cases

63

Table 13. Extending and Used Use Cases 2 with Hypertext Link Marks

Name

Details with Hypertext Links: (Thing) |Concept| {extends} [used]

Add Customer

When a person becomes a Customer of the Library, the does [Enter Customer Details], add the (Customer) to the (Customer File), and [Print Library Membership Card]. The System - Customer File - does assign Customer ID - |Identification| - and the member Since date.

Update Customer

When a Customer information needs corrections, the does enter the Customer ID |Identification| directly - from the |Library Membership Card| - or via {Search Customer}, [Enter Customer Details], update the (Customer) in the (Customer File), and when necessary, re{Print Library Membership Card}.

Remove Customer

When a Customer cancels his or her |Library Membership|, the does enter the Customer ID |Identification| directly - from the |Library Membership Card| or via {Search Customers}, [Look At Customer Details], and - when no |Books| on loan - remove the (Customer) from the (Customer File).

Enter Customer Details

The enters the (Customer) details - firstname, middle initial, lastname, street, city, state, |ZIP|, phone Number, |SSN| -, optionally changes the system defaulted maximum Number Of Items On Loan, and shoots a photo. ID |Identification| and member Since date are set by the system at add time.

Look at Customer Details

The and look at the (Customer) details: id for |Identification|, firstname, middle initial, lastname, street, city, state, |ZIP|, phone Number, member Since date, maximum Number Of Items On Loan, |SSN|, and photo. A customer can only see own details.

Print Library Membership Card

The prints the |Library Membership Card| for the (Customer) with: id for |Identification|, firstname, middle initial, lastname, memberSince date, and photo. ID and memberSince date are printed also as |Bar Code|.

Maintain Category List

The maintains |Category|s (Category)*s - with ID |Identification|, word or phrase, and short text - in the (Category List)* stored in the (Category File)*.

Return Books

The Customer returns Books on loan at the Loan Returns window to the Librarian. The enters each (Book) ID |Identification| and condition - if condition changed. A return affects the Book (Status) accordingly... sometimes to |Lost| - {Search Books}, {Search Books On Loan}, and {Search Customers} are available. The system displays Customer details, books on loan with return Dates, and Books lost, as soon as it knows the |Customer| ID - by entry or via Books in return.

Check Out Books

The Customer checks out Books at the New Loans window with the Library Membership Card. The identifies the (Customer) by the |Library Membership Card| or {Search Customers} and {Look At Customer Details}, enters the Customer ID |Identification| - from the Library Membership Card -, and each (Book) ID - from the Label. A loan affects the Book (Status) accordingly. The system displays customer details, books on loan with returnDate, and lost books, and restricts the loan to the maximum Number Of Items On Loan.

Note: The hypertext links marked with an asterisk * are for later use.

64

VisualAge UML Designer

Summary of Ways to Create and Link New Use Cases Now you know two ways to create new use case model elements: 1. In the Relationship Browser through a new Use Case relationship 2. In the Hypertext of a Browser through a new Hypertext Link A third, very convenient and visual way is: 3. In the Use Case Diagramer by attaching a just in flight created use case model element to a use case figure. The used and extends relationships also can be created in the Use Case Diagramer. Use case diagrams are covered in Chapter 6., “Use Case Diagrams” on page 67. Creating a new model element through attachment is covered in 6.2, “Adding a Group Figure” on page 68.

5.3 Two Complementary Approaches to Analyze Use Cases Going through all use cases with one actor, thing, and concept element at a time and looking for information about that element is one approach defining the element. Another approach is to look for any kind of state and behavior information of any actor, thing, and concept element at the same time in one use case after the other and append the information to the appropriate element. After checking the use case for possible actors or things - Who else "took" the state or behavior information? - everything else in the use case must be a concept. The first approach—For every thing you run through all use cases—is more object-oriented and delivers more consistent actors, things, and concepts but does not ensure, that everything in a use case becomes part of an actor, thing, or concept definition. The second approach—For every use case you run through all things—is more function and analysis process oriented and ensures, that everything in a use case becomes part of a definition. A balanced approach would be this: For the initial result, do the first iteration with the first approach. Iterate over actor, thing, and concept, and over the use cases. For the review of the initial result, use the second approach. Iterate over the use cases once and check that everything is defined either in or as an actor, thing, or concept. This balanced approach delivers consistency and completeness of the defined elements—the required base

Use Cases

65

for taking the next and last major step in the analysis phase: identify, define, and assign the responsibilities to things and actors.

66

VisualAge UML Designer

Chapter 6. Use Case Diagrams Once you have identified the actors and created the use cases, you can use the VisualAge UML Designer Use Case Diagrammer to create use case diagrams that depict actors, use cases, and the relationships among them. Note that you have to create the diagrams; the tool does not generate them. The figures on the UML-compliant use case diagrams you create are based on the underlying model elements. Diagrams are graphical views of the model. They show selected model elements as pictorial elements arranged spatially. Diagrams are made up of node figures and connector figures. Node figures are shown as boxlike shapes, and connector figures are shown as lines between two or more node figures. Every figure has a model element associated with it. For node figures the model association is usually a structural element such as a use case or a class design; for connector figures the model association is a link between the corresponding node figure’s models. Figures can have adornments, that is, labels and other decorations that pictorially convey a semantic meaning. You can use the use case diagrammer to: • Add node figures for existing model elements • Show and hide link figures for existing model elements (links) • Add node and link figures and at the same time create new model elements for them Table 14 on page 69 lists the figures and the creation tools available in the use case diagrammer of VisualAge UML Designer.

6.1 Creating a Use Case Diagram To create a new use case diagram for the library management system, follow these steps: Prerequisites 1. You should have defined the requirements. 2. You may also have defined the (basic) use cases. Step 1: Select the Relationship Select the Use Case Diagrams relationship in the relationship list of the Relationship Browser.

© Copyright IBM Corp. 1998

67

Step 2: Create New Diagram Select New... from the pop-up menu of the relationship list. Step 3: Capture Details When prompted for the name of the diagram, type Book Management

and click OK. Results The new diagram appears in the element list. You can double-click on Book Management to open the use case diagrammer.

6.2 Adding a Group Figure Each model element is represented in a diagram by a figure, a graphical representation based on the UML notation. A figure is attached to an underlying model element, from which it takes most of its properties. A figure also has additional characteristics of its own. These characteristics control the figure’s visual appearance. For example, the aspects of the underlying model element appear on the diagram, as well as purely visual attributes such as color. There are several ways of adding a group figure - or any figure - to a diagram (including, for example, by pasting from other browsers or diagrams). To explicitly add a figure: 1. Place a new unattached figure of the desired type on the drawing area 1. Attach the figure to a model element To create and place a new figure, select the appropriate creation tool from the tool bar along the left edge of the window (Figure 31 on page 70). Table 14 lists and explains the figure creation tools. At this stage in the development process, you might have only a rough idea of how big the system is and how it will have to be divided into subsystems. Systems (which correspond to Group elements in the model and are described below in “Step 3: Attach Figure to Model Element”) provide a lightweight means of tentatively assigning elements to subsystems.

68

VisualAge UML Designer

Table 14. Use Case Diagrammer: Figures and Creation Tools

Tool

Figure

Description

System

Creates new a figure representing a grouping of elements as a system

Use case

Creates a new figure representing a use case

Actor

Creates a new figure representing an actor

Annotation

Creates a new figure representing a note, comment, or constraint

Association

Creates a new figure representing a "used" link between two use cases. The using use case is the origin.(*)

Extension

Creates a new figure representing an "extends" link between two use cases. The extends use case is the origin.

Constraint

Creates a new figure representing an association link between a constraint annotation and a model element

Note: (*) The association link is used to link a use case to a used use case as well as an actor to a use case.

Prerequisites: 1. You must open a use case diagram. Step 1: Select a Figure Select the system tool from the tool bar. The first step is to add a figure representing the boundaries of the library management system. This boundary separates the use cases (which are essentially part of the system) from the actors (which are outside the system). Step 2: Add Book Management System Group Use the left mouse button to drop the icon in an empty area of the drawing surface. Note: When first added to the drawing surface, the figure is labeled with a question mark, indicating that it is not yet associated with an underlying model element. All elements in VisualAge UML Designer diagrams must be associated with underlying models.

Use Case Diagrams

69

Step 3: Attach Figure to Model Element Click the right mouse button on the icon to display its pop-up menu and select Attach from the pop-up menu. A window appears showing the available groups to attach to the System figure. NOTE: A group is an organizational element used to collect related model elements. In a use case diagram, a group is the underlying model element for the System figure, which is essentially a grouping of related use cases. Step 4: Capture Details Because no groups yet exist in the library management system, type: Book Management

in the name field of the Specify New Item group box and then click New. Results The System figure is now attached to the new group, and the Book Management label appears in the diagram. Thus you have added a node figure and created a new model element for the node figure at the same time. Figure 31 on page 70 shows the group figure representing the book management system.

Figure 31. Use Case Diagrammer [Book Management]: Group/System Figure

6.3 Adding a Use Case Figure Follow these steps to add a use case figure to the diagram:

70

VisualAge UML Designer

Prerequisites: 1. You must be in the use case diagrammer. 2. You should have created a system figure and have it attached to the underlying model element. Step 1: Select Figure Icon Select the use case tool from the tool bar. Step 2: Add Use Case Figure Click the left mouse button to place the figure within the Book Management system box. Because it is not yet associated with an actual use case, the use case figure is labeled with a question mark. Step 3: Attach Figure Select Attach from the pop-up menu of the use case figure. A window appears listing the available use cases in the model. Select Maintain Books from the list. Results The use case figure is now attached to the underlying use case and is labeled appropriately. Thus you have added a node figure and connected it to an existing model.

6.4 Adding a Dependent Relationship To show the link between a use case and an actor, you can manually add an actor figure from the tool bar and then connect it to an actor model (just as you did for the use case), but in this case, VisualAge UML Designer can do some of the work for you. Prerequisites: 1. You must open a use case diagram. 2. The diagram must have node figures attached to underlying model elements. 3. The attached model elements must have links. Step 1: Select Hidden Relationship Select Hide/Show Relationships from the pop-up menu of the Maintains Books use case figure. A window opens showing the links for any

Use Case Diagrams

71

existing relationships involving the use case, as well as any identified candidate relationship links. (Candidate links are indicated by a preceding + and appear after the existing relationship link.) In this case, VisualAge UML Designer has identified a candidate link between the Maintains Books use case and the Librarian actor. This link is suggested because of the reference to Librarian (and the accompanying hypertext link) in the description of the use case. Step 2: Capture Details Select +(self >- (Associated With) -> Librarian ) from the Hidden Relationships list and select >> to add the link to the Shown Relationships list. These actions create an explicit "associated with" relationship link and indicate that you want the relationship to be represented in the diagram. Select OK. Step 3: Define Direction Select Yes when asked if the direction of the new link is from the actor to the use case. Step 4: Show the Other Relationships Select Maintains Books and add the following relationships from the Hide/Show Relationships option of the pop-up menu to your diagram: • Add Book >– (Extends –>self • Remove Book >– (Extends –>self • Update Book >– (Extends) –>self Step 5: Complete This and the Other Use Case Diagrams Create and complete the use case diagrams: • Book Management, Figure 33 on page 74 (only to complete) • Customer Management , Figure 34 on page 74 • Loan Management in Figure 35 on page 75 Step 6: Create the Library System Overview (Use Case) Diagrams Create the (use case) diagram: • Library System, Figure 32

72

VisualAge UML Designer

Results A complete set of use case diagrams (see Figure 36 on page 75) with an overview diagram: • Library System overview in Figure 32 with: • Book Management in Figure 33 on page 74 • Customer Management in Figure 34 on page 74 • Loan Management in Figure 35 on page 75 Note: Readability can be improved with fonts, styles, and logical arrangement of the figures: Compare the Customer Management use case diagram in Figure 34 on page 74 with the Customer Management use case diagram in Figure 6 on page 9. Note that links are also figures.

Figure 32. Library System Overview Diagram

Use Case Diagrams

73

Figure 33. Use Case Diagram: Book Management

Figure 34. Use Case Diagram: Customer Management

74

VisualAge UML Designer

Figure 35. Use Case Diagrammer: Book Loan Management

Figure 36. Relationship Browser: All Use Case Diagrams

Use Case Diagrams

75

76

VisualAge UML Designer

Chapter 7. Responsibilities and Participants (Collaborators) A responsibility is a duty of a thing or actor, something it must do in order for a use case to complete successfully. Each thing or actor can have many responsibilities, and each can collaborate with other things or actors in their responsibilities. The responsibility of a thing is a candidate ultimately to become one or more methods of an implementation object or a relationship between objects. Note: At this stage, you could use "computer-free" techniques such as CRC cards to identify responsibilities, entering the results as new responsibility elements. Collaborators are other things or actors that participate in a specific responsibility. VisualAge UML Designer implements collaborators as participants in responsibilities of things.

7.1 Identifying and Assigning Responsibilities and Participants To identify responsibilities and collaborating participants, go through the text of your things and actors and all the use cases (as a backup) and determine first what the things and actors must do, and second, which other thing or actor is a collaborating participant. Thanks to your hypertext links to the model elements in your use cases, you get great support from VisualAge UML Designer to identify responsibilities and participants: The actor or thing Browse>Used by function delivers you a list with all elements, where you find the responsibilities to assign with the collaborating participant. The name of each responsibility must be unique within the scope of a single actor or thing. VisualAge UML Designer defines four types of responsibilities (Table 15). Table 15. Responsibilities Defined by VisualAge UML Designer

Responsibility Type

Description

Action

An ability the thing should be able to do

Identifier

An object that identifies the thing

Reference

An object that the thing knows

Value

An object that the thing keeps information about

© Copyright IBM Corp. 1998

77

Accordingly, you define whether the responsibility must address one or more than one element, for example, keep information about a single value or about a collection of values. In fact, the identifier, reference, and value responsibilities result in the same code stubs when generating code, but they still serve as meta information for your model. For example, VisualAge UML Designer does not allow an array of identifiers to be defined as a responsibility, which makes sense, because an identifier should be unique for an object. However, defining a reference requires a participant, whereas defining a value does not - a value requires defining the type. VisualAge UML Designer generates an association link to the participant for the thing for which you create a reference responsibility and takes the participant in a value responsibility as the type of the value in the getter and setter code stubs.

7.2 Identifying Responsibilities and Doing Hypertext Links In our model we identify Book File as a thing; Book File appears in the following use cases:

• Add Book • Update Book • Remove Book Based on the cases, Book File might have the following responsibilities: • Add the book (in Add Book ) • Assign book identification (in Add Book: The System assigns...) • Update book (in Update Book) • Remove the book (in Remove Book ) Because the Book File has the responsibility to add and remove a book, we can assume that it should "keep" information about a list of books. This implies a one-to-many relationship to book. In VisualAge UML Designer the value-relationship implies an aggregation; therefore, the tool generates "add," "remove," and "getCollection" methods in response to the defined responsibilities with a cardinality of many. As a result, only two responsibilities need to be defined for Book File: • A value responsibility for Books • An action responsibility for assign book ID to

78

VisualAge UML Designer

You will ask: What about Update Book? The answer is: It depends... It depends on how you look at the Book File: • If you look at the Book File as just a Smalltalk object, keeping a collection value referencing all Books, you expect that updates to a Book, for example to its condition, do not affect the collection or its keeping Book File. • If you look at the Book File (more) literally as persistent storage or a proxy of it, you expect correctly that updates to a Book affect the Book File for sure: the Book File has to talk to and update the persistent storage with the Book’s updated information, just as it does in the Add Book and Remove Book use case. We suggest that you look at the Book File as a proxy of the persistent storage. With an empty update responsibility (NOP - no operation - method), the "just Smalltalk" requirement is satisfied too. For this sample, we chose "just Smalltalk". Two comments have to be made at this stage: Comment 1 The easily - and fuzzily - used term system is not (yet) identified and defined as a thing or actor model element, and even worse, not hypertext linked. Everybody understands the system as the set of the participating things and actors and looks at it as a concept, but nobody knows exactly where to locate each responsibility. Therefore some concrete things and actors have to get the so-called system responsibilities assigned. For the timely and periodic responsibility, start the Process End-Of-Day task, the System Timer actor was identified and defined, but the task itself has still to be assigned as a responsibility. To complete the analysis work concerning, for example, the term system, you have three options: 1. Identify and define the system as a concept or thing and hypertext link it in the use case. Describe and delegate the responsibilities in the System with hypertext links. The definition with text reads then:

System • Does assign ID To a Book is done by the Book File. • Does display Xxx and Yyy is done by the Zzz view, and Xxx is of or from Aaa and Yyy is of or from Bbb. In the identifying process, going through the use cases, include the System thing or concept too.

Responsibilities and Participants (Collaborators)

79

2. Replace each term system with an existing or new thing or actors you identify for the responsibility and hypertext link it. 3. Just insert after each term system a new or existing thing or actor you identify for the responsibility and hypertext link it (see hypertext of use case in Figure 37 on page 82, on the right). Option 1 adds complexity. Option two is straight forward, where as option three is a good combination of 1 and 2: In the identifying process the responsible thing or actor gets caught and so the responsibility too, and still, the original fuzziness is visible. When it is easy to find a thing or actor for the system responsibility, we suggest to use option 2, otherwise and when we want to keep the replacement visible we suggest to use option 3. By the way, the technique used in option 1 can be very helpful for breaking down big things with course grain responsibilities into smaller things with crisper responsibilities. It is the same pattern you followed, when you identified extending and used use cases. Comment 2 There are many roads to Rome: some are more efficient, some are more thorough. (You did not expect this interpretation, did you?) An efficient approach based on thorough actor and thing descriptions is: 1. Take the list of things. 2. Iterate over this list of things: 1. Analyze the thing, using its description 2. Identify, define, and describe the responsibilities 3. Hypertext link the responsibilities If you did a thorough job when identifying, defining, and describing the things, then analyzing the thing using its description might be sufficient because you captured everything about the thing in the use cases. But to be sure to get it right - correct and complete and within the context, or if you were not very verbose in the thing description, use the following to review or do your work: 4. Build the list of use cases using the current thing with Browse>Used By. 5. Iterate over this list of use cases: 1. Analyze the current use case for responsibilities of the current thing

80

VisualAge UML Designer

2. Verify or assign the responsibilities to the current thing 3. Hypertext link the text passage in the use case to the responsibility The approach is efficient because you use capabilities of VisualAge UML Designer and the hypertext links you built in previous steps. But there is no guarantee that you will find all responsibilities of the selected thing. For example, search Books On Loan - obviously an action responsibility of the Book File - will not by found when looking at use cases using the Book File thing. Question: Why? Answer: The Search Books On Loan use case where the responsibility occurs does not show up in the list of use cases using the Book File thing. Why? Because the thing does not show up in the use case, it is not hypertext linked, and therefore it is not in the list (Figure 37, on the right). Conclusion: efficiency is not everything. The thoroughness depends on the completeness of each use case concerning the things and their hypertext links. But what if the thing involved in the use case is not obvious, or it is even unknown, and therefore not mentioned? Fortunately, when looking at the use cases that use the Book thing, you will fall over a lot of responsibilities related to books but addressing the collection of all books: the Book File. Day saved! An almost watertight approach is to: 1. Build or take the list of uses cases 2. Iterate over this list of use cases • Analyze the current use case thoroughly and completely for any kind of activity, reference, value, or id phrase • Assign each phrase as a responsibility to an existing or new thing • Hypertext link the phrase to the responsibility. Hypertext linking the phrases to the responsibilities is not necessarily required but results in terrific support for the review of the current analysis stage: browse through the use cases, and if you find any kind of activity, reference, value, or id phrase, that is not marked with a responsibility hypertext link, then you know: the phrase is either not relevant and can be removed from the use case, or it must identify a not yet assigned (or hypertext linked) responsibility. Conclusion: Use the second approach for the review. It seems to be a lot of work. Indeed, it is. But the everlasting truth reads: The better the analysis, the better the design. The better the design, the earlier a user satisfying implementation.

Responsibilities and Participants (Collaborators)

81

7.3 Setting Up an Efficient Identification and Assignment Process If you want to go efficiently through the use cases thing by thing and find the responsibilities, follow these steps: Prerequisites 1. Use cases seriously analyzed concerning things, actors, and concepts and thoroughly context linked. Step 1: Get the Candidate Responsibles (Things) in a Source List Double-click on the relationship of the model elements you want to work on (Thing) in the relationship list of the Relationship Browser. A new Relationship Browser opens with all model elements of the requested relationship (Things) in the source list (Figure 37, on the left). Over this list you will iterate with the next steps.

Figure 37. Responsibles with Responsibilities and Use Cases

82

VisualAge UML Designer

Step 2: Select the Responsible You Want to Work On Select a source item (responsible Book File) in the source list. Step 3: Setup the Progress Monitor Select the Responsibility relationship in the relationship list to monitor the list of defined responsibilities in the element list. Step 4: Get the Relevant Use Cases in a Source List Select Browse>Used By from the pop-up menu of the source list. Another Relationship Browser opens with the use cases (and a few other model elements) in the source list (Figure 37, on the right). Over this source list you will iterate with the next steps. Arrange the two Relationship Browsers as shown in (Figure 37). Step 5: Select the Use Case in the Source Select the use case in the source list (Figure 37, on the right). The use case text shows up. Step 5: Identify Responsibility Read the use case text and identify the responsibility ( add) with (Book) participant for the selected responsible ( Book File ). Step 6: Create New Responsibility Select New... in the pop-up menu of the relationship list with the selected Responsibility relation selected (Figure 37 on page 82, on the left). Note: Step 6 is the bridge to 7.4, “Assigning Action, Identifier, and Value Responsibilities to Things” on page 83, and it is similar to Step 3 there. Continue with Step 4 in 7.4, “Assigning Action, Identifier, and Value Responsibilities to Things” on page 83

7.4 Assigning Action, Identifier, and Value Responsibilities to Things Note: If you have the setup as in 7.2, “Identifying Responsibilities and Doing Hypertext Links” on page 78, continue with Step 4. To add responsibilities of the Book File, follow these steps: Prerequisites 1. You should have analyzed the use cases and identified actors, things, concepts, and other use cases. Especially the hypertext linking must be thoroughly done.

Responsibilities and Participants (Collaborators)

83

Step 1: Select the Things Relationship Select the Things relationship in the relationship list of the Relationship Browser. Step 2: Select the Book File Thing Select the Book File thing from the element list. Step 3: Create the Responsibility Select New> Responsibility from the element list pop-up menu for the selected thing. Step 4: Capture the Responsibility Details Capture the details of the responsibility: 1. 2. 3. 4. 5.

Select the Idiom from the drop-down list (Figure 38). Select the cardinality in the Max Cardinality group box. Complete the name in the Responsibility Name field. Adjust the Implementation Name if required Define the participants, if there are any.

Figure 38. Specify New Responsibility Dialog

For the books in the Book File the responsibility specification reads: 1. 2. 3. 4. 5.

84

Idiom Value Max Cardinality Many Responsibility Name Keeps Books Implementation Name books Participant Thing Book

VisualAge UML Designer

Step 7: Adding All Other Responsibilities, or... You could now identify and define all other action, identifier, and value responsibilities listed in Table 16 and Table 17 and then go to the next analysis step: identify and add the participants or collaborators of each responsibility. But you hold off until you are familiar with all types of responsibilities and participants, because VisualAge UML Designer offers the option to create the responsibility and its participants in one step: see the Participants button in the Specify New Responsibility dialog in Figure 38 on page 84. Results If you defined the action, identifier, and value responsibilities listed in Table 16 and Table 17, they would now be assigned to the things.

7.5 Defining Participants in Action, Identifier, and Value Responsibilities Note: If you have the setup as in 7.2, “Identifying Responsibilities and Doing Hypertext Links” on page 78, continue with Step 4. In the sample, the two responsibilities of Book File are:

• Books • Assign Book ID Each of these is a responsibility of Book File, but each also involves another thing, the Book. Therefore, you can create a link from each of these responsibilities to the Book thing to indicate that it participates. To do so, follow these steps: Prerequisites 1. You should have analyzed the use cases and identified actors, things, concepts and other use cases. Step 1: Select the Thing Relationship Select the Things relationship in the relationship list of the Relationship Browser. Step 2: Open the Focus Browser Double-click on Book File in the resulting list of things. A focus browser opens on the Book File thing. Step 3: Select the Responsibilities Relationship Select the Responsibilities relationship in the relationship list.

Responsibilities and Participants (Collaborators)

85

Step 4: Select the Responsibility Select Keeps Books from the list of responsibilities. Step 5: Create the Link to the Participants Select Link>Participants... from the pop-up menu for the selected responsibility in the element list. The Select The Role To Link To For Participants dialog opens and asks you for the participants to link to (Figure 39). Step 6: Select the Thing Type A participant can be either an actor or a thing. In this case, Book is a thing, so select Thing from the Available Types list.

Figure 39. The Select the Role To Link To For Participants Dialog

Step 7: Select the Participant Select Book entry. Step 8: Link the Participants Select >> to add Book to the list of linked participants. Step 9: Confirm the Linked Participants Select OK. Step 10: Assign All Other Participants You could now repeat the same procedure for all of the action, identifier, and value responsibilities already defined. But you hold off for the same reason

86

VisualAge UML Designer

explained at the end of 7.4, “Assigning Action, Identifier, and Value Responsibilities to Things” on page 83. Results If you defined the participants of the action, identifier, and value responsibilities listed in Table 16 on page 90 and Table 17 on page 91, they would now be defined for and linked to the things.

7.6 Assigning Reference Responsibilities with Participants When assigning reference responsibilities in VisualAge UML Designer, you are required to define a collaborating participant at the same time. The collaborating participant defines the thing or type to which the reference points. In our example, we have a Book and a Title. The information common to each copy of a title is handled by the title object; therefore, to avoid duplication, the book must know the title. The title objects must also know about the list of books because reservations are made on a title. Note: If you have the setup as in 7.2, “Identifying Responsibilities and Doing Hypertext Links” on page 78 (with windows as in Figure 37 on page 82), then: 1. 2. 3. 4.

Select the Book thing in the source list. Select the Responsibility in the relationship list. Select New... in the pop-up menu of the relationship list. Continue with “Step 4: Define Reference Responsibly” on page 88.

Here are the steps to create a reference responsibility: Prerequisite: 1. You should have created things for all participants you have to link to in the reference responsibilities; otherwise you have to create the thing when defining the participant. Step 1: Select a Relationship Select the Thing relationship in the relationship list of the Relationship Browser. Step 2: Select a Thing Select Book from the list of things in the element list. Step 3: Create Responsibility Select New>Responsibility... from the pop-up menu in element list.

Responsibilities and Participants (Collaborators)

87

Step 4: Define Reference Responsibly Select Reference from the Idiom drop-down list. Select 1 as the Max Cardinality and append to the predefined responsibility name the word Title. Note: The OK button will be enabled as soon as you specify a participant for reference responsibility. Step 5: Link a Participant Click on the Participant button and select and Title as the participant (similar to Figure 39 on page 86). Step 6: Confirm the Linked Participants Click OK. Step 7: Confirm the Responsibility Details Click OK. Step 8: Define the Other Reference Responsibilities You can now repeat the same procedure for all reference responsibilities and their participants listed in Table 16 on page 90 and Table 17 on page 91 or you can continue, as recommended, with 7.7, “Hypertext Linking the Responsibilities in the Use Cases” on page 88. Results The reference responsibilities and their participants have been created.

7.7 Hypertext Linking the Responsibilities in the Use Cases You not only hypertext link the responsibility in the thing or actor (Figure 37 on page 82, on the left), but you also might consider to hypertext linking each just created responsibility in your use cases in order to complete the circle: use case - thing - responsibility with use case - responsibility - thing. See the highlighted link label add, which is pointed to by two hands in Figure 37 on page 82, on the right. The horizontal hand to the left of the highlighted link label add indicates a hypertext link to a responsibility (Figure 37 on page 82, on the right). Unfortunately the label does not match the name of the responsibility. A replacement of the word add with the responsibility name would spoil the readability completely, whereas as an insert spoils the readability only partly. See the inserted Keeps Books responsibility for the word remove in the Remove Book use case in Figure 40.

88

VisualAge UML Designer

Figure 40. Remove Book Use Case: Responsibility Hypertext Link As Insert

A rigorous hypertext linking of both use cases and things leads to a thoroughly cross-checked system: everything is networked with many others and only a little plain text remains to keep (some) readability. If there still remains a lot of meaningful plain text, you have to consider going over all of your text in the model elements one more time. Results The responsibilities are hypertext linked in the use cases too, and the circle use case->thing->responsibility is closed by use case->responsibility->thing. Continue with 7.8, “Defining All Types of Responsibilities and Participants at Once” on page 89

7.8 Defining All Types of Responsibilities and Participants at Once Because VisualAge UML Designer supports defining any responsibility type and participants in the same step, you can define and assign all responsibilities at once. Identify the (remaining) responsibilities and participants you find under P=1 in Table 16, in Table 17 on page 91, and in Table 18 on page 92. P=1 stands for the initial protocol to build the initial class design (see Chapter 9, “Initial Class Designs (Object Model)” on page 105. Responsibilities under P=2 will be used later on to refine the initial class design (see Chapter 12, “Refined Class Designs (Object Model)” on page 131). Category is only a single string attribute of the Title thing, but is the subject in Chapter 13, “Extending the Model” on page 143. Define the initial responsibilities (P=1) as you have learned so far: either with the efficient setup of 7.2, “Identifying Responsibilities and Doing Hypertext Links” on page 78, or with the type and task grouped setup beginning with 7.4, “Assigning Action, Identifier, and Value Responsibilities to Things” on page 83. When prompted for the responsibility details (Figure 38 on page 84),

Responsibilities and Participants (Collaborators)

89

click the Participants button and link the participants as required (Figure 39 on page 86). Table 16. Thing Responsibilities 1

Thing

P

Responsibility Name

Implementation Name

T/C

Participants

Book File

1

Keeps Books Does assign Book ID Does search Books on Loan

books assignIdTo searchBooksOnLoanWith(1)

V/m A/A/-

Book Book Title(2)

2

Does search Books Does passing Entry Date Does process End of Day

searchBooksWithand assignEntryDate processEndOfDayWith

A/A/A/-

Title, Customer Book Date

Does change Expired Loans to Overdue

changeExpiredLoansToOver dueWith

A/-

Date

Identifies by ID Knows Title Knows Status

id title status

I/1 R/1 R/1

String Title Status

Keeps condition Does change Status

condition changeStatusTo

V/1 A/-

String String

2

Keeps entry Date Returns default Loan Period Does print Book Labels

entryDate defaultLoanPeriod printBookLabels

A/A/A/-

String -

1

Keeps discriminator Does build next Status

discriminator nextStatusWith

V/1 A/-

String String

2 *a

Identifies by id Keeps number of Loans Knows Book

id numberOfLoans book

V/1 V/1 R/1

String Integer Book

Return default Return Date

defaultReturnDate

A/-

-

Knows Customer Keeps Return Date

customer returnDate

R/1 V/1

Customer Date

Does build Overdue Status

buildOverdueStatusWith

A/-

Date

Book

1

Status

2 *b

Notes: - P=Protocol, T/C=Type/Cardinality, m=many, A=Action, I=Identifier, V=Value, -=no or yet undefined - (1)=searchBooksOnLoanWithAnd with P=2 implemented, (2)=Title, Customer with P=2 implemented - *a=later on will be in refining protocols, *b=later on will be in subclasses of Status

90

VisualAge UML Designer

Table 17. Thing Responsibilities 2

Thing

P

Responsibility Name

Implementation Name

T/C

Participants

Title Catalog

1

Keeps Titles Does assign Title ID Does search Titles

titles assignIdTo searchTitlesWith

V/m A/A/-

Title Title -(1)

2

Does assign Entry Date Returns default Loan Period Returns default Reservation P.

assignEntryDateTo defaultLoanPeriod defaultReservationPeriod

A/A/A/-

-

Does process End of Day Does remove Reservations

processEndOfDay removeReservationsWith

A/1 A/1

Date Date

Identifies by ID Keeps Title Keeps Author

id title author

I/1 V/1 V/1

String String String

Keeps Category(2) Knows Books Keeps Reservations

category books reservations

V/1 R/m V/m

String Book Reserv.

Keeps Abstract Keeps Number of Pages Keeps Publisher

abstract numberOfPages publisher

V/1 V/1 V/1

String Integer String

Keeps Publication Date Keeps ISBN Keeps Entry Date

publicationDate isbn entryDate

V/1 V/1 V/1

Date String Date

Keeps Default Loan Period Keeps Default Reservation P. Keeps Cover

defaultLoanPeriod defaultReservationPeriod cover

V/1 V/1 V/1

Integer Integer String/BLOB

Does books Print Book Labels Returns books Have to Print Book Labels

printBookLabels booksHaveToPrintBookLabels

A/A/-

-

1

Knows Customer

customer

R/1

Customer

2

Knows Title Knows Status

title status

R/1 R/1

Title Status

Keeps Expiration Date Return default Expiration Date

expirationDate defaultExpirationDate

V/1 A/-

Date -

Title

1

2

Reservation

Notes: - P=Protocol, T/C=Type/Cardinality, m=many, A=Action, I=Identifier, V=Value, -=no or yet undefined - (1)=TitleSearchCriteria with P=2 implemented - (2)=later on will be the subject of a model extension

Responsibilities and Participants (Collaborators)

91

Table 18. Thing Responsibilities 3

Thing

P Responsibility Name

Implementation Name

T

Participants

Customer File

1

Keeps Customers Does assign Customer ID Does search Customers

customers assignIdTo searchCustomers

V/m A/A/-

Customer Customer -(1)

2

Does assign Member Since Date Returns default Maximum Number of Items on Loan

assignMemberSinceTo defaultMaximumNumberOfIt emsOnLoan

A/A/-

Customer -

1

Identifies by ID Keeps firstname Keeps lastname

id firstname lastname

I/1 V/1 V/1

String String String

2

Keeps middle Initial Keeps street Keeps city

middleInitial street city

V/1 V/1 V/1

String String String

Keeps state Keeps ZIP Keeps phone Number

state zip phoneNumber

V/1 V/1 V/1

String String String

Keeps member Since Date Keeps SSN Keeps photo

memberSince ssn photo

V/1 V/1 V/1

Date String String/BLOB

Keeps max Number Items on Loan Returns has Books on Loan Does print Library Membership Card

maxNumberItemsOnLoan hasBooksOnLoan printLibraryMembershipCard

A/-

-

Customer

Notes: - P=Protocol, T/C=Type/Cardinality, m=many, A=Action, I=Identifier, V=Value, -=no or yet undefined - (1)=CustomerSearchCriteria with P=2 implemented

Note: The A Library Sample does not assign responsibilities to actors and does not go into more details for most responsibilities. In a system with complex business processes and many actors and timers, the definition of responsibilities for all actors and timers help to operate the system in a controlled and reliable manner. More details in the description of each responsibility is required with coarse grain responsibilities for a further refinement. If the Does assign Xxxx ID of the Xxxx File and Title Catalog were really coarse grain, the description would read like this:

Does assign Customer ID Does assign the id |Identification| to the |Customer|. The id is a string derived from a counter, which is incriminated before every id

92

VisualAge UML Designer

assignment. The ids start with 1 and are padded with leading zeroes up to 6 digits, for example, 000001. Result All responsibilities and their participants have been created and hypertext linked.

Responsibilities and Participants (Collaborators)

93

94

VisualAge UML Designer

Chapter 8. Protocols After determining the requirements of the library management system, setting up the use cases the system must support, identifying the actors and things, and assigning responsibilities and collaborators to the things, the next step in VisualAge UML Designer is to define protocols. This is an important step between the analysis of the system and the definition of your classes. At this point you would typically start to define classes. Because things are candidate objects, you only have to select or decide which things should become real classes and implement the responsibilities as their methods. With VisualAge UML Designer, however, you must first take a closer look at the responsibilities in order to define the interfaces to which your objects must conform later. These interfaces are realized through the use of protocols. In fact Java follows the same concept when you use interfaces.

8.1 The Concept Protocols are the main artifact of the analysis phase in VisualAge UML Designer. They integrate things, responsibilities, and collaborators in order to give you a base on which to design your classes. When working with VisualAge UML Designer, you cannot avoid defining protocols, because the tool uses protocols for providing a typing mechanism for objects, and it needs protocols as a source for generating class designs if you want to create a real design rather than design your model by direct implementation of the class. Protocols define behavior only; implementation is still up to the class. A class is said to conform to a protocol if it implements all of the messages defined by that protocol and adheres to the specified types for input and output values. A class, which is represented in VisualAge UML Designer as a Class Design (See 9.1, “Class Design” on page 105), can conform to more than one protocol. Therefore multiple inheritance in VisualAge UML Designer is achieved by the use of protocols. Because the class inherits multiple sets of function, we call that multiple inheritance. So multiple inheritance of types is possible at this phase of development, whereas at the implementation phase differences can be found depending on the language you use. Smalltalk, for example, supports multiple inheritance only by composition and promoting the interface, whereas Java uses the interfaces, which are part of the Java language. In addition, protocols can refine other protocols. This process is similar to, but distinct from, inheritance among classes, which is implementation-based. Classes conforming to protocols that refine each other do not inherit

© Copyright IBM Corp. 1998

95

automatically from each other; they implement only those methods specified by their protocols, which are in fact about the same, because a refining protocol can add additional message specifications, but it cannot remove any. A refining protocol can also refine the input and output types of the message specifications defined by the supertype, but only according to the following rules: • The input parameter types can be less specific than those defined by the supertype. Therefore any type is accepted that is accepted by the supertype. • The return type can be more specific than the return type defined by the supertype. Therefore it must return a subset of the possible types returned by the supertype. Rigorous use of protocols guarantees substitutability: When you send a message to an object, you are not really interested in the class definition of that object, but you want to be sure that the object understands the message. Thus, you want to be sure that the specified method is implemented, which is assured when it conforms to the protocol defining the interface. Any class conforming to a given protocol (or to a protocol refining that protocol) can be substituted for any other class conforming to that same protocol. If a class conforms to the expected protocol, type mismatches cannot occur. In Smalltalk terms this means never getting a "doesNotUnderstand" message at runtime, and in Java you avoid "Method not found/No such method" errors during compile time. A reasonable initial assumption in modeling is that there will be one protocol (and therefore one type) for each defined thing. In this simple mapping, the responsibilities of the thing become message specifications in the protocol, defined with more detail and more precision. It is then up to you to decide whether you also want to create things for protocols that describe only a special function. So the one-to-one mapping does not always hold true, but it is a good place to start. Of course when it comes to classes, classes will mostly conform to more than one protocol, although things are defined as candidate objects. Protocols provide an intermediate transformation. Thus, the use of protocols avoids unnecessary complexity and increases traceability. Protocols themselves are not code; they are abstract interface specifications that can usually be mapped into actual object-oriented languages in a straightforward manner. In fact protocols build the base for the generation of interfaces in Java.

96

VisualAge UML Designer

8.2 Generating a Protocol Automatically If you have already defined responsibilities for a thing, you can automatically generate a protocol from them. When generating a protocol, VisualAge UML Designer assumes the default mapping of one message specification for each action responsibility, and it uses the implementation name of the responsibility to generate a default message name. You can change the generated message name if it is not satisfactory. You can also make other manual changes, such as adding message specifications, splitting a protocol into two, or merging two protocols into one. For value, identifier, and reference responsibilities, the tool generates setters and getters, and add and remove message specifications if you have defined a responsibility with a cardinality of "many" for a thing. NOTE: You can also define protocols manually. We describe this process in Appendix A.3, “Create a New Protocol and Add Attributes and Message Specifications” on page 206, because we do not recommend it at this phase of development. In our library management system you have already defined several responsibilities for the thing Book File (for example, Keeps Books), so you can now generate a protocol that implements the thing. To generate a protocol for Book File, follow these steps: Prerequisites 1. You must have created a thing. 2. You should have defined the responsibilities of the thing. (Recommended, because of substitutability. Of course it is possible to create an empty protocol first and then add method specifications. But then you will be inconsistent with your thing definitions, if you do not define referring responsibilities there, because responsibilities of things and message specifications of protocols are related to each other.) Step 1: Select Book File Select Things in the relationship list of the Relationship Browser and then Book File from the list of things on the right. Step 2: Create a Protocol Select Transforms->Generate Protocol... from the pop-up menu of the element list.

Protocols

97

Step 3: Capture Details In the Generate Protocols For... dialog (Figure 41): • Select +Book File[Book File] from the Protocol Names list • Check Generate Associations • Check Generate Messages

Figure 41. Generate Protocols for Book File

Step 4: Add a Protocol Select OK to generate the protocol. Note: VisualAge UML Designer also creates a protocol for the Book because you defined it as a participant in the Keeps Books responsibility. But it is only an empty protocol for setting the right parameter type of the message specification. So you must generate a protocol for every thing. VisualAge UML Designer does not differentiate between complete (concerned with the responsibilities of a thing) and incomplete protocols. For more information about changing a parameter type, see Appendix A.5, “Change a Parameter Type” on page 208. Step 5: Add the Other Protocols Repeat steps 1 through 4 for the following things (but now you can select all of the things in the element list):

• • • • •

98

Book Book File (protocol already generated) Customer Customer File Reservation

VisualAge UML Designer

• Status • Title • Title Catalog Note: In the Generate Protocols window (see Figure 42), select all protocols on the Protocol Names list and use the default settings for the message generation options.

Figure 42. Generate Protocols for Library Model (All Things)

Results You have now generated the protocols. You can take a closer look at them by using the focus browser, following these steps: Step 1: Open the Protocol Browser Select Protocols in the relationship list of the Relationship Browser and double-click on Book File. The focus browser opens on the Book File protocol. From here you can explore the Book File protocol. Step 2: Look at Message Specifications In the focus browser, select Messages in the relationship list. In the element list you should see a list of the message specifications that were automatically generated for the protocol based on the responsibilities you defined earlier (Figure 43). The path browser (Figure 45 on page 101) and the hierarchy browser (Figure 46 on page 103) are useful as well for looking at model elements.

Protocols

99

VisualAge UML Designer uses a straightforward transformation to convert responsibility names into Smalltalk, UML, or Java style message specifications that could eventually become Smalltalk or Java method names. If the generated message names are not satisfactory, you can change them. Note: Some of the generated message specifications end in colons, indicating that they take parameters. They have been generated with parameters because each corresponding responsibility has a participant defined.

Figure 43. Focus []: Messages after Protocol Generation

100

VisualAge UML Designer

Step 3: Open the Focus Browser on a Message Double-click on removeBook in the element list to see more information about the message. Step 4: Look at Parameters Select Parameters in the relationship list of the focus browser. In the element list you should see the parameter aBook, because you defined it as a participant of the Keeps Books responsibility (Figure 44, and within other browsers: Figure 45 and Figure 46 on page 103).

Figure 44. Parameters of the addBook Message Specification

Figure 45. Open [Xxxx...] Path Browser (Model... Parameter)

Protocols

101

8.3 Using Various Browsers with Various Settings Note that until now you used the Relationship Browser to do the major part of the sample work. If you prefer to work with the path browser (Figure 45) or hierarch browser (Figure 46 on page 103), you can achieve the same results. You such options as creating, linking, and browsing in the context pop-up menus of the selected model elements lists. With the hierarchy browser you have a single window, in which you need to scroll, expand, and collapse only in order to access all the model elements, whereas with the other browsers you use many more windows. Note as well, that the hierarchy browser in Figure 46 has a Vertical Split Orientation setting whereas the hierarchy browser in Figure 4 on page 7 has a Horizontal setting. Change the setting through the UML Designer or Options menu, and then System Settings..., on the Browsers page. Note further that the text is displayed in the Text Path>Summary Text mode set in the text pop-up menu.

8.4 Renaming Generated Model Elements (Messages) Note, for example, the changed message name #searchBooksWith:and: of the protocol of the A Library Model in the hierarchy browser (Figure 46, pointed to by the cursor). You can rename model elements in the hierarchy browser as easily as in the Relationship Browser: 1. 2. 3. 4.

Select the model element you want to rename. Select Rename... in the pop-up menu of the hierarchy/source/element list. Type the new name in the Information Required dialog. Click on OK.

Note the rename, but be aware that a message regeneration recreates the original message (as an additional message).

102

VisualAge UML Designer

Figure 46. Open [Xxxx...] Hierarchy Browser (Model... Message)

Protocols

103

104

VisualAge UML Designer

Chapter 9. Initial Class Designs (Object Model) After defining protocols you now have to decide what your classes will be and which protocols they conform to. Then you will establish association relationship links between the classes. You create these relationships nonvisually by using the Relationship Browser, or from within the class diagrammer (Chapter 10, “Class Diagrams” on page 111).

9.1 Class Design A class design is a model element that represents a class. The class design can be connected to a real Smalltalk class (connection to a Java source file is not supported yet), but is separate from it. Remember, VisualAge UML Designer calls an implemented class a real class. It provides a placeholder within the model to which the other model elements can be attached. Thereby it decouples the analysis and design from the implementation aspects but provides a common element for the two parts. For example, in a class diagram each class figure is attached to a class design rather than to an real class although the class design itself can be connected to a real class. This does not mean that a class design must have the same name as its real class, but once connected to a real class, it reflects exactly any changes made in the real class. Of course, using the same name makes life easier, but having class designs as containers without the need of underlying Smalltalk or Java code, you achieve much more flexibility in your modeling. Combining the class information and metaclass information in a single entity is another property of class desings in VisualAge UML Designer. In pure UML you have to define two entities: the class and the metaclass. The class keeps the information about the instance variables and instance methods, whereas the metaclass keeps the information about the class variables and class methods. VisualAge UML Designer with its class design is an appropriate object-oriented modeling tool, because most of the object-oriented languages, especially Smalltalk and Java, combine in their implementation the class and metaclass information in one single entity too: the class. You combine class and instance state and behavior in a single class design by linking protocols. In the link of each protocol you specify, whether the protocol is a class or instance protocol. Remember, a class design conforms to a protocol if it implements all of the methods defined by the protocol, and a class design can conform to more than one protocol.

© Copyright IBM Corp. 1998

105

Especially for the pure Smalltalk development, VisualAge UML Designer class designs are of great value: They specify information about parameters and return types, which are not stored in the Smalltalk class definitions, because Smalltalk is type free. For VisualAge Smalltalk parts, where the public interface is typed, as well as for Java, where interfaces are defined and a strict typing is required, they are just natural counterparts. Conversely a class design does not repeat information that is held on the real class to which the class design is connected. The superclass, that is the inheritance relationship, and the messages a class design actually shows are the messages of the real class. A class design always looks up the real class definitions first and prefers them to whatever you (try to) define in your model. Therefore you cannot change your inheritance information as long as a class design is connected to a real class. Delete, disconnect, or change the real class to get back the modeling freedom. In effect, class designs provide a bridge between analysis elements (like protocols) and implementation classes. They provide traceability links from implementation classes back to the model elements from which they are derived. A class design merges the interface information from its protocol definitions with the actual method definitions of its real class, always preferring the definitions of the real class. Thus its methods—the implementation of the interface—come from the following sources: • Methods or attributes defined in a protocol to which the class design conforms. These are called specified methods or attributes. A specified method or attribute might or might not actually be implemented in the underlying class, if any. • Methods or attributes defined in the underlying Smalltalk or Java class to which the class design is linked, if any. These are called implemented methods or attributes. An implemented method or attribute might or might not be specified by any protocols to which the class design conforms. Table 19 shows the combined state a method in class designs can have and the coloring in the VisualAge UML Designer browsers: Table 19. State and Visual Clue of Attributes and Methods

106

Implemented

Not Implemented

Specified

Protocol, Smalltalk Class (green)

Protocol only (yellow)

Unspecified

Smalltalk Class only (red)

-

VisualAge UML Designer

9.2 Generating a Class Design Follow these steps to create the class designs for your protocols: Prerequisites You have already created a protocol. (Recommended; otherwise you must retrieve it from a real class (see 19.2, “Retrieving Protocols from Real Classes” on page 193) or you must link the class design to a protocol later in order to fill it with information.) Step 1: Select a Protocol In the Relationship Browser select Protocols from the relationships in the relationship list and Book File from the element list. Step 2: Generate a Class Design Select Transforms->Generate Class Design... from the pop-up menu in the element list. The Generate Class Design for Xxxx... dialog opens (Figure 47).

Figure 47. Generate Class Design for Protocol Xxxx Dialog

Step 3: Capture Details In the Generate Class Design for Xxxx... Protocol (Figure 47): • Select +Book File class[] as the Class Design • Check Instance as the Protocol Type • Unmark the Generate Real Classes button

Initial Class Designs (Object Model)

107

At this point you do not want to generate real classes, because this is the first class design and will need refinement (for sure). Creating real classes now would imply that no changes concerning the class hierarchy or inheritance tree can bee made in the future (see 2.3, “Design” on page 17). NOTE: VisualAge UML Designer allows you to define protocols for class conformance too. Such protocols are the base for the class methods and attributes in the real classes. To distinguish instance and class methods, VisualAge UML Designer prefixes class methods with a leading dollar sign ($) when listing the methods in class designs. Step 4: Confirm the Creation of a Class Design Select OK. The new Class Design is created. Note: Because you created the new class design from the Book File protocol, it has the same name as that protocol. Of course, you can change this name if you want (see Appendix A.9, “Rename a Model Element” on page 211). Step 5: Generate the Other Class Designs Repeat steps 1 through 4 for the following protocols:

• • • • • • • •

Book File (already done) Book Customer File Customer Reservation Status Title Catalog Title

Results The class designs are created and conform to the specified protocols. You find the generated class design in the Relationship Browser by selecting the Class Designs relationship in the relationship list. Double-click on the BookFile class design and select the Methods relationship list of the focus browser to see the list of generated methods (Figure 48). Note: Because you choose not to generate real classes, all methods are marked with a yellow bullet in the element list of the browsers; otherwise they would be marked with a green bullet.

108

VisualAge UML Designer

Figure 48. Focus [Book File] Browser: Class Design with Instance Methods

9.3 Making a Class Design Dependent on a Protocol Let us take a closer look at the class design you have just created. Because you generated it from the Book File protocol, it not only has the same name, but it is also linked to that protocol as its Main Protocol. Of course, you could change the its name, but do really not want to do that? No. Instead, we suggest that you create an even stronger connection with that protocol: You make the class design dependent on the protocol, such that every change in the protocol automatically shows up in the class design. If you also want to have the changes propagated to the real class, you must regenerate the real class from the class design, or more selectively the methods from the added or changed messages of the class design. While generating the real class you have the option of overwriting existing methods. But note that in VisualAge UML Designer this is only one way to manage changes. Often you just do not want to connect your analysis artifacts with your design elements in such a synchronous way. But let us now make the Book File class design dependent on one of its protocols.

Initial Class Designs (Object Model)

109

Prerequisites 1. You have already created the class design that you want to make dependent on a protocol. 2. You have already created the protocol on which you want to make you class design dependent on. Step 1: Select a Class Design Select Class Design relationship from the relationship list in the Relationship Browser and Book File from the list of Class Designs. Step 2: Create a Depends on Protocol Link Select Link>Depends on Protocol... from the pop-up menu of the element list. Step 3: Capture Details Select the protocol from the Available list and add it to the Linked list, using the >> button. Note: You can make a class design dependent on more than one protocol! Step 4: Establish the Link Click on OK. Step 5: Make the Other Class Designs Dependent Repeat steps 1 through 4 for the following protocols:

• • • • • • • •

Book File (already done) Book Customer File Customer Reservation Status Title Catalog Title

Results The class designs are now dependent on their protocols, and every change in a protocol is automatically reflected in the class design. The protocols are listed in the Depends on Protocol relationship in the focus browser of the class design.

110

VisualAge UML Designer

Chapter 10. Class Diagrams A class diagram is a view of a model. It exposes selected elements of the model that are necessary for conveying some important aspect of the design. The model itself exists independently of the diagram. VisualAge UML Designer keeps a class diagram in synchronization with the underlying model, automatically reflecting changes to the model elements and indicating errors if underlying elements no longer exist. The class design model elements and the class diagram figures work together in the same way as use case model elements and use case diagrams. Refer to the explanations given in the introductions of Chapter 6, “Use Case Diagrams” on page 67, and 6.2, “Adding a Group Figure” on page 68.

10.1 Creating a Class Diagram To create a new class diagram for the library management system, follow these steps: Prerequisites 1. You should have class designs defined (Recommended; otherwise you would create empty class designs and you must link them to protocols later.) Step 1: Select the Relationship Select the Class Diagrams relationship in the relationship list of the Relationship Browser. Step 2: Create New Diagram Select New... from the pop-up menu of the relationship list. Step 3: Capture Details When prompted for the name of the diagram, type Initial Class Designs

and click on OK. Results The new diagram appears in the element list. You can double-click on Initial Class Design to open the class diagrammer.

© Copyright IBM Corp. 1998

111

10.2 Add a Class Figure To create and place a new figure, select the appropriate creation tool from the tool bar along the left edge of the window (Figure 52 on page 117). Table 20 lists and explains the figure creation tools. Table 20. Class Diagrammer: Figures and Creation Tool

Tool

Name Protocol

Creates a figure representing a protocol

Class

Creates a figure representing a class

Object

Creates a figure representing an object instance

Inheritance

Creates a figure representing an inheritance link between protocols

Conformance

Creates a figure representing a conformance link between a class and a protocol

Dependency

Creates a figure representing a dependency link between a class and a protocol

Association

Creates a figure representing a simple association link between classes or protocols

Aggregation

Creates a figure representing an aggregation link between classes or protocols

Note: (*) The association link is used to link a use case to a used use case figure creation tool.

To build a class diagram for the Book File example, follow these steps: Prerequisites: 1. You must be in an open class diagram. Step 1: Select a Figure Select the class creation tool from the tool bar.

112

VisualAge UML Designer

Step 2: Add Book File Class Use the left mouse button to drop the figure in an empty area of the drawing surface (Figure 49). Note: When first added to the drawing surface, the figure is labeled with a question mark (?), indicating that it is not yet associated with an underlying model element. All elements in VisualAge UML Designer diagrams must be associated with underlying models.

Figure 49. Class Diagram: Drop, Attach, Edit, and Format Class Figure

Step 3: Attach Figure to Model Element Select Attach from the pop-up menu of the empty figure and, when prompted for the class design to link, select Book File from the list of Class Designs and click on OK. NOTE: If you have not created the class design yet, you can do so now by clicking on the New button. You then create an empty class design that does not show any methods or attributes. Because the underlying Book File class design has already been created, methods and instance variables appear in the class design figure. (To see the class definition, select Open with and a browser of your choice from the class figure’s pop-up menu—to open a class browser.) Step 4: Edit and Format the Figure In the context pop-up menu of the figure (Figure 50, top left), select Display Options to define the displayed parts of the figure and to change the Figure Properties... such as font and color (see Appendix A.11, “Change Figure Fonts and Colors in Diagrams” on page 213).

Class Diagrams

113

Figure 50. Class Diagrammer Figure Pop-Up Menu with Submenus

114

VisualAge UML Designer

In the context pop-up menu of the figure (Figure 50, top left) select Attributes>Name..., Methods>Named... or Filtering Options... (Figure 51) to define which attributes and methods should be presented in the figure. Use the menu bar Format option to align figures with others.

Figure 51. Filtering Options for Class Figure Detail Presentation

Step 5: Add Other Class Figures You have now diagrammed the Book File class. To completely diagram your design as it stands now, you need to add the other classes you have come up with so that you can show their relationships to one another. Follow steps 1 through 5 to add the following design elements:

• • • • • • • •

Book File class (already done) Book class Customer File class Customer class Reservation class Status class Title Catalog class Title class

Class Diagrams

115

Results The new figures have been created. They are attached to their class designs and look like those in Figure 52.

10.3 Creating Associations among Classes To complete the first pass at a class diagram, you must now connect the design elements to one another to show the relationships among them. Whereas the models of the connections you have created so far, such as the conformance relationship link between the Book File class and protocol, are actually links (that is, instances of relationships) between the model element types predefined by the VisualAge UML Designer metamodel, associations are the way that you specify that it will be possible to have a connection between the objects in the system defined by your model. In other words, they are relationship types in the instance model as well as relationship instances in the metamodel. To define and show the relationships between classes—called associations—in the library management system, follow these steps: Prerequisites: 1. You must have an open class diagram with class figures. 2. The class figures must be attached to underlying class designs. Step 1: Crate an Association Select the association figure creation tool from the tool bar on the left of the class diagrammer to connect the Title class figure to the Book class figure. Add the association by first clicking on the Title and then on the Book figure. The association figure indicates that an association exists between the two elements (a Title must keep track of Book objects with the same title). You will add (more) labels later to show the nature of the association. Step 2: Add the Other Associations Repeat step 1 to create the other associations in the diagram. Note: Some associations, like that between Title Catalog and Title, are aggregations, and you must use the aggregation tool for creation. Results With all of the associations added, the diagram should look like that in Figure 52.

116

VisualAge UML Designer

Figure 52. Class Diagrammer [Initial Class Designs] (Object Model)

Class Diagrams

117

10.4 Adding Figure Adornments and Editing Model Element Details Figures may have adornments, such as labels, to make their diagrams more understandable and to convey additional information about the model elements. Adornments are used in particular on connector figures to convey additional UML semantics, for example, an association can be adorned to show the navigability and multiplicity of the association. For most types of adornments, you can specify whether the adornment is shown or not on a given figure. Note that the property that the adornment expresses exists in the model regardless of whether it is displayed or not. Adornments can include text labels. For each of the two directions of an association there is a name and a role name. The name describes the relationship. The role name describes the role of an end element in the relationship. Thus in effect four different text labels can be shown on an association: a Source, To name, From name, and Destination label. You have two options for naming your associations: • Use a verb describing the relationship, so that the association can be read (usually from left to right) as a sentence. • Use a noun referring to the destination entity, with appropriate plurality for the multiplicity. This option is the default for the labels VisualAge UML Designer can generate. For example, you can add a label to the association between Title and Book. A Title must know one or more Books, so you also have to show the multiplicity of the association. The VisualAge UML Designer class diagrammer gives you easy access to important model element details, such as relationship names, role names, and cardinality. Prerequisites: You must have an open class diagram with figures for classes (class designs) and associations. Step 1: Add an Association-To Name Figure Adornment Select the association between Title and Book and then select Name>Show To from its pop-up menu. A default label for the association using the name of the destination is shown (parent) . In the menus figure adornments are called Labels (Hide All Labels, Show All Labels).

118

VisualAge UML Designer

Step 2: Edit the Association-To Name Select the association between Title and Book and then select Rename->To from its pop-up menu. Enter title as name and click somewhere in the white space of the diagram. Step 3: Edit Names, Edit Cardinalities, Add Other Adornments Use the relationship pop-up menu and its options (Figure 53) to edit names of relationships and roles, edit cardinalities, edit navigabilities, and hide and show the information as figure adornments. To edit some relationship details, such as role details, you have to open the relationship editor with a double-click. Take a look at the result in Figure 54 on page 120, where you can read the required edits and adds.

Figure 53. Relationship Figure Pop-Up Menu (Sample for Title-Book)

Note about Edits and Display Options Edits of the names of relationships and roles, cardinalities, and navigabilities are changes to the model, whereas show and hide of relationships and their adornments are display options only in the actual diagram. The VisualAge UML Designer class diagrammer offers a very efficient tool to copy display options: Edit>Copy/Paste Display Options.

Class Diagrams

119

Result You have a class diagram of the initial class designs with cardinalities adjusted, associations renamed, and complemented with more figure adornments (Figure 54).

Figure 54. Initial Class Designs and Diagram: Adjusted and Complemented

120

VisualAge UML Designer

Chapter 11. Interaction Diagrams Interaction diagrams visually describe the interaction of objects in a system. They demonstrate the message flow and how the objects are related to one another. The only interaction diagrams supported by VisualAge UML Designer are sequence diagrams. Collaboration diagrams are not yet supported. Not all potential interactions of systems nor all details of selected interactions have to show up in interaction diagrams. You define the number of diagrams and choose the elements and the depth of details to put the focus on the crucial interactions of the system.

11.1 Creating a Sequence Diagram A sequence diagram is a visual representation of a series of interactions between the objects in your system. A sequence diagram shows instances of objects as vertical bars. The exchange of messages is indicated by horizontal lines connecting the vertical bars. Unlike a class diagram, which is a static representation of the system, a sequence diagram is a representation of the dynamic interaction of your system, serialized over time. Like a class diagram, a sequence diagram is another view of the model, a more dynamic view; each figure in a sequence diagram is attached to an underlying model element. Because a sequence diagram depicts messages sent and returned between objects, your classes must have some defined behavior before you can build a sequence diagram. Because a sequence diagram depicts a particular sequence of events, it generally does not show all of the possible interactions in your system. Instead, it illustrates the interactions associated with a particular use case. A sequence diagram can help you validate your design by confirming that it accommodates your use cases. It can also be useful for documenting how to use system interfaces that assume modal behavior; specifically, that a sequence of messages must be sent in a particular order to work correctly. Before we create a sequence diagram we need to introduce a new model element: the instance, usually called an object. Instances are the living entities, each created using a class as a template. The creation is called instantiation. Objects, or instances can be used in sequence or class diagrams.

© Copyright IBM Corp. 1998

121

For the library management system, we might want to create a sequence diagram that shows adding the first book of a title to the system, involving in fact a sequence of use cases: Maintain Books, Maintain Titles, Add Book, Add Title, Enter Title Details, and Enter Book Details. The sequence diagram will be a new model element added to the library model. To start working on a new sequence diagram, follow these steps: Prerequisites 1. Model 2. Use cases (recommended, because they should be the base for your graphical description) 3. Class designs (recommended, otherwise you must create some later) Step 1: Select the Relationship Select the Sequence Diagrams relationship in the relationship list of the Relationship Browser. Step 2: Create New Diagram Select New... from the pop-up menu of the relationship list. Step 3: Capture Details When prompted for the name of the diagram, type: Add the First Book of a Title

and click on OK. Results The new diagram appears in the element list. You can double-click on Add First Book of a Title to open the sequence diagrammer. Results A new entry, Add First Book of a Title, is added to the list of sequence diagrams in the Relationship Browser. If you double-click on the entry, the sequence diagrammer opens.

11.2 Adding an Object to the Diagram When you open the sequence diagrammer you find an activation bar along the left edge. An activation bar shows when an object is active. An object is considered active from the time it receives a message to the time it returns control to the sender. Only an active object can send messages. The

122

VisualAge UML Designer

activation bar along the left edge of the window represents the actor or object that initiates the sequence of messages shown in the sequence diagram. To add an element to the diagram, select the appropriate tool from the tool bar along the left edge of the window (Figure 58 on page 128). Table 21 lists and explains the major figure creation tools: Table 21. Object Interaction Diagrammer: Figure Creation Tools

Tool

Name

Description

Object

Creates a figure representing an instance of a class design, an object

Method Call

Creates a figure representing a message sent from one object to another

Four objects are involved in the Add First Book of a Title scenario: • • • •

A A A A

Book object Title object Book File object Title Catalog object

You have already defined class designs for these two objects. To create and add these objects to the sequence diagram, follow these steps: Prerequisites: 1. You should have class designs defined. Step 1: Create Object Figure Select the Object figure creation tool from the tool bar and use the left mouse button to place a new figure near the left edge of the drawing surface (adjacent to the activation bar). Step 2: Capture Details Select Attach... from the pop-up menu of the new object figure, and when prompted, select Book as the class design to which to link. A new instance will be created for the class design automatically and then selected. Select Ok. The object figure is now labeled Book. Step 3: Add Other Object Figures Repeat the same procedure for the following object figures:

• Book • Title

Interaction Diagrams

123

• Book File • Title Catalog Results Your sequence diagram should now look like that in Figure 55.

Figure 55. Sequence Diagrammer

11.3 Add Method Calls to the Diagram To show the sequence of method calls in adding the first book of a title, you must now add method call figures to the diagram. Each figure shows a single method call between a sender and a receiver. The figure starts on the system or on any object activation of the sender, creates an activation bar on the receiver object, and returns back to the sender. The message call is labeled as well as the returned object. If the message has the return type defined, the label shows the name of the main protocol, otherwise . The sequence of events to add a book to the system is: A librarian (an actor) uses the library system interface to: 1. 2. 3. 4. 5. 6.

Create a new book information, aBook Create a new title information, aTitle Enter the information about the aTitle title, such as the title and author. Assign the title to the book with #title: Enter the other information about the aBook book Add the book to the BookFile with addBook:

The method call addBook: of BookFile calls: 7. Add the new title to the TitleCatalog with addTitle: The method call addTitle: of TitleCatalog calls: 8. Assign an ID to the new title with assignIdTo:

124

VisualAge UML Designer

The continuation can be read from the diagram in Figure 58 on page 128. To start the sequence diagram, the first method call must originate from the system activation bar at the left edge. (Only an active object can send a message to another object.) This initial method call represents a call from outside the diagram. To add this method call to the diagram, follow these steps: Prerequisites: 1. You must have an open sequence diagram with object figures. 2. The object figures have to be attached to underlying class designs. 3. The class designs must have methods. Step 1: Select the Method Call Figure Select the Method call figure creation tool from the tool bar. Step 2: Place Method Call Because the first message is "new" and sent to the Book Class in order to get a new book instance, hold down the alt key and click once on the activation bar along the left edge of the diagram to indicate the source of the method call (click and release). The cursor should change to a no entry sign. Drag the mouse over the Book object's (and class’) scope line to indicate the destination and click the left mouse button. The figure you created indicates a method call from outside the diagram to the Book class. Step 3: Capture details When prompted (Figure 56) to choose a method: • Select Behavior in the Classes list • Select Behavior in the Protocols list • Select new from the Messages list and click on OK.

Interaction Diagrams

125

Figure 56. Choose a Method Dialog in the Sequence Diagrammer

Note: The class Behavior with the main protocol Behavior is the superclass of the Book Class class. If you would have made the Book class design conform classwise to a protocol by linking a protocol as a class protocol, this protocol would show up in the Protocols list when you select Book in the Classes list. For example for Figure 59 on page 129, an ObjectWithIdFactory protocol (Figure 57) was created and linked as class protocol to the Customer class design, in order to make the Customer class to understand the messages new, assignIdTo:, nextId, lastId, and l astId:. Sample 1a in Figure 59 on page 129 uses the overriding new, which includes the automatic assignment of the ID at instantiation time of the object.

Figure 57. Choose a Method Dialog in the Sequence Diagrammer

126

VisualAge UML Designer

Step 4: Create the Other Method Calls To build the rest of the sequence diagram, you have to add a series of instance method calls. Use Figure 58 on page 128 as guide in constructing the diagram. Note 1: If you need more space to send messages from an activation bar, you can widen it along the object’s scope line. For example, click on the activation bar for the addBook method call on the BookFile object's scopeline. Use the left mouse button to drag the bottom selection handle of the activation bar downward, lengthening the activation bar. Use the diagram. You can also move each activation bar along the scope line or inside a self-calling activation bar to make space for insertions. Note 2: In Figure 58 on page 128, the BookFile and TitleCatalog objects are set to IsAnonymous where as aBook : Book and aTitle : Title are not, and all labels are model specific (not Use Figure Specific Labels). Results You have now sequence diagram showing who sends which message to which receiver and returns which answer—and this in which sequence.

11.4 Sequence Diagram with Calls to User-Created Class Method The sequence diagram in Figure 59 contains color-edited class methods. Sample 1a invokes the assignIdTo: in the new method, whereas in Sample 1b the id is assigned independently. Sample 2 shows a simple instance method call. The corresponding Smalltalk code is shown as text.Class methods are grayed (done with Edit->Figure Properties...), and have a ($) Dollar sign in front of the message label (done by the sequence diagrammer of VisualAge UML Designer).

Interaction Diagrams

127

Figure 58. Sequence Diagrammer: Add First Book of a Title Diagram

128

VisualAge UML Designer

Figure 59. Sequence Diagram: Alternative Invocation Points of assignIdTo:

Interaction Diagrams

129

130

VisualAge UML Designer

Chapter 12. Refined Class Designs (Object Model) Now we want to look at change management and see how VisualAge UML Designer supports it. We present a few examples of refining and extending the object model to demonstrate how the tool supports inheritance of objects. We extend the model by introducing a new association class.

12.1 Class Redesign If we take a closer look at the status information of a Book , we find that sometimes more information is required and sometimes less. For example, when a Book is available, no more information is required. However, if it is borrowed, we want to have information about the date it will be returned and of course the customer who has actually borrowed it. If there is a reservation for a Title and a copy of that title is returned, the status of this special Book should change to "reserved." So, there are also constraints included in the status change. We decide to implement the status change as described by the state design pattern (see Appendix E.3, “Other Publications” on page 221). Therefore we make the Status class an abstract superclass and add special state subclasses like Available and Borrowed. The special state subclasses inherit from Status the id, discriminator, number Of Loans, and book , but get their own features to cover the corresponding state. Further redesign decisions are: • The status should look like an identifiable contract between book customer and be kept in its own, searchable collection called Status File • The reservation should look like an identifiable contract between title and customer and be kept in its own, searchable collection called Reservation File

12.2 Inheriting Class Information To inherit class information, you have to create new protocols because the class design element is only a collector of protocols as we describe in 9.1, “Class Design” on page 105. We decided to develop everything in this part of the book in a straightforward way, even though with VisualAge UML Designer you can retrieve information by a kind of backward generation (Chapter 19, “Reverse Engineering and Integrating Existing Classes” on page 191). So,

© Copyright IBM Corp. 1998

131

once you have created the new class designs from your protocols, you can then inherit the behavior from the Status class design. Prerequisites 1. You must have created the Status class design and protocol. Step 1: Create a New Thing with Its Responsibilities Create a Borrowed thing as described in Appendix A.2, “Create a New Model Element” on page 206. For the thing descriptions see Table 22. Assign the responsibilities you find in the way you did in Chapter 7, “Responsibilities and Participants (Collaborators)” on page 77. For the responsibilities see Table 23 on page 133. Table 22. Things 4

Thing Name

Details with Hypertext Links: (Thing), |Concept|, !Responsibility!

Borrowed

|Borrowed|, inherits from (Status), references (Customer), keeps !loanDate! and !returnDate!, does !build Next Status! when the (Book) is returned - the returned (Status) is (Available), if no (Reservation) of the Book (Title) is pending, else (Reserved).

Overdue

|Overdue|, inherits from (Status), references (Customer), keeps !loanDate! and !returnDate!, does !build Next Status! when the (Book) finally is returned - the returned (Status) is (Available), if no (Reservation) of the Book (Title) is pending, else (Reserved).

Lost

|Lost|, inherits from (Status), references (Customer), keeps !lostDate!, does !build Next Status! when the (Book) unexpectedly is returned - the returned (Status) is (Available), if no (Reservation) of the Book (Title) is pending, else (Reserved).

Reserved

|Reserved|, inherits from (Status), references (Reservation), inherits from (Book), keeps last (returnDate), does !build Next Status! - the returned Status is (Borrowed) when the Book is checked out, (Reserved) for an other customer or (Available), when the reservation is expired

Available

|Available|, inherits from (Book), keeps !lastReturnDate!, does !build Next Status! (Borrowed) when the Book is checked out

132

VisualAge UML Designer

Table 23. Thing Responsibilities 4

Thing

Responsibility Name

Implementation Name

T/C

Participants

Borrowed

Knows Customer Keeps loan Date Keeps return Date

customer loanDate returnDate

R/1 V/1 V/1

Customer Date Date

Does build next Status Does build Overdue Status

nextStatusWith: overdueStatusWith:

A/A/-

String Date

Knows Customer Keeps loanDate Keeps returnDate

customer loanDate returnDate

R/1 V/1 V/1

Customer Date Date

Does build next Status

nextStatusWith:

A/-

String

Lost

Knows Customer Keeps list Date Does build next Status

customer lostDate nextStatusWith:

R/1 V/1 A/1

Customer Date String

Reserved

Knows Reservation Does build next Status

customer nextStatusWith:

R/1 A/1

Customer String

Available

Keeps last Return Date Does build next Status

lastReturnDate nextStatusWith:

V/1 A/-

Date

Overdue

Step 2: Link New Thing to Its Related Concepts Link the Borrowed thing to its related concept, as described in Appendix A.6, “Create a Link between Model Elements” on page 209. Step 3: Generate the Protocol Generate the protocol for Borrowed, as described in 8.2, “Generating a Protocol Automatically” on page 97. Step 4: Generate the Class Design Generate the Class Design for Borrowed as described in 9.2, “Generating a Class Design” on page 107. Step 5: Create the Other Things up to the Class Design Repeat steps 1 through 4 for the following things:

• • • • •

Borrowed (already done) Overdue Lost Reserved Available

Refined Class Designs (Object Model)

133

Step 6: Make the Class Designs Dependent on their Protocols. Follow the steps described in 9.3, “Making a Class Design Dependent on a Protocol” on page 109 for all of the new Class Designs. Note: Making a class design dependent on a protocol is optional but recommended: You save the step to regenerate the class design after changes have been made to the protocol. Step 7: Let the New Thing Inherit from the Superclass Select Borrowed from the class designs list in the Relationship Browser and Link>Inherits from... from its pop-up menu. Step 8: Capture Inheritance Details Move Status from the Available to the Linked list by using the >> button and select OK. Note: In VisualAge UML Designer class designs can only inherit from one other class design. Therefore the Object class design is removed from the Linked list when you add the Status class design. Step 9: Let Inherit the Other Class Designs Repeat steps 7and 8 for the following class designs: • • • • •

Borrowed (already done) Overdue Lost Reserved Available

Results The individual state class designs are created and inherit the state and behavior, which are all attributes and methods, from the Status class design. Note: The inherited methods do not show up in the list of the methods of a class. VisualAge UML Designer indicates inheritance only by the Inherits From relationship.

12.3 Changing the Protocol of a Class Design At this point you must change the protocol of Status too: Status now hands over the responsibility of changing the states to its subclasses (Available, Reserved, Lost, Overdue , Borrowed). So the nextStatusWith: message

134

VisualAge UML Designer

specification is "self subclassResponsibility" in Smallalk and "abstract" in Java. Other messages have to be added. Changing the protocol of a class design can be achieved in two ways: • Changing the actually linked protocols by adding, changing, or removing responsibilities of the corresponding things and regenerating the protocols, and, where necessary, regenerating the class design too. • Refining the linked protocols by creating new protocols and linking them to the original protocol with the Refines relationship, and, where necessary, regenerate the class design. Note: You can also refine a protocol by overriding message specifications already defined in the more general protocol, according to the rules we describe in 8.1, “The Concept” on page 95. Choose the first way for the protocols with corresponding things that you have already defined, except for Status. Follow the steps in Chapter 7, “Responsibilities and Participants (Collaborators)” on page 77 to complete the thing responsibilities under P=2 in Table 16 on page 90, Table 17 on page 91, and Table 18 on page 92. (Is a lot of work, but less than with the second way.) For the Status protocol choose the second way by following these steps: Prerequisites: 1. You must have created the Status protocol. Step 1: Create a New Protocol Create a new protocol, Status Refined, as described in Appendix A.3, “Create a New Protocol and Add Attributes and Message Specifications” on page 206, but for the moment without adding attribute and message specifications. Step 2: Make It a Refining Protocol Select Link->Refines... from the pop-up menu of the Status Refined protocol in the element list of the Relationship Browser. Step 3: Capture Details Add Status from the Available list to the Linked list by using the >> button and select OK.

Refined Class Designs (Object Model)

135

Step 5: Add Attribute Specifications Add the attribute specifications listed in Table 24 to the Status Refined protocol, as described in Appendix A.3, “Create a New Protocol and Add Attributes and Message Specifications” on page 206. Use Table 24. Refining Attribute Specifications

Specification (in UML Syntax) id : numberOfLoans : book :

Step 5: Add Message Specifications Add the message specifications listed in Table 25 to the StatusRefined protocol, as described in Appendix A.3, “Create a New Protocol and Add Attributes and Message Specifications” on page 206. Table 25. Refining Message Specifications

Specification (in Smalltalk Syntax)

Idiom

id : id: anId :

Getter Setter

numberOfLoans : numberOfLoans: aNumberOfLoans :

Getter Setter

book : book: aBook :

Getter Setter

changeStatusWith: aString :

General Message

Step 6: Assign the Class Design to New Protocol Select Link>Main Protocol... from the pop-up menu of the Status class design in the element list of the Relationship Browser. Step 7: Capture Details Add Status Refined from the Available list to the Linked list by using the >> button and select OK. Results The Status class design now conforms to the refined protocol. Note: An alternative to the tedious work of manually defining a protocol, attribute specifications, and message specifications with all the details is to

136

VisualAge UML Designer

define a Status Refined thing with responsibilities, from which the protocol can be generated automatically.

12.4 Completing the Model In 5.2, “Analyzing Use Cases” on page 44 some things showed up that we decided to leave for to the refinement and extension stages. These things are Category and Category List. Now, it is the time to define the things and the responsibilities and generate the protocols and class designs for these "leftovers." Complete the model with the information in Table 8 on page 53 (things marked with two ** asterisks), and the information in Table 26 (the new things and responsibilities). Table 26. Thing Responsibilities 5

Thing

Responsibility Name

Implementation Name

T/C

Participants

Status File

Keeps stati Does process End of Day Does change Borrowed to Overdue State

stati processEndOfDayWith changeBorrowedToOverdueWith

V/m A/A/-

Status Date Date

Reservation File

Keeps Reservations Does process End of Day Does remove Reservations

reservations process End of DayWith remove ReservationsWith

V/m A/A/-

Reservation Date Date

Title Search Criteria

Keeps title Words Keeps abstract Words Keeps author Names

titleWords abstractWords authorNames

V/m V/m V/m

String String String

Keeps category Word

categoryWords

V/m

String

Keeps firstname Keeps middle initials Keeps lastname

firstname middleInitials lastname

V/1 V/1 V/1

String String String

Keeps street Keeps city Keeps zip

street city zip

V/1 V/1 V/1

String String String

Keeps phone Number, Keeps ssn

phoneNumber, ssn

V/1 V/1

String String

Customer Search Criteria

Notes: T/C=Type/Cardinality, m=many, A=Action, I=Identifier, V=Value, -=no or yet undefined

Note: The Status File and the Reservation File will take over the actual implementation of some of the search responsibilities such as search Books On Loan, from Book File and Title File. Therefore they do not show up in the responsibilities in Table 26.

Refined Class Designs (Object Model)

137

12.5 Creating a Class Diagram of the Refined Class Designs You can either extend an already existing class diagram or create a new one. If you create a new one, you can begin the diagram from scratch or copy the node and link figures from an existing one. We decided to create a new class diagram named Refined Class Designs and copy the figures from the Initial Class Designs Adjusted class diagram. Use Figure 60 on page 139 as a guide to crete your own class diagram, which you call Refined Class Designs. Note: Change the associations and their attributes to match the new designs.

12.6 Setting Types VisualAge UML Designer uses protocols to define parameter types and return types of message specifications. For setting parameter types, see Appendix A.5, “Change a Parameter Type” on page 208. In this section we describe the procedure for setting return types. In our example we want to change the return type of the nextStatusWith: message specification in the Borrowed protocol from to Status Refined. Note: Changing and setting types is the same procedure in VisualAge UML Designer. Prerequisites 1. You have already created message specifications for your protocol. Step 1: Select a Protocol Select Protocols in the relationship list of the Relationship Browser and double-click on the protocol Borrowed in the element list. Step 2: Select a Method Specification Select Messages in the relationship list of the focus browser. Double-click on nextStatusWith:. Step 3: Select a Parameter Select Return Values in the relationship list of the focus browser and then returns in the element list.

138

VisualAge UML Designer

Figure 60. Class Diagram of the Refined Class Designs

Refined Class Designs (Object Model)

139

Step 4: Define the Type of the Return Parameter Select Link>Types... from the pop-up menu in the element list. Step 5: Set New Return Type Move from the Available list to the Linked list and click OK. Step 6: Set All Other Return Types Set or change the return types of all messages in all protocols, using the information in Table 27 on page 140 through Table 30 on page 141. The tables contain the parameter and return types of the action messages only. The parameter types are listed for your convenience and verification. The parameter types of the setter messages and the return types of the getter messages can be derived from the responsibilities. The return parameter type of the setter is standard, that is, self/receiver in Smalltalk and void in Java. Table 27. Message Parameter and Return Types 1

Protocol

Message Name

Param. Types

Return Type

Book File

assignIdTo searchBooksOnLoanWithand searchBooksWithand

Book Title, Customer Title, Customer

@ Book* Book*

assignEntryDate processEndOfDayWith changeExpiredLoansToOverdueWith

Date Date Date

@ Boolean Boolean

Book

changeStatusTo defaultLoanPeriod printBookLabels

String -

Status Refin. Integer Boolean

Status Refined

defaultReturnDate

-

Date

Notes: *=collection of, -=none, @=unspecified (void in Java, self/receiver in Smalltalk)

140

VisualAge UML Designer

Table 28. Message Parameter and Return Types 2

Protocol

Message Name

Parameter Types

Return Type

Title Catalog

assignIdTo searchTitlesWith assignEntryDateTo

Title TitleSearchCriteria -

@ Title* @

defaultLoanPeriod defaultReservationPeriod processEndOfDay

Date

Integer Integer Boolean

removeReservationsWith

Date

Boolean

printBookLabels booksHaveToPrintBookLabels

-

Boolean Boolean

Title

Table 29. Message Parameter and Return Types 3

Protocol

Message Name

Parameter Types

Return Type

Customer File

assignIdTo searchCustomers

Customer CustomerSearchCriteria

@ Customer*

assignMemberSinceTo defaultMaximumNumberOfIt emsOnLoan

Customer -

@ Integer

printLibraryMembershipCard

-

Boolean

Customer

Notes: *=collection of, -=none, @=unspecified (void in Java, self/receiver in Smalltalk) Table 30. Message Parameter and Return Types 4

Protocol

Message Name

Parameter Types

Return Type

Borrowed

nextStatusWith: overdueStatusWith:

String Date

String Date

Overdue

nextStatusWith:

String

Status Refined

Lost

nextStatusWith:

String

Status Refined

Reserved

nextStatusWith:

String

Status Refined

Available

nextStatusWith:

String

Status Refined

Notes: *=collection of, -=none, @=unspecified (void in Java, self/receiver in Smalltalk)

Refined Class Designs (Object Model)

141

Table 31. Messagel Parameter and Return Types 5

Protocol

Message Name

Parameter Types

Return Type

Status File

processEndOfDayWith changeBorrowedToOverdueWith

Date Date

Boolean Boolean

Reservation File

process End of DayWith remove ReservationsWith

Date Date

Boolean Boolean

Notes: *=collection of, -=none, @=unspecified (void in Java, self/receiver in Smalltalk)

Results The return types of all messages in all protocols are set.

142

VisualAge UML Designer

Chapter 13. Extending the Model To get a more advanced search mechanism, we decide that: 1. A title can belong to more than one category. Therefore the Title class gets a new attribute, alternate Categories. 2. The category is no longer a string, but a real object with an id, a keyword (corresponding to the "old" category String), and a text. The class name is Category. 3. The Title attribute primary Category has to be kept, but changed from String type to Category type (because the primary category and the author name identify the physical shelf of a book in the library), referenced by the title attribute. Because the tool does not support association classes directly, we model this m-to-n association by references to the specified classes. For further discussion on the m-to-n association, see 15.5, “Implementing Associations” on page 167. To maintain the different categories we introduce a Category File class. To work with the categories we introduce the Category List. The model extension process will be done in three steps: 1. Define the new class design in the model 2. Integrate the new class design into the model 3. Create a class diagram of the extended model Integration implies changing the existing class designs and adding associations between the new and existing class designs.

13.1 Defining a New Class Design Because you have already run through this process, we provide only a summary of the steps and the information you need to perform the steps. Prerequisites: 1. You have already created a model. Steps: 1. Create and define the things. 2. Link the things to the concepts (where necessary). 3. Define the responsibilities of the things (see Table 32).

© Copyright IBM Corp. 1998

143

Table 32. Thing Responsibilities 6

Thing

Responsibility Name

Implementation Name

T/C

Participants

Category File

Keeps categories Does assign Category ID Keeps Category List

categories assignIdTo categoryList

V/m A/V/1

Category Title CategoryList

Category

Identifies by ID Keeps keyword Keeps text

id keyword text

I/1 V/1 V/1

String String String

Category List

Keeps categories Does search Categories

categories searchCategoriesWith

V/m A/

Category String

Notes: T/C=Type/Cardinality, m=many, A=Action, I=Identifier, V=Value, -=no or yet undefined

4. 5. 6. 7. 8.

Create the protocols from the things. Generate the class designs from the protocols (where required). Link other protocols to the class design (where required). Make the class design dependent on protocols (where required). Define the parameter and return types of the messages (see Table 33).

Table 33. Message Parameter and Return Types 6

Protocol

Message Name

Parameter Types

Return Type

Category File

assignIdTo

Title

@

Category List

searchCategoriesWith

String

Category*

Notes: *=collection of, -=none, @=unspecified (void in Java, self/receiver in Smalltalk)

Results The new class designs have been created.

13.2 Integrating a New Class Design The extension of the model affects only one class design, the Title class design. The extension of the class design with the alternate Categories could be covered by a smooth and elegant protocol refinement, but the existing category needs a change in attribute type and kind of responsibility or complete replacement with for, example, the primary Category. A change of just the types in the message specifications would be a violation of the

144

VisualAge UML Designer

model consistency, except the changes would be reverse engineered back to the thing responsibilities. For clarification reasons we decided to go with the complete replacement and do the forward engineering from the thing responsibility up to the class design and types. Once again we supply you with a summary of the steps and the information you need to perform the steps. Prerequisites: 1. You have already created a model. Steps: 1. Remove the category responsibility from the Title thing. 2. Define the primary Category responsibility (see Table 34). 3. Define the alternate Category responsibility (see Table 34). Table 34. Thing Responsibilities 7

Thing

Responsibility Name

Implementation Name

T/C

Participants

Title

Knows Primary Category Knows Alternate Categories

primaryCategory alternateCategories

R/m R/m

Category Category

Notes: T/C=Type/Cardinality, m=many, A=Action, I=Identifier, V=Value, -=no or yet undefined

4. Create the Title protocol. 5. Create the Title class design (only, if not dependent on the Title protocol). 6. Create the associations between the new and the existing class designs (postpone it to 13.3, “Creating a Class Diagram of the Extended Model” on page 146). 7. Define the parameter and return types of the messages (see Table 35). Table 35. Message Parameter and Return Types 7

Protocol

Message Name

Parameter Types

Return Type

Title

primaryCategory primaryCategory:

Category

Category @

secondaryCategories addSecondaryCategory: removeSecondaryCategory:

Category Category

Category* @@ @@

Notes: *=collection of, -=none, @=unspecified (void in Java, self/receiver in Smalltalk), @@=for Smalltalk: the same as the parameter type; for Java: unspecified (void)

Extending the Model

145

8. Think about adjusting the dependent things, such as real classes and their methods (selective generation of the methods, removing attributes and methods, changing methods,...), if any

13.3 Creating a Class Diagram of the Extended Model You can either extend an already existing class diagram or create a new one. If you create a new one, you can begin the diagram from scratch or copy the node and link figures from an existing one. We decided to create a new class diagram named Extended Model and copy the figures from the one named Refined Class Designs. Use Figure 61 as a guide to crete your own class diagram, which you call Extended Model.

146

VisualAge UML Designer

Figure 61. Class Diagram of the Extended Model

Extending the Model

147

148

VisualAge UML Designer

Chapter 14. Publishing VisualAge UML Designer can generate formatted output based on the contents of your model, including diagrams. You can select the scope of the publication: • The whole model • A subset of the model • A single model element As output format you can choose: • HTML (HyperText Markup Language) • RTF (Rich Text Format) Publishing in HTML on an intranet or Internet server provides: 1. Immediate availability through the intranet or Internet 2. Easy accessibility for the project members spread throughout the company 3. Easier "distribution" of the actual version 4. Usability with standard browsers (no special software needed) 5. Support to use the hypertext links created during the modeling process Publishing in RTF allows the embedding of or into other documents through document or word processors. You can store the model element selections and publishing parameters in Group and Publication model elements for selective, easy, and fast republishing after changes.

14.1 Creating a Publication of a Model or Model Element Prerequisites 1. You must have created a model. 2. You must have saved the diagrams as gif files. 3. Make diagram hypertext text links to embed the diagrams (see Figure 62). Step 1: Select the Model or Model Element Select the model in the source list of the Relationship Browser.

© Copyright IBM Corp. 1998

149

Figure 62. Model Element Description with Embedded Diagram Hypertext Link.

Step 2: Create the Publication From the source pop-up menu select Publish, either With Children or Single. Step 3: Capture the Publication Details 1. Select the drive and path with the [...] button (P:\Aaa\xxx). 2. Change the output file name (ALibraryModel.htm). 3. Select the output format (HTML). 4. Select the model element groups (Everything). 5. Checkmark (optional) the publication model element creation. 6. Clock on OK. Step 4: Complete the Publication Copy the beforehand created gif files into the same directory, in which you copy the output published by VisualAge UML Designer. All references are made relative to the start file you named in the publishing options (Figure 63). VisualAge UML Designer uses the same name with suffixes to build the output files. Results The model or a part of it is published either on-line ore as hardcopy. The figures on the following pages contain extracts of the library model published in HTML format with VisualAge UML Designer.

150

VisualAge UML Designer

Figure 63. Publishing Options

Figure 64. Output Sample of Input displayed in Figure 62 on page 150

Publishing

151

Figure 65. Publication Cover Sample

152

VisualAge UML Designer

Figure 66. Published Use Case with Hypertext Links

Note about an extension for HTML: 7. Capability to embed through referencing any type of on-line document, even external ones, which your browser can display or has a plug in order to display (using a small change to the system

Smalltalk snippet to enable URLs in text to show up as active links in HTML publication. You execute this on your own risk...

SgmlHtmlWriter specialCharacterConversions removeKey: $)use case in motion, or receiving the output from a use case.

Adornment. An adornment is a remark or description label of a model element.

Aggregation. Aggregation is a special form of (-->)association, that specifies an including relationship of a model element.

Artifact. An artifact is a piece of information that represents the result of a software development step. In this book we use this term as a synonym for a model element or (-->)relationship.

Association. An association is a model element representing a relationship of two other model elements.

Attribute. An attribute is a piece of a class or its instance that holds a value.

Bean. A bean is a Java standard definition to describe the (-->)interface of a (-->)class.

Class. A class is a definition of a set of (-->)objects that join the same behavior, which includes (-->)attributes and (-->)methods.

Class class. A class class is the Smalltalk synonym for (-->)class.

Class design. A class design is a VisualAge Smalltalk UML Designer specific model element

© Copyright IBM Corp. 1998

that combines information of an implementation (-->)class and model definitions.

Class diagram. A class diagram is a graphical representation of classes and their static (-->)relationships.

Class instance. A class instance is the Smalltalk synonym for an (-->)instance of a (-->)class.

Class variable. A class variable is an (-->)attribute belonging to the class and therefore is shared by all (-->)instances of that class.

Collaborator. A collaborator is an element that is involved in the definition of a (-->)responsibility.

Collaboration diagram. A collaboration diagram is a special kind of (-->)interaction diagram focusing on the (-->)relationships between the (-->)objects.

Component. A component is a physical or logical subpart of the (-->)model, identifying elements that belong to the same problem domain.

Component diagram. A component diagram is a graphical representation of (-->)components and their dependencies.

Composition. A composition is a special form of (-->)aggregation, which accordingly defines the life cycle of a model element. The composite part dies with its parent.

227

Concept. A concept is a model element representing a significant term or idea that is not necessarily qualified as an (-->)actor or a (-->)thing.

Constraint. A constraint is an extending condition or restriction of a model element.

Edition. An edition is a working copy (open edition) of a (-->)version of a model element or a new created one in the (-->)ENVY library.

ENVY. ENVY is the library management and version control system. Exception. An exception is a event indicating a special situation inside the application.

Figure. A figure is a graphical model element representing a nongraphical counterpart.

Instance variable. An instance variable is a attribute belonging to the (-->)instance of a (-->)class. Every instance can store its own value in an instance variable without affecting other instances of the same class.

Interaction diagram. An interaction diagram is a graphical representation of the interactions of (-->)objects. Interaction diagram is a collective term for all kind of diagrams that shows interactions between objects.

Interface. An interface is a definition of a specific behavior. Unlike a (-->)class an interface does not include implementation.

Link. A link in VisualAge Smalltalk UML Designer represents a binding to another model element. Unlike an (-->)association a link is the mechanism to implement the binding rather than being a model element.

Group. A group is a model element indicating a common topic for a set of other model element.

Hypertext link. A hypertext link is an animated text in a document. By double clicking on it leads you to another information even outside the document itself.

Image. An image is a local subset of the (-->)ENVY library keeping only the applications and classes you need and only one specified edition of each at the same time.

Message. A message is a piece of communication that invokes (-->)method.

Metaclass. A metaclass is (-->)class whose (-->)instances are classes.

Method. A method is the implementation of an operation and expresses a part of functionality.

Inheritance. Inheritance is the object-oriented concept of reusing already defined behavior of other objects.

Methodology. A methodology is a predefined path through special tasks combined with a definition of artifacts. In object-oriented application development a methodology leads you to your final object model.

Instance. An instance is a "living" entity of a (-->)class that can store data and behaves in the way defined by its class.

Model. A model is a collection of related design elements; these elements can include (-->)requirements, (-->)use cases,

228

VisualAge Smalltalk UML Designer

(-->)objects, diagrams, and other artifacts of design.

Model Element. (-->) artifact object. An object is an entity with identity, state and behavior, mostly associated with an (-->)instance.

Parameter. A parameter is a specification for a changeable variable and is used for holding additional information.

Participant. A participant is an (-->)object involved in a definition. In VisualAge Smalltalk UML Designer used as a synonym for (-->)collaborator.

Protocol. A protocol is a model element representing an (-->)interface. A protocol defines a type rather than a (-->)class. Relationship. A relationship is a connection between model elements. In VisualAge Smalltalk UML Designer the model elements themselves are also called relationships.

State transition diagram. A state transition diagram is a graphical description of status changes of an (-->)object during a special scenario.

Stereotype. A stereotype is a metaclassification defining according semantics to your model elements.

Thing. A thing is a candidate to become an (-->)object in the eventual implementation.

Use case. A use case is a sequence of actions that a system performs in interaction with a user during a specified scenario.

Use case diagram. A use case diagram is a graphical representations of a (-->)use case.

Version. A version is a committed copy (closed edition) of a model element in the (-->)ENVY library.

Repository. A repository is an (-->)ENVY library, keeping track of all (-->)editions and (-->)versions of all model elements, Smalltalk applications, and classes.

Responsibility. A responsibility is a duty assigned to a (-->)thing in order to fulfill a (-->)requirement or implement a (-->)use case.

Requirement. A requirement is a task the system should be able to perform.

Sequence diagram. A sequence diagram is a special kind of (-->)interaction diagram showing the interactions between (-->)objects in a time dependent manner.

229

230

VisualAge Smalltalk UML Designer

List of Abbreviations AD

application development

CRC Cards

Class Responsibility and Collaborator Cards

IBM

International Business Machines Corporation

HTML

Hypertext Markup Language

ITSO

International Technical Support Organization

OOA

Object Oriented Analysis

OOAD

Object Oriented Analysis and Design

OOD

Object Oriented Design

RTF

Rich Text Format

UML

Unified Modeling Language

VA

VisualAge

© Copyright IBM Corp. 1998

231

232

Java Clients for VisualAge Generator Servers

Index A abstraction 175 class 49 action participant 85 responsibility 77, 83 activation bar sequence diagram 124 actor 44 case study 48 create 45 description 47 hypertext link 45 identify 44 requirement 15 use case 44, 45 add to collection 78 adornment diagram 118 aggregation keep 78 relationship 78 responsibility 78 align figure 113 analysis 17 class design 106 iteration 60 phase 17 requirement 29 result 21 task 17 use case 44, 60 analyze efficiency 80 iterate 80 setup 82 use case 44, 60 animate model 19 application default 180 generation 180 load 200 model 31

© Copyright IBM Corp. 1998

name 31 architecture 199 art 203 assign responsibility 77, 83 association 167 adornment 118 class 116 class diagram 120 create 116 encapsulation 168 negotiation 170 protocol 98 assumption 25 attach element 19 figure 70, 71, 113 model 68, 70, 71 attribute association 168 constraint 208 create 207 attribute specification case study 136 protocol 136

B Banana Split 159 behavior class 49 class design 105 instance 49 protocol 95 sequence diagram 125 browse edition 8 focus 5, 85 hierarchy 7 hypertext link 4, 83 link 77 model 4 path 6 reference 80 relationship 4 tree 7 used by 44, 77, 80, 83 version 8

233

browser setting 102 split orientation 102 text summary 102 business 25 case study 25 model 158

C cardinality responsibility 78 case study 21 actor 48 assumption 25 attribute specification 136 class diagram 120, 146 concept 55 design pattern 24 extension 146 interaction 22 library management system 21 message specification 136 model 23 requirement 22, 35 responsibility 90, 133, 137, 144 satisfied requirement 43 sequence diagram 128 system diagram 73 thing 51, 132 type 140 use case 39, 61, 62 use case diagram 74 category retrieve 193 change color 213 coupling 13 font 213 propagate 13 protocol 109, 134 relationship browser 5 type 208 check consistency 19 class 105 abstraction 49 association 116 behavior 49

234

VisualAge Smalltalk UML Designer

class design 191 create 182, 185 diagram 10 document 191 figure 112 generate 182, 187 inheritance 182 instance 121 integrate 189 map 197 merge 191 meta level 49 method 105 name 105 protocol 95, 105, 191 redesign 131 refine 138 service 165 Smalltalk 179 thing 49 transform 183, 187 class design 105 bridge analysis-implementation 106 class 191 create 191, 192 dependent 109 design 17 detail 107, 192, 196 extension 143 generate 107 guideline 13 inheritance 131 integrate 144 link 136 map 197 meta class 105 model 105 name 105 protocol 134 real class 105, 106 refine 131, 138 retrieve 191, 195 transform 107, 183, 187 view 111 class diagram 17, 111 association 120 case study 120, 146 create 111 design 17

detail 111 extension 146 instance method call 126 multiplicity 120 refine 138 role 120 class diagrammer 10 class list sequence diagram 125 class method call sequence diagram 126, 129 Class Responsibility Collaborator Card see CRC Card coarse grain responsibility 92 code generate 19 integrate 14, 191 Java 185 Smalltalk 179 transform 19 collaborator 77 requirement collapse hierarchy 7 collection responsibility 78 color change 213 figure 213 concept 54 case study 55 create 55 idea 54 identify 54 protocol 95 requirement 15 terminology 55 use case 44 configure 186 generate 180, 186 Java 186 Smalltalk 180 conform protocol 96, 164 consistency model 19, 144, 212 constraint attribute 208

link 208 controller subsystem 162 copy display option 119 coupling change 13 CRC participant 77 responsibility 77 CRC Card requirement 16 create actor 45 association 116 attribute 207 class design 191, 192 class diagram 111 class, real... 182, 185 concept 55 element 206 extends use case 58 extension 143 hypertext link 50, 205 message 207 model 30, 206 protocol 97, 135, 194, 206 publication 149 relationship browser 5, 30 requirement 34 responsibility 84, 87 sequence diagram 121 stereotype 177 tool 69 use case diagram 67 used use case 58 while linking 50, 59 cycle modeling 14

D decoupling implementation 105 define requirement 32 use case 38 delete element 19, 210

235

figure 210 link 211 relationship 211 depends on relationship 110 describe use case 37, 38 description actor 47 hypertext link 4 natural-language 4 design phase 17 refine 131 result 21 design pattern 24 detail class design 107, 192, 196 class diagram 111 figure 70 generate 98, 183, 188 link 59, 60, 110 model 31 protocol 194, 196 requirement 34 responsibility 84 sequence diagram 122 use case 38 development increment 202 iterate 202 team 199 diagram adornment 118 class 10 edit 118 element 19 interaction 11, 121 model 9 multiplicity 118 sequence 11, 121 use case 9, 67 display option 113, 119 display option copy 119 distinguish protocol 165 document

236

VisualAge Smalltalk UML Designer

class 191 domain concept 55 dynamic test 19

E edit diagram 118 figure 113 edition browse 8 load 8 version 8 edition browser 8 efficiency analyze 80 thoroughness 81 element create 206 delete 19, 210 diagram 19 link 209 name 102, 211 relationship 209 rename 102, 211 encapsulation violation 168 exception analysis 17 expand hierarchy 7 extends use case 57 create 58 extension case study 146 class design 143 class diagram 146 create 143 integrate 143 model 143 modeling 157 process 143

F features UML Designer 3 figure

align 113 attach 68, 71, 113 model attach 70 class 112 color 213 delete 210 detail 70 edit 113 filter 115 font 213 format 113 group 68 link 67 method call 125 model 68, 70, 71, 113 node 67 object 123 property 113 tool 112 use case 67, 71 file generate 185 Java 185 filter figure 115 focus browse 5 focus browser 5 font change 213 figure 213 format figure 113 publishing 149 framework implementation 19 fuzziness responsibility 79

G generalize subsystem 161 generate class design 107 class, real... 182, 187 code 19, 179 configure 180, 186

detail 98, 183, 188 file 185 message 97, 117 names 182 protocol 97, 117 setting 186 transform 13 generation application 180 setting 180 getter 208 group figure 68 group figure use case diagram 68 groups analysis 17 guideline class design 13 work 13

H hide label 118 link 67, 71 relationship 71 hierarchy browse 7 collapse 7 expand 7 hierarchy browser 7, 103 history 171 HTML publishing 11, 149 hybrid subsystem 202 hypertext link actor 45 browse 4, 83 create 50, 205 description 4 identifying 78 insert 50 publishing 149 reference 50 responsibility 81, 88 Hypertext Markup Language see HTML

237

I idea concept 54 identify 77 actor 44 concept 54 participant 77, 85 requirement 32 responsibility 77, 83 subsystem 160 thing 49 use case 37, 57 identifying hypertext link 78 idiom link 207 responsibility 77 implementation class design 106 coupling model 13 decoupling model 13 framework 19 Java 19 name 84 persistence 19 phase 19 protocol 95 task 19 transaction 19 implementation decoupling 105 inconsistency model 200, 212 increment development 202 protocol multiple inheritance 95 inheritance class design 131 class, real ... 182 superclass 134 insert hypertext link 50 install 215 instance behavior 49 class 121 method 105 protocol 105 instance method call

238

VisualAge Smalltalk UML Designer

class diagram 126 instantiation 121 integrate class 189 class design 144 code 14, 191 extension 143 Java 189 interaction 22 diagram 11, 121 interaction diagram 121 interface protocol 96 iterate analyze 80 development 202 development

iterate repository iteration analysis 60

J Java 185, 186 Bean 95 BeanInfo 95 class design 105 code 185 file 185 implementation 19 integrate 189 interface 95 protocol 95

K keep aggregation 78

L label hide 118 show 118 launch relationship browser 5 layers 176 level abstraction 175

199

path 6 library management system 21 case study 21 limitation 217 link browse 77 class design 136 constraint 208 create while ... 50 create while... 59 delete 211 detail 59, 60, 110 element 209 extends use case 58, 59 figure 67 hide 67, 71 idiom 207 participant 88 protocol 110, 136 refine 135 requirement to use case 40 satisfied requirement 41 show 67, 71 traceability 40 use case 58 use case to requirement 40 used use case 59 load application 200 edition 8 model 200

M main protocol 136 make consistent 212 management model 200 map class 197 class design 197 protocol 197 merge class 191 protocol 165 message create 207 generate 97, 117 protocol 98

message list sequence diagram 125 message specification case study 136 protocol 136 meta class class design 105 meta level class 49 method class 105 implemented 106 instance 105 not implemented 106 specified 106 unspecified 106 method call behavior 125 figure 125 sequence diagram 124 methodology 14 metrics 203 model 23 animate 19 application 31 attach 68, 71 browse 4 business 25, 158 case study 23 class design 105 consistency 19, 212 coupling implementation 13 create 30, 206 decoupling implementation 13 detail 31 diagram 9 extension 143 figure 68, 70, 71, 113 inconsistency 200, 212 management 200 modeling 13 name 31 namespace 31 new 30 prerequisite 29 prerequisites 162 publishing 149 reverse engineering 144 share 202

239

Smalltalk 200 specification 31 split 160 syntax 207 test 19 verify 19 version 202 view 9 walkthrough 19 model consistency 144 modeling alternative 157 backward 14, 191 cycle 14 extension 157 forward 14 model 13 phase 14 reverse 191 start 29 style 13 subsystem 159 task 14 UML Designer 4 multiplicity class diagram 120 diagram 118

N name application 31 class 105 class design 105 element 102, 211 implementation 84 model 31 responsibility 84 names generate 182 namespace model 31 prefix 31 natural-language description 4 node figure 67

240

VisualAge Smalltalk UML Designer

O object figure 123 object cluster pattern 159 object model 105 ObjectExtender VisualAge 19 option display 113, 119 organization team 200 output publishing 149

P parameter type 138, 208 participant 77 action 85 CRC 77 identify 85 link 88 requirement thing 77 value 85 path browse 6 level 6 work 13 path browser 6, 101, 208 pattern cluster pattern 159 pattern thing 54 persistence implementation 19 phase analysis 17 design 17 implementation 19 modeling 14 requirement 15 task 14 pool subsystem 161 prefix namespace 31

prerequisite model 29 subsystem 201 prerequisites model 162 process extension 143 programming language 181 propagate change 13 property figure 113 protocol 17, 95 association 98 attribute specification 136 behavior 95 change 109, 134 class 95, 105, 191 class design 134 concept 95 conform 96, 164 create 97, 135, 194, 206 dependent 110 design 17 detail 194, 196 distinguish 165 generate 97, 117 implementation 95 inheritance 95 instance 105 interface 96 Java 95 link 110, 136 main 109, 136 map 197 merge 165 message 98 message specification 136 negotiation 170 refine 96, 135 responsibility 95 retrieve 191, 195 sequence diagram 125 service 165 Smalltalk 95 stereotype 162 substitutability 96 subsystem 162 thing 95

transform 96 type 107 typing 95 proxy subsystem 202 publication create 149 element 149 publishing 11, 149 HTML 11 model 149 partial 149 publication 149 RTF 11

R real class class design 105, 106 design 17 receiver message 124 redesign class 131 reference browse 77, 80 hypertext link 50 responsibility 77, 87 refine class 138 class design 131, 138 class diagram 138 design 131 link 135 protocol 96, 135 relationship aggregation 78 browse 4 delete 211 depends on 110 element 209 hidden 71 hide 71 requirement 33 show 71 use case 38 Relationship Browser 30 relationship browser 4 create 30

241

remove from collection 78 rename element 102, 211 requirement 22, 29 analysis 29 case study 35 create 34 define 32 detail 34 elements 15 identify 32 link to use case 40 phase 15 relationship 33 requirement 15 satisfy requirement 41 requirements analysis 29 responsibility 77 aggregation 78 all at once 89 assign 77 cardinality 78 case study 90, 133, 137, 144 coarse grain 92 collection 78 CRC 77 create 84, 87 detail 84 fuzziness 79 hypertext link 81, 88 identify 77 idiom 77 name 84 protocol 95 reference 87 requirement 16 system 79 type 77, 144 result 21 retrieve category 193 class design 191, 195 protocol 191, 195 thing 198 transform 13, 196, 198 return type 138, 208

242

VisualAge Smalltalk UML Designer

reverse engineering 14, 144, 191 Rich Text Format see RTF role class diagram 120 RTF publishing 11, 149

S Samlltalk implementation 19 scenario verify 19 sender method 124 sequence diagram 11, 121 sequence diagram activation bar 124 case study 128 class method call 126, 129 create 121 design 17 detail 122 method call 124 sequence diagrammer 11 service class 165 protocol 165 setter 208 setting browser 102 generate 186 setup analyze 82 share model 202 show label 118 link 67, 71 relationship 71 Smalltalk architecture 199 class 179 class design 105 code 179 configure 180 generate 179

model 200 protocol 95 syntax 207 specification model 31 split model 160 start modeling 29 state class design 105 static check 19 stereotype 162 create 177 protocol 162 requirement 15 style modeling 13 substitutability protocol 96 subsystem controller 162 domain 162 generalize 161 hybrid 202 identify 160 modeling 159 pattern 159 pool 161 prerequisite 201 protocol 162 proxy 202 specific 162 team 200 used 161 subsystem-use case-object cluster 159 superclass inheritance 134 syntax model 207 Smalltalk 207 UML 207 System Transcript 30 system 17, 79 requirement 15 responsibility 79 system diagram

case study 73 System Transcript UML Designer 30

T task analysis 17 implementation 19 modeling 14 phase 14 team development 199 organization 200 subsystem 200 term concept 55 terminology concept 55 test model 19 text summary 102 thing assign responsibility 83 case study 51, 132 class 49 class aspect 49 identify 49 instance aspect 49 participant 77 pattern thing 54 protocol 95 requirement 15 retrieve 198 use case 44, 49 thoroughness efficiency 81 tool create 69 figure 112 use case diagram 69 traceability link 40 transaction implementation 19 transform class 187 class design 107, 183, 187

243

class, real... 183 code 19 generate 13 protocol 96 responsibility 97, 117 retrieve 13, 196, 198 tree browse 7 view 7 type case study 140 change 208 parameter 138, 208 protocol 107 responsibility 77, 144 return 138, 208 typing protocol 95

U UML syntax 207 UML Designer features 3 modeling 4 System Transcript 30 VisualAge 3 unload model 200 use case 37 actor 44, 45 analysis 44, 60 analyze 44, 60 case study 39, 61, 62 define 38 describe 38 detail 38 diagram 9, 67 extends 44, 57 figure 67, 71 identify 37, 57 link to requirement 40 pattern 159 relationship 38 requirement 15 thing 49 use case 44 used 44, 57

244

VisualAge Smalltalk UML Designer

user 37 use case diagram 67 case study 74 create 67 group figure 68 requirement 15 tool 69 use case diagrammer 9 used subsystem 161 used use case 57 create 58 user use case 37

V value participant 85 responsibility 77, 83 variables class design 105 version application application version 200 browse 8 edition 8 model 202 view class design 111 graphical 9 model 9 static 10 tree 7 VisualAge ObjectExtender 19 UML Designer 3

W walkthrough model 19 work guideline 13 path 13

ITSO Redbook Evaluation VisualAge Smalltalk UML Designer SG24-4997-00 Your feedback is very important to help us maintain the quality of ITSO redbooks. Please complete this questionnaire and return it using one of the following methods: • Use the online evaluation form found at http://www.redbooks.ibm.com • Fax this form to: USA International Access Code + 1 914 432 8264 • Send your comments in an Internet note to [email protected] Which of the following best describes you? _ Customer _ Business Partner _ Solution Developer _ None of the above

_ IBM employee

Please rate your overall satisfaction with this book using the scale: (1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor) Overall Satisfaction

__________

Please answer the following questions: Was this redbook published in time for your needs?

Yes___ No___

If no, please explain:

What other redbooks would you like to see published?

Comments/Suggestions:

© Copyright IBM Corp. 1998

(THANK YOU FOR YOUR FEEDBACK!)

245

SG24-4997-00 Printed in the U.S.A.

VisualAge Smalltalk UML Designer

SG24-4997-00