GRASP Patterns

These notes are taken from Craig Larman’s brilliant book “Applying UML And Patterns”. There is so much information in this book, you really need to work through it in its entirety. Still, it’s good to have a brief refresher of some key points. I hope you may find these notes useful.

General Responsibility Assignment Software Patterns or Principles

1 – Information Expert

A general principle of object design and responsibility assignment?

Assign a responsibility to the information expert – the class that has the information necessary to fulfill the responsibility.

2 – Creator

Who creates? (Note that Factory is a common alternative solution.)

Assign class B the responsibility to create an instance of class A if one of these is true:

1. B contains A
2. B aggregates A
3. B has the initializing data for A
4. B records A
5. B closely uses A

3 – Controller

What first object beyond the UI layer receives and coordinates (‘controls’) a system operation?

Assign the responsibility to an object representing one of these choices:

1. Represents the overall ‘system’, a ‘root object’, a device that the software is running within, or a major subsystem (these are all variations of a façade controller).
2. Represents a use case scenario within which the system operation occurs (a use-case or session controller)

4 – Low Coupling

How to reduce the impact of change?

Assign responsibilities so that (unnecessary) coupling remains low. Use this principle to evaluate alternatives.

5 – High Cohesion

How to keep objects focused, understandable, and manageable, and as a side-effect, support
Low Coupling?

Assign responsibilities so that cohesion remains high. Use this to evaluate alternatives.

6 – Polymorphism

Who is responsible when behavior varies by type?

When related alternatives or behaviors vary by type (class), assign responsibility for the behavior – using polymorphic operations – to the types for which the behavior varies.

7 – Pure Fabrication

Who is responsible when you are desperate, and do not want to violate high cohesion and low coupling?

Assign a highly cohesive set of responsibilities to an artificial or convenience ‘behavior’ class that does not represent a problem domain concept – something made up, in order to support high cohesion, low coupling, and reuse.

8 – Indirection

How to assign responsibilities to avoid direct coupling?

Assign the responsibility to an intermediate object to mediate between other components or services, so that they are not directly coupled.

9 – Protected Variations

How to assign responsibilities to objects so that the variations or instability in these elements do not have an undesirable impact on other elements?

Identify points of predicted variation or instability; assign responsibilities to create a stable ‘interface’ around them.

Risk-Driven and Client-Driven Iterative Planning

Encourage a combination of risk-driven and client-driven iterative planning. This means that the goals of the early iterations are to:

1. identify and drive down the highest risks, and
2. build visible features that the client cares most about

Risk-driven development includes more specifically the practice of architecture-centric iterative development, meaning that early iterations focus on building, testing, and stabilizing the core architecture. Why? Because not having a solid architecture is a common high risk.

Note: I would consider non-functional requirements another risk worth prioritizing.

Requirements

manage requirements…a systematic approach to finding, documenting, organizing, and tracking the changing requirements of a system.

Types and Categories of Requirements

• Functional – features, capabilities, security
• Usability – human factors, help, documentation
• Reliability – frequency of failure, recoverability, predictability
• Performance – response times, throughput, accuracy, availability, resource usage
• Supportability – adaptability, maintainability, internationalization, configurability
• Implementation – resource limitations, languages and tools, hardware, …
• Interface – constraints imposed by interfacing with external systems
• Operations – system management in its operational setting
• Packaging – deployment, distribution, sales considerations, etc.
• Legal – licensing and so forth

Requirements are categorized as functional (behavioral) or non-functional (everything else).

Note: Pay early attention to non-functional requirements, and beware of integration with other systems. Both of these areas can seriously blow out the budget and timeline.

Domain Rules

Domain rules dictate how a domain or business may operate. They are not requirements of any one application, although an applications requirements are often influenced by domain rules. Company policies, physical laws (such as how oil flows underground), and government laws are common domain rules.

They are commonly called business rules.

It’s useful to identify and record domain rules in a separate application-independent artifact. The rules can help clarify ambiguities in the use cases.

Actors

An actor is anything with behavior, including the system under discussion itself when it calls upon the services of other systems. Actors are roles played not only by people, but by organizations, software, and machines. There are three kinds of external actors:

• Primary actor – has user goals fulfilled through using the services of the system, for example the cashier
• Supporting actor – provides a service, for example an authorization service
• Offstage actor – has an interest in the system but is not a primary or supporting actor, for example a tax agency

Domain Model

During object-oriented analysis there is an emphasis on finding and describing the object – or concepts – in the problem domain. For example, in the case of a flight information system, some of the concepts include Plane, Flight and Pilot.

There is an emphasis on defining software objects and how they collaborate to fulfill the requirements.

Object-oriented analysis is concerned with creating a description of the domain from the perspective of objects. There is an identification of the concepts, attributes, and associations that are considered noteworthy. These are often captured in a domain model, which is not a description of software objects, but a visualization of the concepts or mental models of a real-world domain. It is also called a conceptual object model.

The purpose of modeling is primarily to understand, not to document.

A domain model is the most important – and classic – model in OO analysis. It is illustrated with a set of class diagrams in which no operations are defined. It provides a conceptual perspective. It may show:

• domain objects or conceptual classes
• associations between conceptual classes
• attributes of conceptual classes

The domain model describes real-situation concepts:

Not software objects:

The domain model illustrates conceptual classes or vocabulary in the domain. Informally, a conceptual class is an idea, thing, or object. More formally, a conceptual class may be considered in terms of its symbol, intention, and extension:

• Symbol – words or images representing a conceptual class
• Intension – the definition of a conceptual class
• Extension – the set of examples to which the conceptual class applies

A motivation for using a domain model is to lower the representational gap with OO modeling.

Use software class names in the domain layer inspired by names in the domain model, with objects having domain-familiar information and responsibilities. This supports a low representation gap between our mental and software models.

Note: See Evans Ubiquitous language in Domain Driven Design.

Three strategies to find conceptual classes:

1. Reuse or modify existing models – see Analysis Patterns by Fowler, etc.
2. Use a category list
3. Identify noun phrases

Example Category List

Conceptual Class Category List	Examples
business transactions Guideline: These are critical (they involve money), so start with transactions.	Sale, Payment Reservation
transaction line items Guideline: Transactions often come with related line items, so consider these next.	SalesLineItem
product or service related to a transaction or transaction line item Guideline: Transactions are for something (a product or service). Consider these next.	Item Flight, Seat, Meal
where is the transaction recorded? Guideline: Important.	Register, Ledger FlightManifest
roles of people or organizations relates to the transactions; actors in the use case Guideline: We usually need to know about the parties involved in a transaction.	Cashier, Customer, Store Player Passenger, Airline
places of transaction; place of service	Store Airport, Plane, Seat
noteworthy events, often with a time or place we need to remember	Sale, Payment Game Flight
physical objects Guideline: This is especially relevant when creating device-control software, or simulations.	Item, Register Board, Piece, Die Airplane
descriptions of things	ProductDescription FlightDescription
catalogs Guideline: Descriptions are often in a catalog.	ProductCatalog FlightCatalog
containers of things (physical or information)	Store, Bin Board Airplane
things in a container	Item Board Passenger
other collaborating systems	CreditAuthorizationSystem AirTrafficController
records of finance, work, contracts, legal matters	Receipt, Ledger MaintenanceLog
financial instruments	Cash, Check, LineOfCredit TicketCredit
schedules, manuals, documents that are regularly referred to in order to perform work	DailyPriceChangeList RepairSchedule

Another useful technique is linguistic analysis. Identify the nouns and noun phrases in textual descriptions of a domain, and consider them as candidate conceptual classes or attributes.

For example, here is an initial list of candidate conceptual classes for a POS domain:

• Scale
• CashPayment
• SalesLineItem
• Item
• Register
• Ledger
• Cashier
• Customer
• Store
• ProductDescription
• ProductCatalog

Draw a UML class diagram of the conceptual classes are you uncover them:

Think like a Mapmaker: Use Domain Terms

Make a domain model in the spirit of how a cartographer or mapmaker works:

• Use the existing names in the territory. For example, if developing a model for a library, name the customer a Borrower – the term used by the library staff
• Exclude irrelevant or out-of-scope features
• Do not add things that are not there

Associations

It is useful to find and show associations that are needed to satisfy the information requirements of the current scenarios under development, and which aid in understanding the domain.

Relate conceptual classes with an association, not with an attribute.

Responsibility Driven Design (RDD)

A popular way of thinking about the design of software objects and also large scale components is in terms of responsibilities, roles, and collaborations. This is part of a larger approach called responsibility driven design (RDD).

In RDD, we think of software objects as having responsibilities – an abstraction of what they do. Responsibilities are related to the obligations or behavior of an object in terms of its role:

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

Responsibilities are assigned to classes of objects during object design.

The translation of responsibilities into classes and methods is influenced by the granularity of the responsibility. Big responsibilities take hundreds of classes and methods. Little responsibilities might take one method.

A responsibility is not the same thing as a method – it’s an abstraction – but methods fulfill responsibilities.

RDD also includes the idea of collaboration. Responsibilities are implemented by means of methods that either act alone or collaborate with other methods and objects.

Conclusion

This book is a veritable tome, these notes only touch the surface of the wisdom contained therein.

I deliberately avoided a lot of the discussion on class diagrams, UML, and OOAD as many of those topics are covered in other notes I’ve posted on this blog.

This really is an excellent reference book, I highly recommend it.

Advertisement