BTS430 Systems Analysis and Design using UML Design Patterns

Patterns  “… a pattern is a named problem/solution pair that can be applied in new contexts, with advice on how to apply it in novel situations and discussion of its trade- offs.” * *Larman, page 218

Design Patterns  “ The best way to use patterns is to load your brain with them and then recognize places in your design and existing applications where you can apply them. Instead of code reuse, with patterns you get experience reuse.”* * Head First Design Patterns, p. xi

References for Pattern theory  The “Bible” Design Patterns, Elements of Reusable Object-Oriented Software  Erich Gamma  Richard Helm  Ralph Johnson  John Vlissides Authors known as the Gang of Four so the patterns are called the GoF patterns First book – 1995 Most complete

References for Pattern theory  Head First Design Patterns Eric Freeman and Elisabeth Freeman (“must have” for BTS530 and 630)  Applying UML and Patterns, third edition Craig Larman

Beginnings of Patterns  Started with Christopher Alexander, a Professor of Architecture at Berkeley. Invented patterns for building living architectures, e.g., houses, towns, cities Books: The Timeless Way of Building and A Pattern Language Direct analogies between creating “living architecture” and flexible, extensible software* *Head First Design Patterns, p. 602

GRASP Patterns  “ A learning aid to help you understand essential object design and apply design reasoning in a methodical, rational, explainable way ”. *  Patterns of assigning object responsibilities * Larman, p. 277

GRASP Patterns  “ GRASP is an acronym that 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 Larman, p. 222

GRASP Patterns  Do not state new ideas  Name and codify widely used basic principles* * Larman, p. 279

Responsibilities  UML defines a responsibility as “a contract or obligation of a classifier”.  A class embodies a set of responsibilities that define the behaviour of the objects in the class.

Responsibilities  “A responsibility is not the same thing as a method, but methods are implemented to fulfill responsibilities.”  “Responsibilities are implemented using methods that either act alone or collaborate with other methods and objects.” Larman, p. 217

Fig. 17.2: Responsibilities and methods are related Implies Sale objects have a responsibility To create Payments

Responsibilities revolve around  Doing  Knowing  Collaboration

“Doing” responsibilities  Doing something itself, such as creating an object or doing a calculation  Initiating action in other objects  Controlling and co-coordinating activities in other objects Larman, p. 216

“Knowing” responsibilities  Knowing about private encapsulated data  Knowing about related objects  Knowing about things that it can derive or calculate  Larman, p. 216

GRASP Patterns  Key three: Creator Controller Information Expert

Creator  Who should be responsible for creating an new instance of some class?  Some options: Assign B the responsibility to create A if one or more of the following is/are true:  B “contains” A (e.g. Invoice creates InvoiceLineItem)  B records A  B closely uses A  B has the initializing data for A that will be passed to A when it is created (thus B is the Expert with respect to creating A). (e.g. Sale creates Payment) p. 291

Creating a SalesLineItem

Controller  What first object beyond the UI layer receives and coordinates a system operation? Use Case or Session Controller  Use case/session (e.g. Register)* Larman, p. 286 and 302

Guidelines/Issues  Controller usually delegates work to other objects—it controls, coordinates, it does not do much work itself  Danger: Bloated controller a single controller receives all system events (and there are many) a controller that does the work itself a controller that has many attributes; maintains significant information  Among Cures for Bloat more controllers, use case controllers, more delegation

Information Expert  What is the general principle of assigning responsibilities to objects?  A Solution: Assign a responsibility to the class that has the information necessary to fulfill it—the “information expert” (note: start this process by clearly stating the responsibility!) Larman, p. 294

Information Expert  Example: Sale has the responsibility of knowing its total, expressed with the method named getTotal Larman, p. 222

Information Expert p. 222

Collaboration  Fulfillment of a responsibility often requires information from different classes of objects  Example, sales total requires the collaboration of 3 classes of objects: Sale, SalesLineItem, ProductDescription  Interact via messages* *Larman, p. 297

Facade  Hides all of the complexity of one or more classes in a simple interface*  Provides a simplified interface to a subsystem while still exposing the full functionality of the system to those who may need it* *Head First Design Patterns, p. 254 *Head First Design Patterns, p. 260

Database Facade