The document discusses class-responsibility-collaborator (CRC) modeling, a method for organizing classes relevant to system requirements, emphasizing the division of responsibilities and collaborations among classes. It outlines various class types, such as entity, boundary, and controller classes, and highlights the importance of design quality and patterns for object-oriented software. Additionally, it addresses implementation issues related to software reuse and configuration management within the software development process.

1. Class-Responsibility-
Collaborator (CRC) Modeling

2. • Class-responsibility-collaborator (CRC) modeling [Wir90] provides a
simple means for identifying and organizing the classes that are relevant
to system or product requirements. ( Wirfs-Brock and her colleagues)
• A CRC model is really a collection of standard index cards that represent
classes. The cards are divided into three sections. Along the top of the
card you write the name of the class. In the body of the card you list the
class responsibilities on the left and the collab orators on the right -
Ambler [Amb95]
• Responsibilities are the attributes and operations that are relevant for
the class.
• Collaborators are those classes that are required to provide a class with
the information needed to complete a responsibility. In general, a
collaboration implies either a request for information or a request for
some action.

4. A CRC model index card

5. Classes
• Entity classes, also called model or business classes, are extracted
directly from the statement of the problem (e.g., FloorPlan and
Sensor).
• Boundary classes are used to create the interface (e.g., interactive
screen or printed reports) that the user sees and interacts with as the
software is used.
• Controller classes manage a “unit of work” [UML03] from start to
finish.

6. Controller classes
• (1) the creation or update of entity objects,
• (2) the instantiation of boundary objects as they obtain information
from entity objects,
• (3) complex communication between sets of objects,
• (4) validation of data communicated between objects or between the
user and the application.

7. Responsibilities
1. System intelligence should be distributed across classes to best
address the needs of the problem.
2. Each responsibility should be stated as generally as possible.
3. Information and the behavior related to it should reside within the
same class.
4. Information about one thing should be localized with a single class,
not distributed across multiple classes.
5. Responsibilities should be shared among related classes, when
appropriate.

8. Collaborations [Wir90]
• Collaborations represent requests from a client to a server in
fulfillment of a client responsibility. A collaboration is the
embodiment of the contract between the client and the server.
• We say that an object collaborates with another object if, to fulfill a
responsibility, it needs to send the other object any messages.
• A single collaboration flows in one direction—representing a request
from the client to the server. From the client’s point of view, each of
its collaborations is associated with a particular responsibility
implemented by the server.

9. • To help in the identification of collaborators, you can examine three
different generic relationships between classes [Wir90]:
(1) the is-part-of relationship,
(2) the has-knowledge-of relationship, and
(3) the depends-upon relationship.

10. A composite aggregate class

11. Associations and Dependencies
Multiplicity
Dependencies

12. Analysis Packages

13. Quality of design
• Quality of design refers to the characteristics that designers specify
for a product.
• The grade of materials, tolerances, and performance specifications all
contribute to the quality of design.
• As higher-grade materials are used, tighter tolerances and greater
levels of performance are specified, the design quality of a product
increases, if the product is manufactured according to specifications.

14. Design patterns
• To show how system modeling and architectural design are put into
practice in developing an object-oriented software design.
• To introduce important implementation issues that are not usually
covered in programming books. These include software reuse,
configuration management, and open source development.

15. Object-oriented design using the UML
1. Understand and define the context and the external interactions with
the system.
2. Design the system architecture.
3. Identify the principal objects in the system.
4. Develop design models.
5. Specify interfaces.

16. Design patterns
• Design patterns were derived from ideas put forward by Christopher
Alexander (Alexander et al., 1977), who suggested that there were
certain common patterns of building design that were inherently
pleasing and effective.
• The pattern is a description of the problem and the essence of its
solution, so that the solution may be reused in different settings.
• The pattern is not a detailed specification. Rather, you can think of it
as a description of accumulated wisdom and experience, a well-tried
solution to a com mon problem.

17. Multiple displays

18. The four essential elements of design patterns were
defined by the ‘Gang of Four’ in their patterns book:
1. A name that is a meaningful reference to the pattern.
2. A description of the problem area that explains when the pattern may be
applied.
3. A solution description of the parts of the design solution, their
relationships, and their responsibilities. This is not a concrete design
description. It is a template for a design solution that can be instantiated in
different ways. This is often expressed graphically and shows the relationships
between the objects and object classes in the solution.
4. A statement of the consequences—the results and trade-offs—of applying
the pattern. This can help designers understand whether or not a pattern can
be used in a particular situation.

19. • 1. Tell several objects that the state of some other object has changed
(Observer pattern).
• 2. Tidy up the interfaces to a number of related objects that have
often been developed incrementally (Façade pattern).
• 3. Provide a standard way of accessing the elements in a collection,
irrespective of how that collection is implemented (Iterator pattern).
• 4. Allow for the possibility of extending the functionality of an existing
class at run-time (Decorator pattern).

20. Implementation issues – Reuse
Software reuse is possible at a number of different levels:
1. The abstraction level
2. The object level
3. The component level
4. The system level
Cost factor of Reuse
5. The costs of the time spent in looking for software to reuse and assessing whether or not it
meets your needs.
6. Where applicable, the costs of buying the reusable software.
7. The costs of adapting and configuring the reusable software components or systems to reflect
the requirements of the system that you are developing.
8. The costs of integrating reusable software elements with each other (if you are using software
from different sources) and with the new code that you have developed.

21. Implementation issues – Configuration
management
• 1. Version management, where support is provided to keep track of
the different versions of software components.
• 2. System integration, where support is provided to help developers
define what versions of components are used to create each version
of a system.
• 3. Problem tracking, where support is provided to allow users to
report bugs and other problems, and to allow all developers to see
who is working on these prob lems and when they are fixed.

22. Implementation issues – Host-target
development
• A software development platform should provide a range of tools to
support soft ware engineering processes. These may include:
• 1. An integrated compiler and syntax-directed editing system that
allows you to create, edit, and compile code.
• 2. A language debugging system.
• 3. Graphical editing tools, such as tools to edit UML models.
• 4. Testing tools, such as JUnit (Massol, 2003) that can automatically run
a set of tests on a new version of a program.
• 5. Project support tools that help you organize the code for different
development projects.