A PATTERN LANGUAGE FOR CRC CARDS Mohamed Fayad1, Huáscar Sánchez2, and Haitham Hamza3 1,2Computer Engineering Dept., College of Engineering, San Jose State University One Washington Square, San Jose, CA 95192-0180 [email protected], [email protected] 3Computer Science and Engineering Dept., University of Nebraska-Lincoln Lincoln, NE 68588, USA Ph: +1 402 4729492 [email protected] ABSTRACT The Class Responsibility Collaborator (CRC) cards are index cards that are utilized for mapping candidates classes in predefined design scenarios; e.g. Use Case Scenarios. The objective of CRC cards is to facilitate the design process while insuring an active participation of involved designers. This paper represents the first attempt towards a CRC card pattern language representation via stable patterns as a mean to discover, organize, and utilize CRC cards endured knowledge. Each stable pattern focuses on a distinctive activity and provides a way by which this activity can be conducted efficiently. The pattern language is a continuation of our early effort in improving the effectiveness of CRC cards and their role in the design process. 1. INTRODUCTION: The notion of CRC-Cards was first introduced in 1989 at the annual OOPSLA conference [2]. The acronym CRC stands for Class, Responsibilities, and Collaboration and, while they are not formally used in UML, they can offer valuable insights during the early stages of development [10]. They are primarily used as a brainstorming technique to rapidly and thoroughly explore design alternatives by identifying the classes and their associations within a system. Class-Responsibility-Collaborator (CRC) Cards are index cards utilized for mapping candidates classes in predefined design scenarios; e.g. Use Case Scenarios. They provide a simple alternative for a collaborative design environment, where analysts, designers, and developers try to simulate the system behavior; i.e. role-play-driven approach. This process ends up with a set of collaborative classes represented by index cards, along with their roles, which are played by the members of the development team in a pre-animated design scenario [6]. Figure 1 shows the original CRC cards, and illustrates in light gray color current changes incurred over its original format.Figure 1: Original CRC card and current changes in its structure [HS: They recommended including the original CRC card format. I included this one. What do you think?] Aside from its original purpose that was to teach programmers the Object Oriented Paradigm, CRC Cards have been redefined to become valuable beyond the educational purpose [2]. For their simplicity and flexible form, this tool can be applied to different domains’ purposes, such as teaching OOP, a mean for not only documenting and identifying relevant classes of a system, serving as a methodology or as a front-end for other design methods, but also solving modeling problems, and engaging the entire development team through effective brainstorming sessions, etc. Some of those applications of CRC cards, at such, specify the underlying goals and expectations of CRC Cards use. The processes of accomplishing these goals, especially in software development, throughout iterative sessions are done at ad-hoc. Not precisely knowing when, how, and where to apply them to successfully accomplish the expected goals. This limitation calls software practitioners for a set of suitable guidelines and stable knowledge to answer those former inquiries. Being this the rationale of this work; to propose the first pattern language for CRC cards and communicate this stable knowledge and suitable guidelines. This pattern language will enhance the way we commonly see and use CRC cards; turning it from simple index cards to a valuable knowledge repository. Our idea of this paper is not to provide a specific approach on how to define and deploy a CRC card, instead we provide a straightforward conceptualization and understanding of the CRC Card’s domain knowledge, and fundamental processes to deploy one. To do this we relied on the formed synergy of two methodologies: the Software Stability Concepts paradigm [5] and its sub-elements: Stable Analysis and Design Patterns [5], and Pattern Language Methodology [18]. The reader, in this case, would truly visualize the distinct elements that composed the CRC Card’s domain knowledge, and how they relate with each other to cope with a determined area of application. The rest of the paper is organized as follows. Section 2 provides an overview of the essential characteristics of effective CRC Cards. Section 3 focuses on a bird-eye description of the CRC Card implicit goals and Capabilities. Section 4 discusses the rationale of the Pattern Language for CRC Cards and the set of stable patterns involved in the CRC Card usage. Section 5 provides the detailed description of CRC-Cards pattern language. Some conclusions and discussion are presented in Section 6.2. WHAT MAKES AN EFFECTIVE CRC CARDS? CRC Cards regardless of which format is used [19] embodies a particular set of characteristics that transcend across any context of applicability. Each of these characteristics possesses essential semantics that must be taken into consideration when applying CRC cards across domains. The focusing on those semantics, along with the utilization of CRC Card quality factors would be key factors in improving CRC card utilization within software development life cycle. Regardless of structure’s simplification, current CRC-Cards follow the original structure and share same basic elements (i.e. Class name, Responsibility, and Collaborators). Nevertheless, it may include more elements if necessary [19]. In the long run, these current structures might not always attain the essential aspects needed in future development stages (i.e., building system class diagrams, etc).Therefore, for CRC-cards to aid system development, main essential quality factors need to be satisfied. The fulfillment of these quality factors will have a high impact on the CRC Card’s characteristics realization. These quality factors are provided herein: (1) High Level of Understandability: Illustrate its sections in an orderly and specific manner; showing an efficient distribution of its elements. (2) Accurate Identification of Class Elements: Assure proper Identification of artifact/class and its elements. This will prevent any confusion during class