Open navigation menu
Close suggestions
Search
Search
en
Change Language
Upload
Sign in
Sign in
Download free for days
0 ratings
0% found this document useful (0 votes)
23 views
8 pages
Scan 0001
OOMD Chapter 4 scan number 1
Uploaded by
NALE SVPMEngg
AI-enhanced title
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content,
claim it here
.
Available Formats
Download as PDF or read online on Scribd
Download
Save
Save scan0001 For Later
0%
0% found this document useful, undefined
0%
, undefined
Embed
Share
Print
Report
0 ratings
0% found this document useful (0 votes)
23 views
8 pages
Scan 0001
OOMD Chapter 4 scan number 1
Uploaded by
NALE SVPMEngg
AI-enhanced title
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content,
claim it here
.
Available Formats
Download as PDF or read online on Scribd
Carousel Previous
Carousel Next
Download
Save
Save scan0001 For Later
0%
0% found this document useful, undefined
0%
, undefined
Embed
Share
Print
Report
Download now
Download
You are on page 1
/ 8
Search
Fullscreen
Artem MLC CAECUM ELLE General Responsibility Assignment Software Pattern (GRASP) ‘+ Definition : General Responsibility Assignment Software Patterns (or Principles) or GRASP consists of guideline required for designing an object. «The different patterns and principles used in GRASP are : Creator, Information Expert, Controller, Low Coupling, High Cohesion and so on. + Responsibility. Driven Design (RDD) : The design of objects for a large system is done in terms of responsibilities, roles and collaborations. This approach is called Responsibility-Driven-Design (RD). + Responsibilities are the aggregation of objects in terms of its behavior. In UML, while designing the interaction diagram the responsibilities can be assigned to the object. In UML terminology these responsibilities are called the methods. «Definition of pattern - The pattern can be defined as a named and well-known problem solution pair which can be applied in new context, and guides on how to apply it in current situations and discussion of its trade-offs, implementations, variations and 50 on. + Various patterns suggested by GRASP are - Creator, Information Expert, Low Coupling, Controller, High Cohesion and so on. Let us discuss them in detail Creator Problem Who should create an instance of a new class ? Sol. :. Consider assigning class B the responsibility to create an instance of class A if one of the following is true - 1. Class B contains A. 2, Class B aggregates A. 3. Class B records A. 4, Class B closely uses A. Thus B is a creator of instances of class A. Example In library management system, when a book is added in the library the catalog is updated by its title. Then the creator pattern can be applied as follows - +#Create(Bcok) Fig. 5.21 Creator pattern Another example of creator pattern is - When we want to add the records in the database then the table creates a new instance for the Datarow. Using this instance the record can be added in the table at the next row.Discussion : Creation of objects is a common task in object oriented system and this task is guided by the creator pattern. The basic goal of Creator pattern is to find a creator that needs to be connected to the created object in any event. Various common relationships between the ciasses of the class diagram are aggregates, contains and records. In other words connect an object to its creator when - + Aggregator aggregates part ‘Container contains content Recorder records ‘Initializing data passed to it during creation. Composition is an excellent candidate considered by the Creator pattem for creating object. (Contraindications : Sometimes creation of object involves si complexity. In such a situation it is preferred to create object using Concrete Factory or Abstract Factory. Benefits : Creator Pattern supports low coupling. Due low coupling there are less dependencies between the objects and the objects become more reusable. Related Patterns or Principles : + Low coupling. + Abstract Factory. ‘ Aggregation and composition. | Review Questions: | @1. Explain the need for eretor pattern, Q2 Describe the concept of creator. | [53] information Expert Problem What is the basic principle responsibilities to objects ? Sol.: Assign a responsibility to the class that has the information needéd to respond to it. Such a class is known as Information Expert. of assigning Example In the ATM system application, the some class ‘might need to know the account balance. While finding the information expert make use of the principle - ” Start assigning the responsibilities by clearly stating the responsibility”. Using this principle following question can be asked - ” Who is responsible for knowing the balance amount” By information expert we should look for the class of the objects that need balance amount. Now in order to know the balance amount we need to know - 1) The account number of the customer whose balance amount must be known. 2) The transactions made by the same customer till date. Obviously this information might be available to the class Bank. For finding out the information expert in this context, the interaction diagram is designed. A partial interaction diagram and the class diagram is as shown below - |?GetBatancelntonFor the information that we need to determine the account balance? Account Number and Transaction made so far. Therefore by information expert the Bank class will return the Account number of the desired customer because it managed the Account class. 1 Gatbalancone p=] Fig, 6.3.3 Information expert pattern Discussion : Information expert is used for assigning the responsibilities. But for the fulfillment of the responsibilities the 2ccess to the information which is spread across the clas.s is needed. This implies that the partial information experts will collaborate to perform some task. For example for knowing the balance amount the classes like Customer, Bank and Account work in collaboration. Whenever information is spread across different objects they will need to interact via messages to share the work. Contraindications : Information expert may contradict the low coupling and high cohesion pioperties in the dgsign. The basic architectural principle of keeping the core logic/systems separate may get violated due to information expert. Benefits : 1) It supports the information encapsulation because objects posses their own information in order to perform the responsibilities, 2) It supports low coupling because of which system becomes more maintainable. 3) The behaviour in distributed across the classes. that need the related information. This helps in designing of the lightweight class definition. 4) High cohesion is supported. Related Patterns or Principles : ‘* Low coupling ‘* High cohesion | Review Question | | 1 Explain the information expert pattern with | some illustrative example. | 5.4 | Low Coupling Coupling is a measure of how strongly one object is connected to, knowledge of or dependant upon the other object. An element with low coupling is not dependant upon too many objects. The classes with high coupling rely upon many classes and it leads to various problems Problems + How to reduce the impact of changes ? + How to understand the iolated object ? ‘+ How to reuse the object which is dependant upon another object’? Sol. : Assign the responsibilities to the objects in such a way that the coupling between the objects remain low. Example Consider the clases in the ATM System - Fig. 8.4.4 Assume that the customer wants to withdraw money. The Creator patiern suggest that there should be therelationship between Customer, ATMSystem and Transaction. If these classes are related to each other by the relationship as shown in Fig. 542 (a) then it indicates that the Customer must have the knowledge of both the ATMSystem class and the Transaction class. ‘This leads to poor design. But as shown in Fig. 5.4.2 (b) if the Customer is related to the ATMSystem class and the ATMSystem class performs the desired transaction then it leads to low coupling. TL Ee: = ERT] 2: Whew 0) —— (a) Customer creates transaction 1 Enter PINTS (0) ATMsystem creates transaction Fig. 64.2 Low coupling Discussion : In object oriented languages common forms of coupling between class A and class B is - When class A has an attribute which refers the instance of class B. # Class A object calls upon the service of class B object. #Class A is inherited from class B. «The class A has a method that refers the instance of class B. +-Class B is an interface and if class A implements that interface. Low coupling ericourages assigning of responsibilities to independent classes. Due to this there is no impact of changes made in one class to other class. There is no exact measure of coupling but in general the generic classes or the classes that can be reused frequently should have low coupling. * Contraindication : High coupling to stable classes create the problems in the system design. Benefits : Following are the benefits of low coupling - # Impact of changes can be reduced. ‘* The objects can be understood easily in isolation. The reusability of objects is convenient. | | | | | Review Questions | Q1 Define coupling. | @.2 Explain the concept of low coupling with some | | suitable example. [5] controtier A simple layered architecture has a User Interface Layer at the top and then comes the domain layer. The user interacts with the Ul layer and generate UI events by pressing button, or clicking menu and so on. The UI software objects must process the event and cause the execution of the desired process. For example when the user clicks on the slide show button of Presentation software then, the transition of slides one after the other starts . These are known as the system operations. When user generates some event using the UI objects then there is a first object beyond the UI layer who handles these events. This object is called controller. Problem What first object beyond the UI layer that receives and co-ordinates a systemt operation ? Sol. : Assign the responsibility of controller to an object representing one of the following choices - © Represent overall system or root object or a device which is running within a major subsystem. These choices of controller are called facade controller. «Represent the use case scenario within which some events occur as the controller. Such controller are often named as Handler or Coordinator or Session. Example In the ATMSystem the controller can be Card Reader object. This is the first object that handles the requests after inserting the card in the ATMSystem, Gard Reader =ATMID *CaidReaden) +ReadCard)) ‘4EjectCardl) +RetainCard) Fig. 6. During the analysis, some system operations might be assigned to this controller object.Fig. 5.5.2 ‘The controller Card Reader will handle the enterPIN. Discussion : Normally’ the UI layer objects delegate the work request to domain layer. The controller pattern collects all those work requests from the domain objects. Hence controller is a kind of facade into the domain layer from UI layer. ‘The controller object co-ordinates or controls the activity. It does not do the work itself. Benefits : . « By delegating the system operations responsibilities to the controller supports the concept of reusability. elf the responsibility of controller is handled in an interface object then it is possible to develop the pluggable interfaces. ‘« For occurring the system operations in some specific sequence use of controller pattern is a reasonable choice. Related patterns : ‘Command - In message handling system, each message is handled using separate command object. Fagade - Facade pattern is an object that provides the interface in a large sub-system. When “the client class wants to communicate to the subsystem classes then instead of having direct communication, the client class communicates with the facade interface and then this interface delegates the request to the subsystem classes. For example Layers - According to layers pattern, each layer contains some specific logic. For instance the UI layer contains the User Interface Logic. Subeyotem Class Cont class ean Subsystem Class C] Pure fabrication - This is a GRASP pattern which does not represent the concept in the problem domain. It is an arbitrary creation of designer for achieving low coupling, high cohesion and reusability. This pattern provide some service in domain design model. | Fig. 5.6.3, Review Questions | Q1 What is the controller pattern ? Explain it with | some suitable example. | Q2 Enlist the benefits of controller objec. | 3 What is GRASP ? Explain the following GRASP | patterns : Creator, information expert, low | | coupling, high cohesion and controller. | | a4 Explain crestor and controller design patterns | | Il with examples. 5.6 | High Cohesion ‘The word cohesion means "sticking together". In object oriented system cohesion is said to be a measure of relatedness of all the elements. These elements can be classes, subsystems and so on. Problem How to keep classes: focused, understandable and manageable ? Sol. : Assign the responsibilities in such a manner that the cohesion remains high.‘A class with low cohesion may camry many unrelated things or does the a lot of work. These classes might face following problems - + These classes are hard to understand. These classes are harder to reuse and finding out reusable elements from these classes is very difficult. * These classes are hard to maintain. Example Consider the ATM System, Discussion : The most common goal of effective design is high lcohesion and low coupling. The cohesion can be described from low to high lcohesion as follows - Very low cohesion : In this type of cohesion, classes are responsible for many things in unrelated areas. low cohesion : In this type of cohesion, classes have responsibilities for many things in related areas. g makeTransaction() F Customer The responsibilities ‘are delegated to other classes Design i | > Withdraw Money [> Deposit Fundy | > Balance Enquiry Moderate cohesion : In this type of cohesion, classes have sibilities for few things. ‘These responsibilities are related to the class but are not related to each other. High ‘cohesion : In this type of cohesion, the classes have responsibilities in one fundamental area. These responsibilities collaborate with other classes to accomplish the desired task. Contraindication : Following are few cases where low cohesion is justified - «The situation in which grouping of responsibilities or code into one class or component to simplify the maintenance by one person. + Sometimes it is desirable to create less cohesive server ‘objects that provide an interface for many operations of remote objects. In distributed environment the remote communication occurs and to avoid the overhead and performance implications associated with these remote objects it is desirable to create less ‘The responsibilty of "ATMSystem" include "Withdrawal", “deposition”, "enquiry’, - ‘These are unrelated responsibilities ‘that result in ow cohesioncohesive server objects that provide an interface for many operations. This approach is called Coarse-Grained Remote Interface. Benefits : 1) The high cohesion pattern often supports for low coupling. 2) The maintenance and modifications are simplified due to high cohesive elements. 3) Reusability can be achieved as the system elements focus the specific functionality. Example 5.6.1 Compare cohesion and coupling with suitable example. Reviow Questions Q.1 What is high cohesion ? Give exampie of it Q.2 What is GRASP ? Explain the design patterns | and the principles used in it, Q3 Explain about low coupling, controller and high | ‘cohesion. [7] Polymorphism - Poly means many and morph means form. In object oriented programming, the polymorphism is a mechanism that decides which object is responsible for handling the corresponding element. Problem How to handle related but varying elements ‘based on element type ?or How to design pluggable components ? Sol. (1) Use subslassing. (2) Make subclass objects responsible for their own behavior and (3) iet proper behavior be invoked automatically by subclass type. Example 8.7.1 Consider an application that computes the area of a shape. The shape can be Rectangle or circle, depending upon the parameters passed, the area of particular shape can be computed. Refer following that represents the polymorphisrs ‘Shape eo 4 Rectangle Triangle gsiarea Fig. 8.7.4 ‘The getarea() function varies from type of shape. Hence ‘the responsibility is assigned to the corresponding subclasses. By sending message to the Shape object, a call will be made to the corresponding sub class object - Rectangle or Triangle, Contraindication : Polymorphism is a powerful property of object-oriented programming. It is a technique that simplifies code rastically , when there are choices that the code must make. For example, if we were writing code for a calculation of area for the Shape, we might find that the code executed for Rectangle, Triangle or Circle will be different. | Without polymorphism we would have to use iftthen-else or switch statements to code the choice. JE we use polymorphism then for each particular shape, the code behaves in the correct way. Benefits : (1) It helps programmer to reuse the class once written, tested and implemented. 2) New implementations can be introduced without affecting other classes.Related Patterns : (1) Protected Variations 2) Adpater, Command, Composite, Proxy, State, and Strategy 5.8 | Pure Fabrication Problem Sometimes, during design, responsibilities need to be assigned that are not naturally attributable to any of the conceptual classes. Then how to assign these responsibilities? Sol. : Assign the responsibility to an artificial class that doesn't belong to domain class model. Most of the GoF Patterns the fabrication of new classes such as observer, adapter, abstract factory ete. Example In Payroll System, domain classes need to store information about employees. In order to do that one option is to assign data storage responsibilities to domain classes. But this option will reduce the cohesiveness of domain. classes as there will be more than one responsibilities that get assigned to domain classes. Other option is to introduce another class which does not represent any domain concept. In the Payroll System we can introduce a new class named PersistenceStorage. This class does not represent any domain entity. The only purpose of this class is to handle data storage functions. Therefore PersistenceStorage is a pure fabrication. Contraindications Sometimes the objects of pure fabrication can be overused . The software is decomposed or organized in terms of functionalities only. Sometimes functions behave just like objects. If overused, Pure fabrication could lead to too many behavior objects that have responsibilities not co-related with the required information. The data is simply passed from one object to another object. Benefits : (1) High cohesion is supported because responsibilities are factored into different classes. 2) Reusability of code. Related Patterns : (@) ‘Low coupling (2) High cohesion (3) All GoF patterns ‘such as Adapter, Command, Strategy 5.9 | indirection Problem How to assign responsibilities in order to remove direct coupling between two things ? Sol. : Assign the responsibility to an intermediate object placed between two components that are not directly When customer makes a peyment” to shop the CreditCardAuthorization class will talk to Modem devices. Persistencestorage! capes ‘Hingert_empinfo) (oes ++delete_empinfo() | ‘+update_empinfo() | This invokes low level API's. Fig. 5.8.41 | Customer ‘1 :makesPayment ae Shop [creditCardAuthorization) AuthorizePayment Ll.
You might also like
Ooad - Unit 4
PDF
No ratings yet
Ooad - Unit 4
36 pages
Design Model Relationships
PDF
No ratings yet
Design Model Relationships
13 pages
02 Grasp 1711367751647
PDF
No ratings yet
02 Grasp 1711367751647
41 pages
Unit 4: Grasp-Methodological Approach To Object Design
PDF
No ratings yet
Unit 4: Grasp-Methodological Approach To Object Design
18 pages
Grasp Patterns PDF
PDF
No ratings yet
Grasp Patterns PDF
30 pages
OOAD - Unit 4
PDF
No ratings yet
OOAD - Unit 4
37 pages
7- Chapter17V2(1)
PDF
No ratings yet
7- Chapter17V2(1)
44 pages
PDS_2_GRASP
PDF
No ratings yet
PDS_2_GRASP
83 pages
Lecture 9 2023
PDF
No ratings yet
Lecture 9 2023
46 pages
GRASP
PDF
No ratings yet
GRASP
8 pages
GRASP Pattern
PDF
No ratings yet
GRASP Pattern
76 pages
Module 4 first half
PDF
No ratings yet
Module 4 first half
37 pages
grasp pattern
PDF
No ratings yet
grasp pattern
35 pages
Unit 4 & 5
PDF
No ratings yet
Unit 4 & 5
7 pages
Class Diagram & GRASP Patterns
PDF
No ratings yet
Class Diagram & GRASP Patterns
63 pages
UNIT4
PDF
No ratings yet
UNIT4
17 pages
Unit 2
PDF
No ratings yet
Unit 2
43 pages
Unit 4
PDF
No ratings yet
Unit 4
49 pages
Lecture12 GRASP Designing Objects With Responsibilities, Information Expert
PDF
100% (1)
Lecture12 GRASP Designing Objects With Responsibilities, Information Expert
70 pages
GRASP Design Patterns: Designing Objects With Responsibilities
PDF
No ratings yet
GRASP Design Patterns: Designing Objects With Responsibilities
53 pages
6.unit 4
PDF
No ratings yet
6.unit 4
42 pages
SDA-Lect10-Fall2024-Class Diagrams, GRASP and SD
PDF
No ratings yet
SDA-Lect10-Fall2024-Class Diagrams, GRASP and SD
59 pages
UNIT4 (5)
PDF
No ratings yet
UNIT4 (5)
17 pages
GRASP - General Responsibility Assignment Software Patterns (Or Principles)
PDF
No ratings yet
GRASP - General Responsibility Assignment Software Patterns (Or Principles)
1 page
cs8592 Unit IV Unit 4 Notes
PDF
No ratings yet
cs8592 Unit IV Unit 4 Notes
27 pages
References:: - Applying UML and Patterns Craig Larman - Patterns in Java, Volume 2 Mark Grand
PDF
No ratings yet
References:: - Applying UML and Patterns Craig Larman - Patterns in Java, Volume 2 Mark Grand
76 pages
ATM Case (Week 7,8,9,10)
PDF
No ratings yet
ATM Case (Week 7,8,9,10)
13 pages
Chapter 3 1 DesignPattern PDF
PDF
No ratings yet
Chapter 3 1 DesignPattern PDF
80 pages
GRASP Principles
PDF
No ratings yet
GRASP Principles
56 pages
SE Units 3b 4 5 v3
PDF
No ratings yet
SE Units 3b 4 5 v3
49 pages
SAD - Ch8 - Design Principles
PDF
No ratings yet
SAD - Ch8 - Design Principles
47 pages
Design Principles GRASP SOLID
PDF
No ratings yet
Design Principles GRASP SOLID
28 pages
Lecture 03 (Complete)
PDF
No ratings yet
Lecture 03 (Complete)
76 pages
Ooad UNIT 4 Notes
PDF
50% (2)
Ooad UNIT 4 Notes
11 pages
Guidelines Use Case Analysis (Analysis Classes)
PDF
No ratings yet
Guidelines Use Case Analysis (Analysis Classes)
21 pages
Department of Computer Science & Engineering Object Oriented Analysis and Design Unit-Ii Design Patterns
PDF
No ratings yet
Department of Computer Science & Engineering Object Oriented Analysis and Design Unit-Ii Design Patterns
4 pages
Conceptual Design: Uml Class Diagram Relationships
PDF
No ratings yet
Conceptual Design: Uml Class Diagram Relationships
52 pages
Department of Computer Science & Engineering Cs6502-Object Oriented Analysis and Design Unit-Ii Design Patterns
PDF
No ratings yet
Department of Computer Science & Engineering Cs6502-Object Oriented Analysis and Design Unit-Ii Design Patterns
4 pages
Lecture 9 GRASP Designing Objects With Responsibilities Information Expert
PDF
No ratings yet
Lecture 9 GRASP Designing Objects With Responsibilities Information Expert
67 pages
Chapter 4
PDF
No ratings yet
Chapter 4
23 pages
Data Modeling
PDF
No ratings yet
Data Modeling
40 pages
Software Engineering Software Engineering: Readings Readings
PDF
No ratings yet
Software Engineering Software Engineering: Readings Readings
13 pages
Grasp
PDF
No ratings yet
Grasp
13 pages
Uml Class Diagrams
PDF
No ratings yet
Uml Class Diagrams
35 pages
Go Design Patterns
PDF
No ratings yet
Go Design Patterns
36 pages
Lecture 11 GRASP
PDF
No ratings yet
Lecture 11 GRASP
34 pages
UNIT IV OOAD PART 1
PDF
No ratings yet
UNIT IV OOAD PART 1
72 pages
Class Diagrams
PDF
No ratings yet
Class Diagrams
8 pages
L4.1 Class Diagram
PDF
No ratings yet
L4.1 Class Diagram
43 pages
Class Diagrams
PDF
No ratings yet
Class Diagrams
29 pages
OOSE Chapter Three
PDF
No ratings yet
OOSE Chapter Three
47 pages
APznzaZ5Ke7KIS4Lhqzrw4Fnq0AelR 9fTE2gWBvij5sseBplXzd3NSJKDmeqeaNVvfMePD7PFYspVJiczdblwctLqOCy3BjbSHaFjItBHTL3TWhe8HGKkOhZ60Dq0Ks6jeRpLA3rN465e2RoXWmbPPQ7JF 0Qmdg2IdhogEilMFgLF DSUeJ2FggmLgyEME7TM-DAY WjxwvSBis43Ef
PDF
No ratings yet
APznzaZ5Ke7KIS4Lhqzrw4Fnq0AelR 9fTE2gWBvij5sseBplXzd3NSJKDmeqeaNVvfMePD7PFYspVJiczdblwctLqOCy3BjbSHaFjItBHTL3TWhe8HGKkOhZ60Dq0Ks6jeRpLA3rN465e2RoXWmbPPQ7JF 0Qmdg2IdhogEilMFgLF DSUeJ2FggmLgyEME7TM-DAY WjxwvSBis43Ef
99 pages
Class Diagram
PDF
No ratings yet
Class Diagram
22 pages
Grasp - Unit 2
PDF
No ratings yet
Grasp - Unit 2
63 pages
Class Relationship
PDF
No ratings yet
Class Relationship
47 pages
Class Relationship
PDF
No ratings yet
Class Relationship
47 pages
ImageProcessing5 SpatialFiltering1
PDF
No ratings yet
ImageProcessing5 SpatialFiltering1
33 pages
Unit V - IOT
PDF
No ratings yet
Unit V - IOT
25 pages
Introduction To Data Structures
PDF
No ratings yet
Introduction To Data Structures
15 pages
TOC Solution Page 1
PDF
No ratings yet
TOC Solution Page 1
1 page
Deep Learning PPT Full Notes
PDF
No ratings yet
Deep Learning PPT Full Notes
105 pages
L10 - Intro - To - Deep - Learning
PDF
No ratings yet
L10 - Intro - To - Deep - Learning
75 pages
Chapter10-Activity Diagram
PDF
No ratings yet
Chapter10-Activity Diagram
16 pages