eBook2000 (2000)
Available on Compatible NOOK devices, the free NOOK App and in My Digital Library.
Related collections and offers
Overview
Product Details
| ISBN-13: | 9781447136392 |
|---|---|
| Publisher: | Springer-Verlag New York, LLC |
| Publication date: | 03/14/2013 |
| Series: | Practitioner Series |
| Sold by: | Barnes & Noble |
| Format: | eBook |
| File size: | 7 MB |
Read an Excerpt
2. Object-Oriented Analysis and Design
2.1 IntroductionThis chapter surveys the most significant object-oriented design and analysis methods to emerge since the late 1980s. It concentrates primarily on OOA (Coad and Yourdon,1991), Booch (Booch,1991,1994), Object Modeling Technique (Rumbaugh et al., 1991), Objectory (Jacobson, 1992) and Fusion (Coleman et al., 1994). It also introduces the Unified Modeling Language (Booch et al., 1996; Booch and Rumbaugh,1995).
This chapter does not aim to deal comprehensively with either the range of methods available or the fine details of each approach. Rather, it provides an overview of the design process and the strengths and weaknesses of some important and reasonably representative methods.
2.2 Object-Oriented Design Methods
The object-oriented design methods that we consider are all architecture-driven, incremental and iterative. They do not adopt the more traditional waterfall software development model; instead they adopt an approach which is more akin to the spiral model of Boehm (1988). This reflects developers' experiences when creating objectoriented systems - the object-oriented development process is more incremental than that for procedural systems, with less distinct barriers between analysis, design and implementation. Some organizations take this process to the extreme and adopt an evolutionary development approach. This approach delivers system functions to users in very small steps and revises project plans in the light of experience and user feedback. This philosophy has proved very successful for organizations that have fully embraced it and has led to earlier business benefits andsuccessful endproducts from large development projects.
2.3 Object-Oriented Analysis
We first consider the Object-Oriented Analysis approach (OOA) of Coad and Yourdon (1991). The identification of objects and classes is a crucial task in object oriented analysis and design, but many techniques ignore this issue. For example, neither the Booch method nor OMT deal with it at all. They indicate that it is a highly creative process that can be based on the identification of nouns and verbs in an informal verbal description of the problem domain. A different approach is to use a method such as OOA as the first part of the design process and then to use another object-oriented design method for the later parts of the process.
OOA helps designers identify the detailed requirements of their software, rather than how the software should be structured or implemented. It aims to describe the existing system and how it operates, and how the software system should interact with it. One of the claims of OOA is that it helps the designer to package the requirements of the system in an appropriate manner (for object-oriented systems) and to reduce the risk of the software failing to meet the customer's requirements. In effect, OOA helps to build the Object Model that we look at in more detail when we look at OMT.
There are five activities within OOA which direct the analyst during the analysis process:
Identifying subjects (related objects). 1 Defining attributes (the data elements of the objects). 0 Defining services (the active parts of objects that indicate what the object does).
These are not sequential steps. As information becomes available, the analyst performs the appropriate activity. The intention is that analysts can work in whatever way the domain experts find it easiest to express their knowledge. Thus, analysts may go deeper into one activity than the others as the domain experts provide greater information in that area. Equally, analysts may jump around between activities, identifying classes one minute and services the next.
2.3.1 Class Responsibility Collaborator (CRC)
CRC (Class Responsibility Collaborator) is an exploratory technique rather than a complete method. It was originally devised as a way of teaching basic concepts in object-oriented design. The CRC technique can be exploited in other methods (for example, Booch; it is explicitly used as an early step in Fusion). It is also the foundation of the responsibility-driven design method (Wirfs-Brock et al., 1990), where it constitutes the first phase.
CRC deals primarily with the design phase of development. The process is anthropomorphic and drives development by having project teams enact scenarios and play the parts of objects. Classes are recorded on index cards. The steps in the process can be summarized in Figure 2.1.
Identification of Classes and Responsibilities
In this stage, the classes are identified. Guidelines include looking for nouns in the requirements document and modelling physical objects and conceptual entities.
Object categories are candidate classes. Grouping classes by common attributes gives candidates for abstract superclasses. The classes are written on cards. The classes form the vocabulary for discussion. Subclasses and superclasses are also identified and recorded on the class card. The requirements are then examined for actions and information associated with each class to find the responsibilities of the classes. Responsibilities are the essential duties that have to be performed. They identify problems to be solved and are a handle for discussing solutions. An example of a CRC class card is presented in Figure 2.2.
Assignment of Responsibilities
The responsibilities identified in the previous stage are allocated to classes. The goal is to distribute the "intelligence" of the system evenly around the classes, with behaviour kept with related information. Information about one thing should appear in just one place. If necessary, responsibilities can be shared among related classes. Responsibilities should be made as general as possible and placed as high as possible in the inheritance hierarchy.
Identification of Collaborations
This stage identifies how classes interact. Each class/responsibility pair is examined to see which other classes would need to be consulted to fulfil the responsibility and which classes make use of which responsibilities. The cards for classes that closely collaborate are grouped together physically. This informal grouping helps in the understanding of the emerging design.
Refinement
The design process is driven toward completion by considering execution scenarios. Each member of the design team takes the part of a class enacting the scenario. This process uncovers missing responsibilities and collaborators. The restricted size of the index cards helps stop classes becoming too complex. If a card becomes too cluttered, then it is reviewed. The outcome can be simplified statements of responsibilities, new subclasses or superclasses, or even new classes.
The output of the design is a set of classes that are related through inheritance. The hierarchy is refined with common responsibilities placed as high as possible in the graph. Abstract classes cannot inherit from concrete ones and classes that add no functionality can be discarded.
Strengths and Weaknesses
In assessing CRC it should be noted that CRC is a technique and does not claim to be a method (even though there are practitioners around who use it as a method). CRC is primarily an exploratory technique can be very useful in this role. However, it does not produce a design which can be directly implemented - it is at too high a level. As the index cards produced during the design process are the only form of documentation associated with the design (i.e. the only record of the design decisions taken as well as the end result) they are clearly inadequate. It can be a very powerful technique for identifying initial classes and class relationships (both inheritance and uses relations); however, it does not deal with object creation, object partitioning, object interactions (only collaborations) or any issues related to the implementation of the system. In summary CRC is a powerful technique which has its place within other design methods during the very early stages of class and object identification...