Le decisioni sull'assegnazione delle responsabilità agli oggetti possono essere prese mentre si esegue la codifica oppure durante la modellazione. Nell'ambito di UML, il disegnare i diagrammi di interazione diventa l'occasione per considerare tali responsabilità (realizzate come metodi).

La figura mostra che agli oggetti Sale è stata assegnata la responsabilità di creare oggetti CashPayment; questa responsabilità viene concretamente richiamata con un messaggio makeCashPayment e gestita con un corrispondente metodo makeCashPayment. Inoltre, l'adempimento di questa responsabilità richiede una collaborazione per creare l'oggetto CashPayment e chiamare il suo costruttore.

Pertanto, mentre si disegna un diagramma di interazione di UML vanno prese delle decisioni riguardo all'assegnazione di responsabilità. Il disegno deve poi illustrare le scelte di progetto fatte.

Il salto rappresentazionale basso (Low Rapresentational Gap - LRG) sostiene l'assegnazione di responsabilità guidata dal nostro modello mentale di dominio, e favorisce la comprensibilità del progetto e del codice. In pratica, un modo di ottenere un salto rappresentazionale basso è quello di utilizzare il modello di dominio come fonte di ispirazione per la progettazione dello strato del dominio, ovvero scegliere nel progetto classi software il cui nome è ispirato a classi concettuali del modello di dominio.

Tuttavia, è importante osservare che un salto rappresentazionale basso non garantisce che la complessità del sistema possa essere gestita facilmente. Per esempio, LRG non garantisce modificabilità ed estendibilità del software, che sono obiettivi di progettazione importanti. Piuttosto, è necessario fare riferimento anche a principi di progettazione più solidi, come per esempio proprio i pattern GRASP.

Anche se è utile che il salto rappresentazionale sia basso, allo stesso modo non è opportuno che tale salto sia nullo: un progetto OO non può essere ottenuto come la traduzione automatica in software del modello di dominio. Infatti in un progetto OO sano, ci saranno certamente diverse classi software ispirate alle classi concettuali del modello di dominio, ma anche classi software artificiali, che non hanno nessuna corrispondenza nel modello di dominio.

I GRASP definiscono nove principi di progettazione orientata agli oggetti di base.

• Creator
• Information Expert
• Low Coupling
• Controller
• High Cohesion
• Pure Fabrication
• Polymorphism
• Indirection
• Protected Variations

I pattern GRASP sono delle generalizzazioni che lasciano la possibilità di scovare pattern più specifici come i pattern GoF (Gang-of-Four discussi nel libro Design Patterns), ne vediamo alcuni, in maniera superficiale in modo tale da poter essere approfonditi nel libro menzionato sopra, per una discussione più completa:

• Adapter
• Factory
• Singleton
• Strategy
• Composite
• Facade
• Observer