kentb@argosy.UUCP (Kent Beck) (11/09/90)
Ed Berard made several sweeping statements about CRC in his recent posting which I will rebut. First is his characterization of CRC as a methodology. CRC is a method of finding and explaining objects- it deliberately does not address many issues that must be addressed by a life-cycle-wide methodology. As such, it isn't in competition with Booch, although Wirfs-Brock et. al. have pushed the responsibility driven approach onto much the same turf. Second is his contention that CRC is not useful for medium to large projects. I use CRC (and the experience of many people I talked to at OOPSLA bears this out) to explore the structure of a problem in a collaborative setting and to explain the intent of a design, whether to a user, maintainer, or manager. There are times in the life of a large project when you must notate every detail and Booch's family of notations and process for applying them ably serve this purpose, but there are other kinds of design which call for a more engaging and approachable notation.
eberard@bse.com (Edward V. Berard) (11/09/90)
In article <750@argosy.UUCP>, kentb@argosy.UUCP (Kent Beck) writes: > > Ed Berard made several sweeping statements about CRC in his recent posting > which I will rebut. First is his characterization of CRC as a > methodology. CRC is a method of finding and explaining objects- it > deliberately does not address many issues that must be addressed by > a life-cycle-wide methodology. As such, it isn't in competition with > Booch, although Wirfs-Brock et. al. have pushed the responsibility > driven approach onto much the same turf. I think some defining of terms is in order here. (Excuse me while I open Pandora's Box. ;-)) Many people like to specify a hierarchy of terms, e.g.: a. A method is a "small," well-defined technique used to accomplish some part of an overall (larger process). For example, as part of an object-oriented requirements effort, one might have a method for identifying objects, and a method for documenting these objects. b. A methodology, on the other hand, is a collection of rules, techniques, guidelines, practices, standards, and methods used to accomplish some significant software engineering effort. For example, one might accomplish object-oriented design using a methodology specified by Booch, Seidewitz and Stark, or others. One would likely use a different methodology for object-oriented requirements analysis. (Using more conventional approaches as examples, structured analysis and structured design are two different methodologies.) People who design methodologies seldom claim that their methodologies cover the entire software life-cycle. c. An approach is an overall guiding theme for the engineering of software. For example, an organization might choose to use an object-oriented approach for the engineering of software, and then select a useful combination of object-oriented methodologies to cover the life-cycle. (Sometimes organizations bundle methods, methodologies, management practices, etc. to create a product to handle entire life-cycles, or at least the development part of a life-cycle, e.g., STRADIS). Using the above definitions, I would say the following: 1. CRC cards are a technique which is useful in identifying objects and specifying relationships among objects. It is not a methodology, and definitely not an overall approach. 2. One could construct a methodology which makes heavy use of CRC cards, but CRC cards by themselves are not a methodology. 3. Booch does not claim that his approach to object-oriented design is a complete approach to the development part of the software life-cycle. 4. Responsibility-driven design is not a complete approach, nor does it claim to be such. I would say, however, that it is at least at the level of a design methodology. > Second is his contention that > CRC is not useful for medium to large projects. I use CRC (and the > experience of many people I talked to at OOPSLA bears this out) to > explore the structure of a problem in a collaborative setting and to > explain the intent of a design, whether to a user, maintainer, or > manager. There are times in the life of a large project when you must > notate every detail and Booch's family of notations and process for > applying them ably serve this purpose, but there are other kinds of > design which call for a more engaging and approachable notation. In general, I agree with Kent on this point. In fact, I sometimes suggest CRC cards to my clients as a means of "sketching" or exploring a problem. I also feel that CRC cards help people get a better feeling about both objects and an object-oriented approach. However, I also alert them to the pitfalls of CRC cards, e.g.: a. As the number of objects within the system grows larger, the number and arrangement of CRC cards can become cumbersome. b. If one is not careful with CRC cards, a great deal of undesirable object coupling can be introduced into the design. This will create problems for maintenance of the product, and will negatively impact software reusability. I understand the wide appeal of CRC cards. Their simplicity is indeed attractive. I also recognize that Booch's approach can appear very daunting. Further, I would agree that for some/many problems CRC cards are perfectly adequate, and that Booch's notations/approach are overkill. I would even go so far as to say that CRC cards can often be combined with more rigorous approaches. I must point out, however, that for critical or large systems There are many issues (e.g., concurrency, timing relationships) which CRC cards (in their present form) do not adequately address. I guess you could summarize my thoughts by saying: the right tool for the right job, and know the value of each tool. -- Ed ---------------------------------------------------------------------------- Edward V. Berard | Phone: (301) 353-9652 Berard Software Engineering, Inc. | FAX: (301) 353-9272 18620 Mateney Road | E-Mail: eberard@bse.com Germantown, Maryland 20874 | ----------------------------------------------------------------------------