Kate Gregory

Week 8

• Midterm discussion

• Interaction / Sequence Diagrams

• Design Patterns

• RAII

• Lab 4

Date Week Topic Hand Out Due Back Test

6-Sep-13 1 Administrivia / Overview / Motivation, benefits of OO

13-Sep-13 2 Use Cases Lab 1: Use cases

20-Sep-13 3 CRC Cards, collab graphs Lab 2: CRC cards lab 1 5%

27-Sep-134 start class diag lab 2 5%

4-Oct-13 5 Finish class diag, Associations Lab 3: Class Diag

11-Oct-13 6 Inh & Polymorphism / midterm review lab 3 5%

18-Oct-13 7 midterm Midterm 25%

25-Oct-13 Reading Break

1-Nov-13 8 Interaction diag / Design Patterns Lab 4: Interaction Diag    

8-Nov-13 9 Good Design / Modules & Packages / Deployment and component diagrams /Metrics / SOLID

Lab 5: Critiques lab 4 5%

15-Nov-13 10 State diagrams / Activity diagrams / Summary and Conclusion / The Future

22-Nov-13 11 Critiques critique lab (before class) 15%

29-Nov-13 12 Critiques

TBD Final Exam Final 40%

Kate Gregory

Sequence Diagrams

• Also called interaction diagram and interaction sequence diagram

• Based on a use case instance

• Document the ways that objects co-operate

• Two dimensions:– down represents time passing– across represents different objects

Kate Gregory

Sample Sequence DiagramChecking AccountBank Client

ATMMachine

Account

Withdraw Checking Account

Withdraw Successful

Request Kind

Enter Kind

Request Amount

Enter Amount

Process Transaction

Transaction succeed

Dispense Cash

Request Take Cash

Take Cash

Request Continuation

Terminate

Print Receipt

Kate Gregory

Tips for Good Sequence Diagrams

• Give your objects good names– especially when two objects of the same class

are featured

• Record the parameters and return values being sent

• Refer to your use case often

Kate Gregory

Sequence Diagrams Clarify Responsibilities

• Invoice, Customer, and Line Item co-operate to print an invoice:

Kate Gregory

Return arrows clarify meaning

Kate Gregory

Show the flow of information

Kate Gregory

Lifetimes can vary

Design Patterns• Patterns provide

a mechanism for capturing and describing commonly recurring design ideas that solve a general design problem.

Kate Gregory

Singleton

• Classes (such as inventory or member list) must have one, and only one, object instance.

• Must be able to call a method and get either the new object, or if one already exists, a pointer to it.

Kate Gregory

Singleton

• Make the constructor of the class private – not accessible outside of the class structure– How do you create an object?

• Have a public class method like Instance( ) – checks an internal class variable, _instance, of

the class type. – if _instance is NULL, create new object and

return it, else return _instance.

Kate Gregory

Singleton – Code Example

class Singleton

{

public:

static Singleton* Instance();

private:

Singleton();

static Singleton* _instance;

};

Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance(){ if(_instance == 0) {

_instance = new Singleton(); } return _instance;}

Singleton-itis

• Singleton is good in certain situations– Application settings, pools (eg db connections),

inventory, etc

• Almost impossible to write a thread-safe version

• Can be overused – Unrecorded dependencies

Kate Gregory

Façade

“Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.” - Design Patterns, Gamma et al.

Kate Gregory

Façade

• Hide the many interfaces of a detailed, complex subsystem by inserting a single interface (façade) between the high level classes and the subsystem.

• Insulate the consumers of your system from all your details

• Prevent other programmers from consuming your system “wrongly”

Façade example

Composite

• Perfect for unstructured hierarchies– Chains vary in length

• Employee reports to another Employee, who reports to another …

• A container holds items, some of which are actually containers, holding more items, which might be containers…

Kate Gregory

Composite Pattern

RAII

• Resource Acquisition is Initialization– Terrible name

• C++ concept– Applicable in many other languages

• Key is known lifetime of objects– And automatic cleanup

Kate Gregory

RAII Example

• Imagine a FILE resource you can get from your operating system– Open(string filename) returns handle– Read(handle h) returns some bytes– Write(handle h, byte[] b) writes data into it– Close(handle h) closes it

• You must remember to close the file

Kate Gregory

FileWrapper class

• Constructor takes file name, calls Open• Keep handle in member variable• Read and Write are member functions

– No need to pass handle

• Destructor (in C++ - other names other languages) calls Close– Cannot be forgotten– Works even in the presence of exceptions

Kate Gregory

RAII in General

• Constructor acquires a resource– Source of the name

• Destructor frees the resource

• Cannot forget

• Works with exceptions

• Incredibly powerful

Kate Gregory

Kate Gregory

Lab 4

• Draw a sequence diagram– One diagram– One path through one use case

• Read the hints!– They are based on troubles students had in the

past

• Don’t be surprised if you think a LOT for a single page you hand in

Kate Gregory

Next Week

• Modules and Packages, Metrics

• Lab 4 due

• Lab 5 will be handed out