GRASP

GRASP stands for General Responsibility Assignment Software Patterns. The name was chosen to suggest the importance of //grasping// these principles to successfully design object-oriented software.

Understanding and being able to apply the ideas behind GRASP, while coding or drawing interaction and class diagrams, are essential when designing OO systems. They form a foundation for designing OO Systems. The critical design tool for software development is a mind well educated in design principles. It's not the UML or any other technology.

GRASP Patterns

 * Creator (GRASP)
 * Information Expert (GRASP)
 * Low Coupling (GRASP)
 * Controller (GRASP)
 * High Cohesion (GRASP)
 * Polymorphism (GRASP)
 * Indirection (GRASP)
 * Pure Fabrication (GRASP)
 * Protected Variations (GRASP)

Input to Object Design

 * Use case text:** Defines the visible behavior that the software objects must ultimately support. Objects are designed to realize (implement) the use cases. This is also called the //use case realization//.


 * Supplementary Specification:** Defines the non-functional goals, such as internalization, our objects must satisfy.


 * System Sequence Diagram:** Identifies the system operation messages, which are the starting messages on our interaction diagrams of collaborating objects.


 * Glossary:** Clarifies details of parameters or data coming in from the UI layer, data being passed to the database, and detailed item-specific logic or validation requirements, such as the legal formats and validation for product UPCs.


 * Operation Contracts:** May complement the use case text to clarify what the software objects must achieve in a system operation. The postconditions define detailed achievements.


 * Domain Model:** Suggests some names and attributes of software domain objects in the domain layer of the software architecture.

Given one or more of these inputs, developers
 * 1) start immediately coding (ideally with //test-first development//)
 * 2) start some UML modeling for the object design, or
 * 3) start with another modeling technique, such as CRC cards.

During this work we draw both interaction diagrams and complementary class diagrams (dynamic and static modeling), applying various OO design principles such as //GRASP// and the //GoF design patterns//. The overall approach to doing the OO design modeling will be based on the metaphor of //responsibility-driven design// (RDD), thinking about how to assign responsibilities to collaborating objects.

GRASP is relevant, but it's just a learning aid to structure and name the principles. Once you "grasp" the fundamentals, the specific GRASP terms (Information Expert, Creator, ...) aren't important.

Responsibility-Driven Design
Think about the design of software objects in terms of //responsibilities//, //roles//, and //collaborations//. This is part of a larger approach called //responsibility-driven design// or RDD, and can apply at any scale of software - from a small object to a system of systems. RDD leads to viewing an OO design as a //community of collaborating responsible objects//.

In RDD, think of software objects as having responsibilities, related to the obligations or behavior of an object in terms of its role. Basically, these responsibilities are of the following two types - //doing// and //knowing//. For software domain objects, the domain model often inspires the relevant responsibilities related to "knowing".


 * Doing** responsibilities of an object include:
 * Doing something itself, such as creating an object or doing a calculation.
 * Initiating action in other objects.
 * Controlling and coordinating activities in other objects.


 * Knowing** responsibilities of an object include:
 * Knowing about private encapsulated data.
 * Knowing about related objects.
 * Knowing about things it can derive or calculate.


 * Patterns:** In OO design, a pattern is a named description of a problem and solution that can be applied to new contexts. Ideally, a pattern advises us on how to apply its solution in varying circumstances and considers the forces and trade-offs. Many patterns guide the assignment of responsibilities to objects.

In UML, draw parallel complementary dynamic and static object models, both a partial sequence diagram and a class diagram that reflect this design decision where the GRASP pattern is applied.