UML and Object Oriented Modeling

UML and Object Oriented Modeling

JiHsian Lee

Web:http://202.201.18.40:8080/mas5/labs/home.jsp?id=7 The School of Mathematics, Physics and Software Engineering Lanzhou Jiaotong University July 19, 2006

2

Contents 1 Fundamentals of OOM

7

1.1

Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

1.2

Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

1.3

Model Organization . . . . . . . . . . . . . . . . . . . . . . . .

8

1.4

Structured Analysis . . . . . . . . . . . . . . . . . . . . . . . .

9

1.5

Object Orientation . . . . . . . . . . . . . . . . . . . . . . . . 10

1.6

Encapsulation of Hardware . . . . . . . . . . . . . . . . . . . . 12

1.7

Encapsulation of Software . . . . . . . . . . . . . . . . . . . . 12

1.8

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.9

Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 UML - Part 1

19

2.1

UML - What It Is . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2

Why Use UML? . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3

How UML Started . . . . . . . . . . . . . . . . . . . . . . . . 24

2.4

UML Diagram Types . . . . . . . . . . . . . . . . . . . . . . . 24

2.5

Business Modelling, Web Applications, and extending UML . 26

2.6

Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . 27

2.7

Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.7.1

Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3

4

CONTENTS 2.7.2

Relationships . . . . . . . . . . . . . . . . . . . . . . . 36

2.8

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.9

Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3 UML - Part 2

45

3.1

Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2

Collaboration Diagram . . . . . . . . . . . . . . . . . . . . . . 47

3.3

Statechart Diagram . . . . . . . . . . . . . . . . . . . . . . . . 50

3.4

Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.5

Component Diagram . . . . . . . . . . . . . . . . . . . . . . . 53

3.6

Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . 53

3.7

Modelling Architecture . . . . . . . . . . . . . . . . . . . . . . 56

3.8

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.9

Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4 The Software Development Process

61

4.1

Business Process Modelling . . . . . . . . . . . . . . . . . . . 61

4.2

System Requirements Definition . . . . . . . . . . . . . . . . . 62

4.3

The System Analysis Model . . . . . . . . . . . . . . . . . . . 63

4.4

System Model Information Flow . . . . . . . . . . . . . . . . . 63

4.5

The System Design Model . . . . . . . . . . . . . . . . . . . . 64

4.6

Overall Process Flow . . . . . . . . . . . . . . . . . . . . . . . 65

4.7

Incremental Development

4.8

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.9

Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

A Answers

. . . . . . . . . . . . . . . . . . . . 66

71

CONTENTS B CRC

5 73

B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 B.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 B.3 Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 B.4 CRC Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 B.5 Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 B.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6

CONTENTS

Chapter 1 Fundamentals of OOM This chapter explains the principles behind modeling and abstraction and shows how they can be applied to object oriented models and systems.

1.1

Abstraction

Abstraction is a fundamental principle of modeling. A system model is created at different levels, starting at the higher levels and adding more levels with more detail as more is understood about the system. When complete, the model can be viewed at several levels. So abstraction is about: • Looking only at the information that is relevant at the time • Hiding details so as not to confuse the bigger picture

1.2

Modeling

When we model, we create a number of views of the system being described, usually 2 or 3. For a complete description 3 are normally needed. Each 7

8

CHAPTER 1. FUNDAMENTALS OF OOM

Figure 1.1: Orthogonal View of a Plane

view is an “orthogonal” view, see Figure. 1.1. Each view is needed for a full understanding of the system. Views are orthogonal when: • Each view has information that is unique to that view • Each view has information that appears in other views • The information that is common between views is consistent(一致的, 相容的)

1.3

Model Organization

All model syntaxes(语法, 句法) provide a number of model elements which can appear on one or more diagram types. The model elements are contained within a central model, together with all their properties and connections to other model elements. The diagrams are independent views of the model just as a number of computer screens looking into different records or parts of a database shows different views. See Figure. 1.2.

1.4. STRUCTURED ANALYSIS

9

Figure 1.2: Model Diagram

1.4

Structured Analysis

In structured analysis there are three orthogonal views, Figure. 1.3: • The functional view, made up of data flow diagrams(DFD), is the primary view of the system. It defines what is done, the flow of data between things that are done and provides the primary structure of the solution. Changes in functionality result in changes in the software structure. • The data view, made up of entity relationship diagrams(ERD), is a record of what is in the system, or what is outside the system that is being monitored. It is the static structural view. • The dynamic view, made up of state transition diagrams(STD), defines when things happen and the conditions under which they happen. Traditional Structured Analysis and Design methods tend to fall short of(缺乏, 达不到) the goal of producing software that is easy to maintain and extend over a long period. They are able to produce a hierarchically

10

CHAPTER 1. FUNDAMENTALS OF OOM

Figure 1.3: Orthogonal Views in Structured Analysis

structured model that satisfies a static requirement. The model is, to a trained analyst, clear and easy to understand and, to a large degree, reasonable traceable. What structured analysis is not good at is adapting models to the continuously changing requirements that are the characteristic of modern businesses.

1.5

Object Orientation

Object Oriented software is based on the static, or object model — the things in the system, or, the things outside the system about which we need to record information, and their relationships. This is the most stable view in the system. It is why an object oriented model produces more stable software over a long period. See Figure. 1.4 • Functionality from the interaction model is mapped onto the object model.

1.5. OBJECT ORIENTATION

11

Figure 1.4: Orthogonal Views in Object-Oriented Analysis

• The interaction model is, in turn, derived from the Use Case model which defines the functionality of the system from a user’s perspective. • The dynamic model defines the order and conditions under which things are done and is also mapped onto the object model. The object model is usually less affected by the changes to functional requirements that characterize most of the evolutionary process of the software. The things that are part of the problem and the way in which they are related tend to remain the same. It is what we want to do with them — the functional model — that changes the most. If, therefore, we model the structure of the problem and the structure of the resulting software solution around the object model instead of around the functional model, then we will produce systems that are more resilient to change over a period of time. This is what object orientation does and is the primary reason why object oriented software is more maintainable, re-useable and extensible than traditional structured software, especially over a long period. In addition, the flexibility and resultant portability of an object-oriented solution, tends to result in software that is inherently scalable. The encap-

12

CHAPTER 1. FUNDAMENTALS OF OOM

sulation of objects lends itself to redistribution across distributed platforms once the functionality of the application has been proved as a single machine solution.

1.6

Encapsulation of Hardware

The concept of encapsulation of data and functionality that belongs together is something which the hardware industry has been doing for a long time. Hardware engineers have been creating re-useable, re-configurable hardware at each level of abstraction since the early sixties in the last century. Elementary boolean functions are encapsulated together with bits and bytes of data in registers on chips. Chips are encapsulated together on circuit boards. Circuit boards are made to work together in various system boxes that make up the computer, as shown in Figure. 1.5. Computer are made to work together across networks. Hardware design, therefore is totally object oriented at every level and is, as a result, maximally re-useable, extensible and maintainable. In a single word: flexible. Applying object-orientation to software, therefore, could be seen as putting the engineering into software design that has existed in hardware design for many years. • Hardware encapsulates data and function at every level of abstraction • Maximizes maintainability, reuse and extension

1.7

Encapsulation of Software

In well developed object oriented software, functionality and data is encapsulated in objects. Objects are encapsulated in components. Components

1.7. ENCAPSULATION OF SOFTWARE

13

Figure 1.5: Encapsulation of Hardware

Figure 1.6: Encapsulation of Software

are encapsulated into systems. See Figure. 1.6. If this is done well the result is: • Maximal coherence(一致) • Minimal interconnection • Solid interface definitions Maximum maintainability, reuse and extensibility Encapsulation of primitive functions, together with the data upon which they act and to which they belong, is fundamental to object orientation. The trick is to get the right functionality encapsulated with the right data.

14

CHAPTER 1. FUNDAMENTALS OF OOM

If this is achieved, then, the network of objects, which collaborate to provide the required functionality of the software, will have the minimum possible essential connections between objects and maximum functional cohesion of the objects. From this maximal functional cohesion(结合, 凝聚, 内聚力) can be derived maximal maintainability, reuse and extension. To achieve this we need two things. Firstly, the right objects. Secondly, to set the interface to the objects in concrete. If a change to an object requires a change to the interface to the object, then the effect of that change will escape beyond the boundaries of the object and propagate around the network. This is to allow the whole reason for encapsulation to be negated(否定, 打消) in one go. Proper Analysis and Design defines the right objects for the system and their interfaces to the point where each object can be given to a programmer and coded independently of any other object in the system. If this is done well then the resulting objects will still be around in future versions of the software, and, furthermore, their interfaces will not have changed except for additions. We aim for maximum maintainability, re-use and extension.

1.8

Summary

• Abstraction is about looking only at the information that is relevant at the time. • When modelling 2 or 3 orthogonal views of the system are created. • Diagrams are independent views of the model and may be of different types. • In structured analysis the functional view is the primary view of the system.

1.9. QUIZ

15

• In object oriented analysis, the object model, or data view, is the primary, and most stable view of the system. • Hardware engineering produces well encapsulated hardware designs • Applying encapsulation techniques to software encourages maintainable, re-useable and extensible code.

1.9

Quiz

1. Abstraction is about (a) Looking at things in detail (b) Looking at relevant information only (c) Focusing on one detailed point 2. Hiding details is a good idea because (a) There is no need to worry about them as they are unnecessary (b) Details are not important (c) It stops you worrying about them when they are not important 3. In a model made up of multiple views (a) Each view is a transformation of another view (b) Views contain unique information (c) Common information must be consistent (d) 3b and 3c are true (e) None of the above

16

CHAPTER 1. FUNDAMENTALS OF OOM 4. Model elements (a) appear on one diagram only (b) are distributed amongst the diagrams of the model (c) can appear on multiple diagrams of the same or different types (d) can appear on multiple diagrams of different types only (e) 4a and 4b are true 5. In structured analysis (a) The functional view is the primary view (b) The data view records what is in the system (c) The dynamic view describes the flow of data (d) 5a and 5b are true (e) 5a, 5b and 5c are true 6. In object orientation (a) The functionality of the object model is derived directly from the use case model (b) The interaction model is mapped onto the dynamic model (c) The object model is the most stable view of the system (d) 6a and 6c are true (e) None is true 7. Encapsulation of hardware (a) Is little used in modern electronics

1.9. QUIZ (b) Makes software development easier (c) Is inherent in the way most hardware engineers work 8. Object orientation (a) Encapsulates software at object, component, and system level (b) Maximizes maintainability, reuse and extension (c) Helps give applications a longer life (d) All of the above

17

18

CHAPTER 1. FUNDAMENTALS OF OOM

Chapter 2 UML - Part 1 This chapter explains the origins of UML and some of the different kinds of diagrams available within it.

2.1

UML - What It Is

The Unified Modeling Language was originally developed at Rational Software but is now administered by the Object Management Group. It is a modelling syntax aimed primarily at creating models of software-based systems, but can be used in a number of areas. It is:

• Syntax only — UML is just a language, it tells you what model elements and diagrams are available and the rules associated with them. It doesn’t tell you what diagrams to create. • Process independent — the process by which the models are created is separate from the definition of the language. You will need a process in addition to the use of UML itself. 19

20

CHAPTER 2. UML - PART 1 • Tool independent — UML leaves plenty of space for tool vendors to be creative and add value to visual modelling with UML. However, some tools will be better than others for particular applications. • Well documented — the UML notation guide is available as a reference to all the syntax available in the language. • Its application is not well understood — the UML notation guide is not sufficient to teach you how to use the language. It is a generic modelling language and needs to be adapted by the user to particular applications. • Originally just for system modelling — some user defined extensions are becoming more widely used now, for example for business modelling and modelling the design of web-based applications.

2.2

Why Use UML?

• Software Construction Needs a Plan. There is a common perception(理解) among general management that software is both cheap to produce and easy to change. “Its only a bit of software - it won’t take you long.” Developers know that this is not true. Software is extremely complex and, once a particular structure is in place, often long-winded(气长的, 罗嗦的, 冗长的) and difficult to change. An architect(建筑师) knows this and creates a drawing of the building from more than one direction, ensuring that the structure is appropriate for the purpose of the building and that the dimensions are all consistent. Only when this visual model of the proposed work has been approved is the job of laying bricks begun.

2.2. WHY USE UML?

21

• Visualize In Multiple Dimensions and Levels of Detail. Software is very abstract and hard to visualize. A visual modelling language, such as UML, allows software to be visualized in multiple dimension, so that a computer system can be completely understood before construction begins. Furthermore, UML can be used to produce several models at increasing levels of detail. The overall scope of the software can quickly and easily be defined at the start of the project with a high level model allowing for accurate estimation. Increasing levels of detail can then be added to each part of the software as it is constructed, until finally the software appears as code. The code can then be tested against a test model that is derived from the original model of requirements. • Appropriate For Both New and Legacy(遗 遗赠 物,遗 遗产) Systems. UML is appropriate for both new system developments and improvements to existing systems. It is a fallacy(谬误, 谬论) that in order to use a new modelling technique on an old system, the old system will have to be completely “re-documented” in the new style in order for any change to take place. The truth is that only those parts that are affected by the change will need to be modelled. If they were badly documented or not documented at all, then a lot of work would need to be done to understand them anyway in order to make the change. • Documents Software Assets. Undocumented or badly documented software has a reduced value as a company asset. With so much of the company’s business process embedded in obtuse(愚蠢的, 迟钝的) software code, a company is vulnerable to losing an understanding of and control over the business

22

CHAPTER 2. UML - PART 1 rules by which it operates. Gradual re-engineering of the company’s computer software in a way that makes the functionality of the software transparent, brings those important assets back under control. It removes the company from dependence on key personnel who may leave at any time and improves understanding of the company’s critical business processes. It even improves the quality of software engineering staff because those who want to do a proper job will look for companies that model with UML. • Unified and Universal. The Unified Modelling Language was created by Rational Software in order to provide a standard for software modelling languages. It is now owned and controlled by the Object Modelling Group, an independent organization. UML has quickly become the de facto(事 实 上 的, 实 际 的) standard modelling language in the software industry. UML is a universal language because it can be applied in many areas of software development. It includes user-definable extension mechanisms so that it can be adapted for specific environments. Industry standard extensions now exist for business modelling and web-based applications development. • Inherent Traceability(可 可描 绘, 可 描 写,可 可追 溯). The Use Case Driven nature of modelling with UML ensures that all levels of model trace back to elements of the original functional requirements. This traceability between models comes without the extra effort creating and maintaining a “traceability matrix” which can be a complex and time consuming job. The result is that the impact of a requested change can quickly be estimated. A change in requirements

2.2. WHY USE UML?

23

can be traced though analysis and design models into those components affected and even lines of code. The code affected can then be traced back to the requirements and total regression testing(回归测试) effort calculated. • Accommodates(适 适应, 容 纳) Incremental Development and ReDevelopment. UML models respond well to an incremental development environment. It is possible not only to develop only those parts of the model that are required to satisfy the new requirements, but also to demonstrate that all the code needed to fulfil those requirements is in place and that only the code needed to fulfil those requirements is in place. This approach ensures that only the work needed to fulfil the current requirement is done, while still developing in such a way that maximizes re-use, maintainability and extensibility. • Accommodates Parallel Development of Large Systems. Large complex UML models can be decomposed in a totally userdefinable way so that different parts of the model can be developed independently by different people or groups. Furthermore, given the right tool and change management infrastructure(基础设施), each part of each model can be independently change managed. This facility enables independent, yet controlled and coordinated, working on different parts of a project by different groups. Each group, however, still has full visibility of the activity of other groups and is kept fully aware of all changes that affect its own work. Automatic metric extraction can contribute further to improving estimation.

24

CHAPTER 2. UML - PART 1

Figure 2.1: How UML Started

2.3

How UML Started

UML came about when James Rumbaugh joined Grady Booch at Rational Software. They both had object oriented syntaxes and needed to combine them. Semantically(语义上) they were very similar, it was mainly the symbols that needed to be unified. The result was UML 1.0 Then Ivar Jaconson joined them. He brought with him the syntax for use cases which was added in UML 1.1. The Object Management Group adopted the UML1.1 specification in November 1997 making it an independent industry standard. Some small changes were made in versions 1.3 and 1.4. Version 2.0 is currently being researched. See Figure. 2.1.

2.4

UML Diagram Types

UML provides a number of diagram types as a mechanism for entering model elements into the model and showing overlapping sets of models elements and

2.4. UML DIAGRAM TYPES

25

their relationships. UML does not specify what diagrams should be created or what they should contain, only what they can contain and the rules for connecting the elements. the diagram types include: • Use Case Diagrams — shows an outside-in(里 面 翻 到 外 面 的, 彻 底 的) view of the procedures available in the use of the system. These are summary diagrams and between them should contain all use cases available in the system and so all the available functionality of the system, represented at a high level. • Static Structure Diagram — includes object and class diagrams. Most methods use class diagrams to describe the properties of the objects in the system and their relationships. Object diagrams are rarely used, except for examples of the way in which object interact, and these are normally shown on sequence or collaboration diagrams • Interaction Diagrams — these include collaboration and sequence diagrams, both of which show the way in which objects interact in order to fulfil the functionality of the use case Further diagram types include: • Activity Diagrams — a generic flow chart used much in business modelling and sometimes in use case modelling to indicate the overall flow of the uses case. This diagram type replaces the need for dataflow diagrams but is not a main diagram type for the purposes of analysis and design. • Component Diagrams — shows the types of components, their interfaces and dependencies in the software architecture that is the solution to the application being developed.

26

CHAPTER 2. UML - PART 1 • Deployment Diagrams — shows actual computing nodes, their communication relationships and the processes or components that run on them.

2.5

Business Modelling, Web Applications, and extending UML

UML can be used to model a business, prior to automating it with computers. The same basic UML syntax is used, however, a number of new symbols are added, in order to make the diagrams more relevant to the business process world. A commonly used set of these symbols is available in current versions of Rational Rose.1 The most commonly used UML extensions for web applications were developed by Jim Conallen2 . You can access his own website to learn more 1

IBM Rational Rose 是一个完整的可视建模方案，开发人员、项目经理、工程师和分

析人员可以在提交编码之前对需求和构架进行可视化、理解和改进。 • 支持UML 1.4 的模型驱动开发灵活的实施支持 • 从单独的建模，到设计级代码生成，再到可全面执行的应用程序生成 • Java、C、C++、Visual Basic、Ada、XML、CORBA/IDL、MIDL 的双向工程 • 自动或按需而定的Java 同步 • 与领先的IDE 集成 • 基于UML 的数据建模 • 用领先的数据库管理系统进行数据模型同步 • 对Java 和Visual C++ 提供Gang of Four (GoF) 设计模式的支持 • 多用户支持Web 发布和生成报告 2

Jim Conallen is a software engineer in IBM Rational’s Model Driven Development

2.6. USE CASE DIAGRAM

27

about them by following the link. These symbols are also available in current versions of Rational Rose. UML is designed to be extended in this way. Extensions to the syntax are created by adding “stereotypes(固定形式)” to a model element. The stereotype creates a new model element from an existing one with an extended, user-defined, meaning. User defined symbols, which replace the original UML symbol for the model element, can then be assigned to the stereotype. UML itself uses this mechanism, so it is important to know what stereotypes are predefined in UML in order not to clash with them when creating new one. Stereotypes allow the UML syntax to be used to model anything.

2.6

Use Case Diagram

The use case diagram show the functionality of the system from an outside-in viewpoint. See an example of use case diagram in Figure. 2.2. • Actors (stick men) are anything outside the system that interacts with the system. • Use Cases (ovals) are the procedures by which the actors interact with the system • Solid lines indicate which actors interact with the system as part of which procedures • Dotted lines show dependencies between use cases, where one use case is “included” in or “extends” another. Strategy team, where he is actively involved in applying the Object Management Group’s (OMG) Model Driven Architecture (MDA) initiative to IBM Rational’s model tooling.

28

CHAPTER 2. UML - PART 1

Figure 2.2: Use Case Diagram

A use case can be related to another use case by either an “include” or an “extend” relationship. An “include” relationship indicates that the procedure of the used use case is part of the procedure of the using use case. The arrow is, in effect, an unconditional call to the procedure in the used use case. An example of the include relationship is illustrated in Figure. 2.3 in which use case 1 includes use case 2. If the procedure of the use case is an alternative or partial alternative course to a procedure defined in another use case, then an “extends” relationship is used from the “extending” use case to the “extended” use case. The procedure in the “extending” used case then replaces all or part of the procedure in the “extended” use case under conditions specified in the “extending” use case. This is illustrated in Figure. 2.3 in which use case 3 extends use case 1.

2.7. CLASS DIAGRAMS

29

Figure 2.3: The Extend and Include Relationships Among Use Cases

Include and extend relationships allow all possible procedures to be specified without duplication. The boundaries of the system are illustrated in a use-case diagram as a boundary rectangle including the use cases with the actors outside of it. The name of the system appears at the top of the rectangle. A typical use-case diagram incorporating the boundary rectangle appears in Figure. 2.4. Associated with a use-case diagram is usually the corresponding use-case detail. The details may be captured as either a sequence diagram or in a textual description.

2.7

Class Diagrams

Class diagrams show the static structure of the systems. In other words, it describes how the system is structured instead of how it behaves. It describes “what things are” and their relationships with other things. To describe all the objects in a system would be rather tedious as many of them have similar characteristics, and, in any case, some of them are created and destroyed as

30

CHAPTER 2. UML - PART 1

Figure 2.4: Use-Case Diagram for a Registration System.

2.7. CLASS DIAGRAMS

31

Figure 2.5: Class Diagram

a program proceeds. Class diagrams are, therefore, used more often than object diagrams to show this view3 . Classes define the properties of the objects which belong to them. See Figure. 2.5. These include: • Attributes - (second container) the data properties of the classes including type, default value and constraints • Operations - (third container) the signature of the functionality that can be applied to the objects of the classes including parameters, parameter types, parameter constraints, return types and the semantics. • Associations - (solid lines between classes) the references contained 3

Actual objects become important when they interact with other objects, so it is more

useful to view then in interaction diagrams.

32

CHAPTER 2. UML - PART 1

Figure 2.6: UML Notation for Objects

within the objects of the classes to other objects enabling interaction with those objects.

2.7.1

Class

A class represents entities with common characteristics and behaviors(i.e., attribute, services, rules, and relationships). The following paragraphs describe how objects, class, and parameterized classes are documented in UML. Figure. 2.6 illustrates how objects are represented in UML. An object is illustrated as a rectangle with the name underlined. The full name of an object is the object name and the class name separated by a colon. In some cases, either the object name or the class name is not present. In all cases (and diagrams illustrating objects), the name of the object is underlined to distinguish it from a class. In UML a class may appear in multiple diagrams. One result of this possibility is that different diagrams may suppress(抑制, 忍住; 隐瞒) all or some attributes or operations. If a single attribute or operation is given, the rectangle for the class is partitioned into three sections. An empty section does not mean that there is no attributes or operations associated with the class, only that they have not been shown in that diagram. Figure. 2.7 illustrates two ways in which classes are represented in UML diagrams. The first example illustrates how a class is represented when the attributes and operations

2.7. CLASS DIAGRAMS

33

Figure 2.7: UML Representations for Classes

associated with the class are suppressed. The second example illustrates a class with the attributes and operations represented. In the second example, the name of the class appears in the top section, the attributes in the middle section, and the operation in the bottom section. Attributes are specified according to the following notation: Visibility name: type = default-value where, • visibility is public (+), protected (#), or private(-)4 • name is a string by which the attribute is identified • type is the attribute type • default-value is a value assigned to the attribute unless specified otherwise. 4

The visibility parameter does not have rigorous semantics in UML. In fact, the inter-

pretation of this parameter is usually locally defined base on the semantics of visibility employed by the programming language used in implementation. Hence, a C++ oriented development organization and a Smalltalk-oriented development organization may use the same visibility for an attribute, but mean different things by it.

34

CHAPTER 2. UML - PART 1 At a minimum, the name os the attribute must be specified. The other

fields are optional5 . A derived attribute, one that is computed rather than stored, is indicated by a “/” before the attribute declaration. Operations are specified according to the following notation: visibility name (parameter-list) : return-type [property-string] where, • visibility is public (+), protected (#), or private (-) • name is a string by which the operation is identified • parameter-list contains comma-separated parameters whose syntax is given by direction name: type = default-value – direction indicates if the parameter is for input (in), output(out), or both(in out) – name is the name of the parameter – type is the type of the parameter – default-value identifies the default value of the parameter • return-type is a comma-separated list of return types • property-list indicates property values that apply to the operation. 5

We should not be concerned with identifying the type associated with an attribute

with an attribute during analysis as that is a design decision. Because class diagrams are used during analysis and design, UML must support documenting our model with the appropriate levels of detail.

2.7. CLASS DIAGRAMS

35

Figure 2.8: Attaching a Constraint on the class

Figure 2.9: Package Diagram.

As was the case with attributes, only the name of the operation must be specified; the other fields are optional. Figure. 2.8 illustrates how a constraint can be attached to a class. Anything may appear within the brace identifying the constraint. Most practitioners use a textual description of the constraint. Figure. 2.9 shows a package diagram. According to the UML specification, a package is illustrated using a folder-style icon. When the classes contained within the package are suppressed, the name of the package goes in the center of the folder. When the classes are present, the name of the package goes in the tab portion of the folder. Dependencies between packages are illustrated

36

CHAPTER 2. UML - PART 1

Figure 2.10: Associations in UML.

as a dashed arrow pointing in the direction of the dependency.

2.7.2

Relationships

Relationships can exist between instances of classes or between classes. Associations(联 系) and aggregations(聚 合) are relationships that relate two or more other instances of classes(association and aggregation). Generalization(一般化, 普遍化, 概括) and specialization are relationships(特殊化, 专 门化) between two classes. Figure. 2.10 illustrates the basic representation of an association in UML. An association is drawn as a line connecting two classes. The line is labelled with the name of the association, the multiplicities of the two classes(number of objects of the given class) participating in the association, and the roles that an instance of each class takes within the association. All of these labels are optional. The multiplicity associated with one end of an association can be given

2.7. CLASS DIAGRAMS

37

Table 2.1: Multiplicity Keys and Their Interpretation Key

Interpretation

*

Any number of objects (including none)

1

Exactly one object

n

Exactly n objects (n is an integer)

1...1

Zero or one (indicates the association is optional)

n...m

Range from n as minimum to m as maximum(n and m are integers)

2, 4

Discrete combination(as two doors or four doors)

Figure 2.11: Unidirectional Association

in any of the forms identified in Table. 2.1. The default assumption about an association is that it can be traversed by an object at either end of the association. In many cases, this assumption is not valid. To indicate unidirectional traversal the line connecting the two classes is replaced by an arrow pointing in the direction of traversal. This is illustrated in Figure. 2.11. Figure. 2.12 illustrates how an association class is expressed. The association class is connected to the link between the two classes participating in the association by a dashed line. The association class can have attributes and operations associated with it. Figure. 2.13 shows an association class that has been promoted to a full class. A derived association has been introduced to capture the fact that there is an association between Class A and Class B. The derived association

38

CHAPTER 2. UML - PART 1

Figure 2.12: Association Class

Figure 2.13: Promoting an Association Class to a Full Class and Introducing a Derived Association.

Figure 2.14: Qualified Association

2.7. CLASS DIAGRAMS

Figure 2.15: Aggregation and Composition

Figure 2.16: Generalization and Specialization

Figure 2.17: Dependency

39

40

CHAPTER 2. UML - PART 1

Figure 2.18: Interface Diagram Using Classes

Figure 2.19: Alternative Form for Representing Interface

2.8. SUMMARY

41

is denoted through the use of a “/” in front of the association name. Figure. 2.14 illustrates the diagram for a qualified association. Qualifiers can be used to denote key lookup in a map. Figure. 2.15 illustrates how aggregation and composition are documented. Unidirectional navigation across the aggregation or composition is illustrated using an arrow in the same manner as for associations. Figure. 2.16 shows generalization and specialization. The generalization is indicated as the class with the point of the triangle pointing at it. Subclass 1 illustrates single generalization, while Subclass 2 illustrates multiple generalization. Generalization can have a discriminator that distinguishes between different kinds of generalizations.6 Figure. 2.17 illustrates how dependencies between classes are documented. Dependencies are typically associations that are created dynamically. Figure. 2.18 illustrate how an interface can be specified using classed. The dashed line with triangle at the end is used to indicate that implementation class realizes the interface. An alternative way of documenting interfaces uses a lollipop style icon to represent the interface as show in Figure. 2.19.

2.8

Summary

• UML is just a syntax. It says nothing about how too create a model. • UML is well documented but little understood. • It was developed by Grady Booch, Jim Rumbaugh and Ivar Jacobon 6

This diagram can be used to express multiple and dynamic classification. For this

diagram, one employs a discriminator to establish which combinations are legal. Classification is different than inheritance, in the sense that multiple classification allows types for an object without defining a specific type for that purpose.

42

CHAPTER 2. UML - PART 1 at Rational Software. • UML specifies 8 different diagram. Not all are used in practice. • UML can be extended through the use of stereotypes. • A use case diagram show the functionality of the system from the outside in. • Class diagrams show the static structure of the systems.

2.9

Quiz

1. Interaction diagrams include (a) Collaboration and class diagrams (b) Statecharts and sequence diagrams (c) Sequence and class diagrams (d) Collaboration and Sequence diagrams (e) Class and object diagrams 2. UML is (a) Language independent (b) Process independent (c) Easy to apply (d) 2b and 2c (e) 2a and 2b 3. The UML is currently controlled by

2.9. QUIZ

43

(a) Rational Software (b) The Object Management Group (c) James Rumbaugh (d) Grady Booch (e) Ivar Jacobson 4. Which of the following statements is true? (a) Object diagrams are the most important diagram type (b) Collaboration diagrams show the relationship between states for a given object (c) Flowcharts are used to show the order in which objects interact (d) Activity diagrams can be used to show the overall flow of a use case (e) Deployment diagrams show the order in which functionality will be made available to users 5. UML can be extended using stereotypes and used for (a) Business modelling (b) Web Applications (c) 5a and 5b (d) Any problem domain (e) None of the above 6. A use case is (a) A sequence of interactions between actors and the system

44

CHAPTER 2. UML - PART 1 (b) A procedure by which actors interact with the system (c) The way an actor to achieves the goal that is the name of the use case (d) A way of grouping together functional requirements (e) All of the above 7. An association between two classes on a class diagram (a) Allows interaction between the two classes (b) Allows interaction between the objects of the two classes (c) Shows inheritance between the two classes (d) 7a and 7b (e) 7b and 7c

Chapter 3 UML - Part 2 This chapter explains the rest of the different kinds of diagrams available within UML.

3.1

Sequence Diagram

Sequence diagrams show potential interactions between objects in the system being defined. Normally these are specified as part of a use case or use case flow and show how the use case will be implemented in the system. See Figure. 3.1. They include:

• Objects — rectangular boxes at the top or actors, named or just shown as belonging to a class from or to which messages are sent to other objects. • Messages — solid lines for calls and dotted lines to data returns, showing the messages that are send between objects. This includes the order of the messages which is from top of the diagram to the bottom. 45

46

CHAPTER 3. UML - PART 2

Figure 3.1: Sequence Diagram

• Object lifelines — dotted vertical lines showing the lifetime of the objects. • Activation — the vertical oblong boxes on the object lifelines showing the thread of control in a synchronous system. A sequence diagram, such as shown in Figure. 3.1, is a diagram that shows actual objects and interactions between objects in the horizontal direction and sequence in the vertical direction. The vertical dotted lines represent the lifetime of the object and the horizontal arrows the interactions of messages between objects. These messages can represent any kind of message (specifically a call to an operation on the target object). Messages can include sequence numbers, operation names, and actual parameters. Narrow elongated boxes on the object lifelines represent the “activation” of the object when interactions are sequential and represent calls to operations. The

3.2. COLLABORATION DIAGRAM

47

Figure 3.2: Sequence Diagram For Using a Microwave Oven

operation remains active until all the sequential operations, which it calls, have completed and returned, thus, allowing it to return control to its caller. Figure. 3.2 shows a typical sequence diagram for using a microwave oven.

3.2

Collaboration Diagram

Collaboration Diagrams show similar information to sequence diagrams, except that the vertical sequence is missing. See Figure. 3.3. In its place are:

48

CHAPTER 3. UML - PART 2

Figure 3.3: Collaboration Diagram

• Object Links — solid lines between the objects. These represent the references between objects that are needed for them to interact and so show the static structure at object level. On the links are: • Messages — arrows with one or more message name that show the direction and names of the messages sent between objects A collaboration diagram is functionally equivalent to a sequence diagram with two exceptions: • It shows links between objects along which messages can flow whereas only the messages are shown in a sequence diagram. item The order of the messages can only be seen in their numbering as the vertical dimension is used to show static relationships along with the horizontal dimension.1 A collaboration diagram is used to show how groups of objects work together to perform a piece of functionality required for one path through a 1

This makes the collaboration diagram effectively an object diagram with messages on

the links.

3.2. COLLABORATION DIAGRAM

49

use case.2 The concepts and paths in this diagram are • Object of a particular type (class or interface), represents the role that the object plays in the interaction. • Relationship role, represents role that the link may play within the interaction. • Message, represents communication between object. Figure. 3.3 illustrates a collaboration diagram. The service request is of the form: sequence-number : [condition] : message (arglist) where • sequence-number indicates the order in which the service request was dispatched – “*” is used to indicate iteration (for example, 2* indicates that the second service request repeats) – sequence numbers can be sequential integers or based on a decimal scheme • condition is an optional condition that is to be evaluated to determine if the request is sent • message is a string identifying the service request • arglist is a list of arguments formulated in the same fashion as the arglist for an operation 2

Sequence diagrams are better for fully specifying a use case as they can include con-

ditional functionality in various ways without confusing the order of the messages.

50

CHAPTER 3. UML - PART 2

3.3

Statechart Diagram

Statecharts, often used more in embedded systems than in information systems, show, for a class, the order in which incoming calls to operations normally occur, the conditions under which the operations respond and the response. They are a class-centric view of system functionality as opposed to sequence and collaboration diagrams which are a use case-centric view of functionality. See Figure. 3.4. They include: • States — rounded boxes which indicate the stable states of the object between events. A state represents a period between events during the object is stable. If an object has many internal states, the state model can be simplified by using “nested state” within a simpler state model. • Transitions — the solid arrows which show possible changes of state. A transition represents a response by an object to an event received by it. The response produces a change in the object, which can constitute change in state. The mechanism for identifying if a change in state occurs is a guard condition. A guard condition is a Boolean expression in terms of event parameters and the state variables and the functions of the object to which the state diagram belongs. When an event triggers the transition, the value of the guard condition is evaluated. If the value evaluates to true, the transition occurs; otherwise, the transition does not occur. Not all transitions have an associated guard condition. • Events — the text on the transitions before the “/” showing the incoming call to the object interface which causes the change of state. • Conditions — a boolean statement in square brackets which qualifies the event.

3.3. STATECHART DIAGRAM

51

Figure 3.4: Statechart Diagram

• Actions — the text after the “/” which represents a set of operations that is done inside of a state or on a transition. • Extra syntax which defines state centric functionality In UML, three additional constructs are added: history state, activity and timing mark. • A history state is used to capture the concept that a state must “remember” its sub-state when it is exited and be able to enter the same sub-state on subsequent reentry into the state. • An activity is an operation or set of operations within a state that takes time to complete; thus, it is not instantaneous and can be interrupted. Some activities continue until they are terminated by an external event (usually a state change) and others terminate on their own accord. • a timing mark construct is used to capture real-time constraints on transition. The most common use of a timing mark is to capture the maximum limits in the elapsed time between events.

52

CHAPTER 3. UML - PART 2

3.4

Activity Diagram

A UML Activity Diagram is a general purpose flowchart with a few extras. It can be used to detail a business process or to help define complex iteration and selection in a use case description. See Figure. 3.5. It includes: • Active states — oblongs with rounded corners which describe what is done. • Transitions — which show the order in which the active states occur and represent a thread of activity. • Conditions — (in square brackets) which qualify the transitions. • Decisions — (nodes in the transitions) which cause the thread to select one of multiple paths. • Swimlanes — (vertical lines the length of the diagram) which allow activities to be assigned to objects. • Synch States — horizontal or vertical solid lines which split or merge threads (transitions) An activity diagram is similar to a state diagram in that they represent sequences of activity but are closer in semantics to flowcharts in allowing action state. Swimlanes allow activities associated with action states to be assigned to business level actors. Figure. 3.5 shows a basic activity diagram. The solid circle at the top indicates the start point. The rounded rectangles identify activities. The arrows represent a transition. Conditional behavior is identifies by branches and mergers. A diamond represents a branch point if one arrow enters and multiple arrows exit or a merge if several arrows enter and one arrow exits.

3.5. COMPONENT DIAGRAM

53

Concurrent behavior is identified by forks and joins. A dark bar represents a fork is on arrow enters and multiple arrows exit or a join if multiple arrows enter and a single arrow exits.

3.5

Component Diagram

Component Diagrams show the types of software components in the system, their interfaces and dependencies. Figure. 3.6 illustrates a component diagram. The concepts and paths in this diagram are • Component, which represents distributable physical units such as source code, object code, or executable code. • Dependency, which represents the dependency between components. If a group of classes forms a component, we may define another way in which other components use it by applying a special UML construct: an interface. The interface allows components to be designed for use by other components without any knowledge of the internal structure of the used component. Thus, the using component depends on the interface to the used component, not on its implementation. This makes it possible to design components that are polymorphic (i.e., substitutable for one another).

3.6

Deployment Diagram

Deployment diagrams show the computing nodes in the system, their communication links, the components that run on them and their dependencies. Figure. 3.7 illustrates a deployment diagram. It consists of two processors with a single component on each. The processors are connected by (TCP/IP).

54

CHAPTER 3. UML - PART 2

Figure 3.5: Activity Diagram

3.6. DEPLOYMENT DIAGRAM

Figure 3.6: Component Diagram

55

56

CHAPTER 3. UML - PART 2

Figure 3.7: Deployment Diagram

There is a dependency between the Graphical User Interface(GUI) component on the central processing unit (CPU) 2 with the myComponent on CPU 1.

3.7

Modelling Architecture

Class diagrams can be used to model hi-level architecture with packages, interfaces and dependencies. Packages are used to group together a set of model elements for various purposes. Figure. 3.8. The results may show: • Subsystems — the design view of a software component or re-useable part of a component. • Libraries of re-useable elements, usually classes. • The hierarchic structure and layering of the system • Client-server relationships between components and other model elements • Logical dependencies of sub-systems and libraries on one another

3.7. MODELLING ARCHITECTURE

Figure 3.8: Modelling Architecture

57

58

CHAPTER 3. UML - PART 2

3.8

Summary

• Sequence diagrams show potential interactions between objects in the system in the order in which they normally occur. • Collaboration diagrams also show interaction between objects, but emphasize the structure required to support them. • Statecharts are a class-centric view of system functionality. • An activity diagram is as general purpose flowchart. • Component diagrams show the types of software components in the system, their interfaces and dependencies. • Deployment diagrams show the computing nodes in the system, their communication links, the components that run on them and their dependencies. • Class diagrams can be used to model hi-level architecture with packages, interfaces and dependencies.

3.9

Quiz

1. The activation on a sequence diagram shows (a) The messages between objects (b) The objects involved in a use case (c) The thread of control in the sequence (d) The condition under which an operation is executed (e) None of the above

3.9. QUIZ 2. A collaboration diagram shows (a) The thread of control between objects (b) References between objects (c) Similar information to sequence diagrams (d) 2a and 2b (e) 2b and 2c 3. An event on a statechart shows (a) What caused the transition (b) What caused the change of state (c) The action performed on the transition (d) 3a and 3b (e) 3b and 3c 4. In an activity diagram, which of the following is true? (a) A synch state defines a stable state of the system (b) A swim lane can be used to show object interaction (c) A condition qualifies a transition (d) A decision splits the thread into concurrent threads (e) A transition shows a stable state of the system 5. A component diagram shows: (a) Classes and their relationships (b) The types of components in the system

59

60

CHAPTER 3. UML - PART 2 (c) Dependencies between components (d) 5a and 5b (e) 5b and 5c 6. Which of the following is true? (a) Packages appear on sequence diagrams (b) Dependencies appear on class diagrams (c) Packages show client-server relationships between components (d) 6a and 6b (e) 6b and 6c 7. Computing nodes on a deployment diagram (a) Show connections between components (b) The components that run on computers (c) What communication links are available between subsystems (d) What processors are available (e) What communication links are available between computers

Chapter 4 The Software Development Process In order to make the development of software predictable and repeatable, a process is needed which defines what is done by whom and in what order. When using UML this revolves around the creation of models at different levels of abstraction and increasing levels of detail. This chapter takes you through each step of the process, shows what models are created, and how information flows between them.

4.1

Business Process Modelling

A Business Model may be created to better understand the business, either for the purpose of improving the business itself, or as a way of discovering requirements for a computer system. Business processes can be modelled at various levels within the organization. The model uses all the standard rules of UML and includes some user defined extensions. See Figure. 4.1. The differences include: 61

62

CHAPTER 4. THE SOFTWARE DEVELOPMENT PROCESS

Figure 4.1: Business Model

• Slightly different symbols for business actors and business use cases (also known as business processes). • Some of Jacobson’s stereotypes with additions to represent business entities and business workers. • The system boundary is now the business or the part of the business being modelled.

4.2

System Requirements Definition

Implementation constraints are modelled separately from the use case model. The logical functional requirements of a systems are modelled using use cases and use case descriptions — documents associated with the use case giving a detailed textual description of the use case flow and other logical constraints. Using use cases for the logical requirements has a number of advantages:

4.3. THE SYSTEM ANALYSIS MODEL

63

• It is an outside-in view and easily understood by non-technical people. • It is more likely to be complete than a classical functionally decomposed specification. • It directly maps into and is traceable to acceptance tests, user documentation and the analysis and design models.

4.3

The System Analysis Model

The System Analysis Model is made up of class diagrams, sequence or collaboration diagrams and statechart diagrams. Between them they constitute a logical, implementation-free view of the computer system that includes a detailed definitions of every aspect of functionality. This model: • Defines what the system does not how it does it. • Defines logical requirements in more detail than the use case model, rather than a physical solution to the requirements. • Leaves out all technology detail, including system topology.

4.4

System Model Information Flow

Figure. 4.2 illustrates the way in which the 3-dimensional system model is developed iteratively from the uses case model in terms of the information which flows between each view. Note that it is not possible fully to develop any one of the three views without the other two. They are interdependent. This is the reason why incremental and iterative development is the most efficient way of developing computer software.

64

CHAPTER 4. THE SOFTWARE DEVELOPMENT PROCESS

Figure 4.2: System Model Information Flow

4.5

The System Design Model

This model is the detailed model of everything that is going to be needed to write all the code for the system components. It is the analysis model plus all the implementation detail. Preferable it should be possible automatically to generate at least frame code from this model. Then if any structural changes to the code are made in the design model first and then forward re-generated, this ensures that the design model accurately reflects the code in the components. The design model includes: • Class, sequence or collaboration and state diagrams, as in the analysis model, but now fully defined ready for code generation. • Component diagrams defining all the software components, their interfaces and dependencies. • Deployment diagrams defining the topology of the target environment

4.6. OVERALL PROCESS FLOW

65

Figure 4.3: Overall Process Flow

including which components will run on which computing nodes.

4.6

Overall Process Flow

The overall process flow must allow for both rework and incremental development. See Figure. 4.3. • Rework — where changes need to be made, the earliest model that the change affects is changed first and the results flowed forward through all the other models to keep them up to date. • Incrementation — increments can restart at any point, dependent on whether the work needed for this increment has already been completed in higher level models.

66

CHAPTER 4. THE SOFTWARE DEVELOPMENT PROCESS

4.7

Incremental Development

Incremental Development is based on use cases or use case flows which define working pieces of functionality at the user level. In an increment, the models required to develop a working software increment are each incremented until a working, tested executing piece of software is produced with incremental functionality. This approach: • Improves estimation, planning and assessment. Use cases provide better baselines for estimation than traditionally written specifications. The estimates are continuously updated and improved throughout the project. • Allows risks to the project to be addressed incrementally and reduced early in the life-cycle. Early increments can be scheduled to cover the most risky parts of the architecture. When the architecture is stable, development can be speeded up. • Benefits users, managers and developers who see working functionality early in the life-cycle. Each increment is, effectively, a prototype for the next increment.

4.8

Summary

• A software process is needed to make a software development predictable and repeatable. • UML can be used to model business processes and structure. • Functional requirements are defined with use cases and use case descriptions.

4.9. QUIZ

67

• A system analysis model is a technology-free model of the detail of what the system will do. • The system design model is a detailed model of the software structure of the system down to class property level. • The use case model feeds the object, interaction and state models which are interdependent. • The classic waterfall process should be augmented by both rework (iterative) and incremental loops. • Incremental development improves estimation, planning, assessment and software quality.

4.9

Quiz

1. Business process modelling of use cases uses (a) The same symbols as used in analysis (b) Similar symbols with additions (c) Different symbols entirely (d) Doesn’t use symbols 2. System requirements defined with use cases map directly into (a) User documentation (b) System acceptance tests (c) The analysis model (d) The design model

68

CHAPTER 4. THE SOFTWARE DEVELOPMENT PROCESS (e) All of the above 3. The system analysis model leaves out (a) Topology (b) Technology (c) Functionality (d) 3a and 3b (e) 3b and 3c 4. Information flows from the interaction model to the (a) state model (b) object model (c) use case model (d) 4a and 4b (e) 4b and 4c 5. The UML system design model may include (a) 1 diagram type (b) 2 diagram types (c) 3 diagram types (d) 4 diagram types (e) 5 diagram types 6. An increment starts at

4.9. QUIZ (a) requirements (b) analysis (c) design (d) coding (e) any point in the waterfall 7. A increment produces (a) increased system functionality (b) a working executable (c) a tested executable (d) implemented use cases (e) all of the above

69

70

CHAPTER 4. THE SOFTWARE DEVELOPMENT PROCESS

Appendix A Answers • Chapter 1: 1b, 2c, 3d, 4c, 5d, 6c, 7c, 8d • Chapter 2: 1d, 2e, 3b, 4d, 5d, 6e, 7b • Chapter 3: 1c, 2e, 3d, 4c, 5e, 6b, 7d • Chapter 4: 1b, 2e, 3e, 4d, 5e, 6e, 7e

71

72

APPENDIX A. ANSWERS

Appendix B CRC B.1

Introduction

It is difficult to introduce both novice and experienced procedural programmers to the anthropomorphic perspective necessary for object-oriented design. We introduce CRC cards, which characterize objects by class name, responsibilities, and collaborators, as a way of giving learners a direct experience of objects. We have found this approach successful in teaching novice programmers the concepts of objects, and in introducing experienced programmers to complicated existing designs.

B.2

Problem

The most difficult problem in teaching object- oriented programming is getting the learner to give up the global knowledge of control that is possible with procedural programs, and rely on the local knowledge of objects to accomplish their tasks. Novice designs are littered with regressions to global thinking: gratuitous global variables, unnecessary pointers, and inappropri73

74

APPENDIX B. CRC

ate reliance on the implementation of other objects. Because learning about objects requires such a shift in overall approach, teaching objects reduces to teaching the design of objects. We focus on design whether we are teaching basic concepts to novices or the subtleties of a complicated design to experienced object programmers. Rather than try to make object design as much like procedural design as possible, we have found that the most effective way of teaching the idiomatic way of thinking with objects is to immerse the learner in the ”object-ness” of the material. To do this we must remove as much familiar material as possible, expecting that details such as syntax and programming environment operation will be picked up quickly enough once the fundamentals have been thoroughly understood. It is in this context that we will describe our perspective on object design, its concrete manifestation, CRC (for Class, Responsibility, and Collaboration) cards, and our experience using these cards to teach both the fundamentals and subtleties of thinking with objects.

B.3

Perspective

Procedural designs can be characterized at an abstract level as having processes, data flows, and data stores, regardless of implementation language or operating environment. We wished to come up with a similar set of fundamental principles for object designs. We settled on three dimensions which identify the role of an object in a design: class name, responsibilities, and collaborators. The class name of an object creates a vocabulary for discussing a design. Indeed, many people have remarked that object design has more in common with language design than with procedural program design. We urge learners (and spend considerable time ourselves while designing) to find

B.4. CRC CARDS

75

just the right set of words to describe our objects, a set that is internally consistent and evocative in the context of the larger design environment. Responsibilities identify problems to be solved. The solutions will exist in many versions and refinements. A responsibility serves as a handle for discussing potential solutions. The responsibilities of an object are expressed by a handful of short verb phrases, each containing an active verb. The more that can be expressed by these phrases, the more powerful and concise the design. Again, searching for just the right words is a valuable use of time while designing. One of the distinguishing features of object design is that no object is an island. All objects stand in relationship to others, on whom they rely for services and control. The last dimension we use in characterizing object designs is the collaborators of an object. We name as collaborators objects which will send or be sent messages in the course of satisfying responsibilities. Collaboration is not necessarily a symmetric relation. For example in Smalltalk- 80, View and Controller operate as near equals (see example below) while OrderedCollection offers a service with little regard or even awareness of its client. Throughout this paper we deliberately blur the distinction between classes and instances. This informality is not as confusing as it might seem because the concreteness of our method substitutes for naming of instances. This also makes our method for teaching independent of whether a class or prototype-based language is used.

B.4

CRC Cards

The cards started as a HyperCard stack which provided automatic indexing to collaborators, but were moved to their current form to address problems of portability and system independence. Like our earlier work in documenting

76

APPENDIX B. CRC

Figure B.1: A Class-Responsibility-collaborator (CRC) index card

the collaboration of objects, CRC cards explicitly represent multiple objects simultaneously. However, rather than simply tracing the details of a collaboration in the form of message sending, CRC cards place the designer’s focus on the motivation for collaboration by representing (potentially) many messages as a phrase of English text. A Class-Responsibility-collaborator (CRC) index card As we currently use them, all the information for an object is written on a 4” x 6” index card. These have the advantages that they are cheap, portable, readily available, and familiar. Figure. B.1 shows an idealized card. The class name appears underlined in the upper-left hand corner, a bullet- list of responsibilities appears under it in the left two-thirds of the card, and the list of collaborators appears in the right third. CRC-cards describing the responsibilities and collaborations of Smalltalk’s Model, View and Controller. Figure.B.2 shows an example taken from the

B.4. CRC CARDS

77

Figure B.2: CRC-cards describing the responsibilities and collaborations of Smalltalk’s Model, View and Controller.

78

APPENDIX B. CRC

Smalltalk-80 image, the much-misunderstood model-view-controller user interface framework. We have deliberately shown only a portion of the responsibilities each of these objects assumes for clarity of exposition. Note that the cards are placed such that View and Controller are overlapping (implying close collaboration) and placed above Model (implying supervision.) We find these and other informal groupings aid in comprehending a design. Parts, for example, are often arranged below the whole. Likewise, refinements of an abstraction can be collected and handled as a single pile of cards with the most abstract card on top where it can represent the rest. The ability to quickly organize and spatially address index cards proves most valuable when a design is incomplete or poorly understood. We have watched designers repeatedly refer to a card they intended to write by pointing to where they will put it when completed. Design with the cards tends to progress from knowns to unknowns, as opposed to top-down or bottom up. We have observed two teams arriving at essentially the same design through nearly opposite sequences, one starting with device drivers, the other with high-level models. The problem demanded a certain set of capabilities which both teams discovered in the course of fulfilling the requirements of the design. We suggest driving a design toward completion with the aid of execution scenarios. We start with only one or two obvious cards and start playing ”what-if”. If the situation calls for a responsibility not already covered by one of the objects we either add the responsibility to one of the objects, or create a new object to address that responsibility. If one of the object becomes too cluttered during this process we copy the information on its card to a new card, searching for more concise and powerful ways of saying what the object does. If it is not possible to shrink the information further, but the object is still too complex, we create a new object to assume some of the responsibilities. We

B.5. EXPERIENCE

79

encourage learners to pick up the card whose role they are assuming while ”executing” a scenario. It is not unusual to see a designer with a card in each hand, waving them about, making a strong identification with the objects while describing their collaboration. We stress the importance of creating objects not to meet mythical future needs, but only under the demands of the moment. This ensures that a design contains only as much information as the designer has directly experienced, and avoids premature complexity. Working in teams helps here because a concerned designer can influence team members by suggesting scenarios aimed specifically at suspected weaknesses or omissions.

B.5

Experience

One of the contexts in which we have used CRC cards is a three-hour class entitled ”Thinking with Objects,” which is intended for computing professionals who have programmed, but whose jobs do not necessarily involve programming every day. The class proceeds by introducing a data flow example (a school, with processes for teaching and administration) which is then recast in terms of objects with responsibilities and collaborators (such as Teacher, Janitor, and Principal). The class then pairs off and spends an hour designing the objects in an automatic banking machine, an exercise chosen because of everyone’s familiarity with the application and its ready breakdown into objects to control the devices, communicate with the central bank database, and control the user interface. (See the appendix for a sample solution.) The exercise is followed by a definition of the terms ”class”, ”instance”, ”method”, and ”message”, and the class concludes with a brief discussion of the history and features of a variety of object- oriented pro-

80

APPENDIX B. CRC

gramming languages. In teaching over a hundred students this course we have encountered no one who was unable to complete the exercise unaided, although one pair in each class usually needs a few hints to get started. Although we have done no follow-up studies, the class is considered a valuable resource in the company and is still well attended with a long waiting list almost a year after its inception. We have also asked skilled object programmers to try using CRC cards. Our personal experience suggests a role for cards in software engineering though we cannot yet claim a complete methodology. We- know of one case where finished cards were delivered to a client as (partial) design documentation. Although the team that produced the cards was quite happy with the design, the recipient was unable to make sense of the cards out of context. Another experiment illustrates the importance of the context established by the handling and discussing of cards. We had videotaped experienced designers working out a problem similar to the bank machine. Our camera placement made cards and the designers’ hands visible but not the writing on the cards. Viewers of the tape had no trouble following the development and often asked that the tape be stopped so that they could express their opinions. The most telling moments came when a viewer’s explanation required that he point to a blurry card in the frozen image on the screen. Finally, we have used CRC cards to advantage in explaining complex designs. A few minutes of introduction is sufficient to prepare an audience for a card based presentation. Cards can be made out in advance or written on the spot. The latter allows the complexity in a design to be revealed slowly, a process related to Dave Thomas’ ”lie management”. The cards are being used as props to aid the telling of a story of computation. The cards allow its telling without recourse to programming language syntax or idiom.

B.6. CONCLUSION

B.6

81

Conclusion

Taking our perspective as a base we give novices and experienced programmers a learning experience which teaches them something valuable about objects. CRC cards give the learner who has never encountered objects a physical understanding of object-ness, and prepares them to understand the vocabulary and details of particular languages. CRC cards also give useful and convincing experience with objects to those who has learned the mechanisms of objects but do not yet see their value. Ragu Raghavan has said that in the switch to objects strong programmers become stronger, but weaker programmers are left behind. Using the cards in group settings we found that even weaker programmers, without a deep understanding of objects, could contribute to object designs. We speculate that because the designs are so much more concrete, and the logical relationship between objects explicit, it is easier to understand, evaluate, and modify a design. We were surprised at the value of physically moving the cards around. When learners pick up an object they seem to more readily identify with it, and are prepared to deal with the remainder of the design from its perspective. It is the value of this physical interaction that has led us to resist a computerization of the cards. It is just this problem-integrating the cards with larger design methodologies and with particular language environments, that we feel holds the most promise for the future. The need to retain the value of physical interaction points to the need for a new kind of user interface and programming environment as far beyond what we have today as our current systems are beyond the tool-oriented environments of the past.