TAILIEUCHUNG - Software design and architecture (Lecture Notes) – Chapter 22

Lecture 22 – Class responsibility collaboration cards. This chapter presents the following content: Class responsibility collaboration cards, responsibilities and collaborations, knowing responsibilities, doing responsibilities. | Lecture Notes Lecture 22 – CLASS RESPONSIBILITY COLLABORATION CARDS CLASS RESPONSIBILITY COLLABORATION CARDS Class-Responsibility-Collaboration cards, most commonly called CRC cards, are used to document the responsibilities and collaborations of a class. RESPONSIBILITIES AND COLLABORATIONS The responsibilities of a class can be divided into two separate types: knowing and doing. Knowing responsibilities are those things that an instance of a class must be capable of knowing. An instance of a class typically knows the values of its attributes and its relationships. Doing responsibilities are those things that an instance of a class must be capable of doing. In this case, an instance of a class can execute its operations, or it can request a second instance that it knows about to execute one of its operations on behalf of the first instance. The structural model describes the objects necessary to support the business processes modeled by the use cases. Most use cases involve a set of several classes, not just one class. This set of classes forms a collaboration. Collaborations allow the analyst to think in terms of clients, servers, and contracts. A client object is an instance of a class that sends a request to an instance of another class for an operation to be executed. A server object is the instance that receives the request from the client object. A contract formalizes the interactions between the client and server objects. For example, a patient makes an appointment with a doctor. This sets up an obligation for both the patient and doctor to appear at the appointed time. Otherwise, consequences, such as billing the patient for the appointment regardless of whether the patient appears, can be dealt out. The contract should also spell out what the benefits of the contract will be, such as a treatment being prescribed for whatever ails the patient and a payment to the doctor for the services provided.

• Kỹ thuật lập trình
• Software design
• Software design and architecture
• Software architecture
• Software architectural design
• Object oriented design
• Software development
• Class responsibility collaboration cards
• Software design methods
• Distributed software architecture
• Data flow software architecture
• Software requirement specification
• Software development activities
• Component based software engineering