”The process of preparing programs for a digital computer is especially attractive, not only because it can be Computing Science Department economically and scientifically Uppsala University rewarding, but also because it can be an 29th November 1999 aesthetic experience much like

Zoran Radovic composing poetry or music.” ¢¡¤£¦¥¤§¦£©¨ ©  ¤ 

29-Nov-1999 [email protected] 2

”Definition” Christopher Alexander

Patterns and Pattern Languages are ways to • An architecture professor at Berkeley describe best practices, good designs, and • C. Alexander, S. Ishikawa, M. Silverstein, capture experience in a way that it is possible M. Jacobson, I. Fiksdahl-King and S. for others to reuse this experience. Angel, ¤ "!#$ %'&¢$%( , New York:

Oxford University Press, 1977. ./+¤0+ 1214365¢798;:

• C. Alexander, )©*(+,)#-

<>=

0@?'- A$B - , 1979.

29-Nov-1999 [email protected] 3 29-Nov-1999 [email protected] 4

Christopher Alexander (cont.) Introducing Patterns into OOP

• Terminology: • 1987 – Workshop in OOPSLA – Kent Beck & Ward Cunningham – CED FFGH2IJ ”A Solution to a problem in a context.” • 1993 – The ”Hillside Group”

– KEL MMNO2PRQSL¤PUT¤VUL T¤N W ”A set of patterns used to – Beck, Booch, Coplien, Cunningham, Johnson, solve closely related problems” … • Purpose: • 1994 – PLoP Conference – Effective reuse – Pattern Languages of Programming – Dissemination of solutions • 1995 – The Gang of Four (GoF)

29-Nov-1999 [email protected] 5 29-Nov-1999 [email protected] 6

1 Hillside Group Misconceptions

• Formed out of a workshop called in the summer of • Misconception 1: 1993. (http://hillside.net) – ”Seen one, seen them all.” • Educational ”non-profit”… • Misconception 2: – a group of industry software designers committed to – ”Patterns need tool or methodological support studying the applicability of software patterns to be effective.” • Sponsored and helped to run the PLoP '94, '95, • Misconception 3: '96, '97, EuroPLoP '96, '97, UP97, ChiliPLoP '98 – ”Patterns guarantee reusable software, higher and the PLoPD1, PLoPD2 and PLoPD3 books. productivity, world peace, etc.”

29-Nov-1999 [email protected] 7 29-Nov-1999 [email protected] 8

Language Specific Patterns = Books about Patterns dSegf¦h

Idioms • c Gamma, E., Helm, R., Johnson, R., Vlissides, J.,

ijlknm oprqUs2t t jvupknwgx(y jvz#jvp t kU{ |$}(j~aks €2y jr‚€ ƒ jn„nt ;ulm jlp2t jv†

‡

{ |t ˆ$s2uj

• X/YZY , Addison-Wesley Publishing Co., 1995. ŠU‹(ŒŠŽZ

– Coplien: ”Advanced C++ Programming styles • ‰ James O. Coplien and Douglas C. Schmidt,

‘(’2“ “ ”v•–r—¤’g–˜¢™’˜¢”š(› œU‘•›n˜¢•@’2Rž”všlŸ ˜–S and Idioms” , Addison-Wesley Publishing Co., 1995.

– ”Localized Ownership” [PLoPD2] ¢U£(¤¢Ž¥‚¦ §

• ¡ John M. Vlissides, James O. Coplien and

ª «a¬@­‚®¦©g­a¯¤°©a¯¢«l±$² ³©¨¬²n¯ ¬@© ´>µ«l±n¶ ¯­

Norman L. Kerth, ¨$©ª [#\^](__`a]$_b

• · , Addison-Wesley Publishing Co., 1996.

– Beck: ”Smalltalk Patterns: Best Practices” ¹Uº(»¹Ž¼‚½ ¾

• ¸ Martin, R., Riehle, D., Buschmann, F., editors,

Á ÂvÃÄrŤÀgÄÆ¢ÇÀÆ¢ÂÈ(É ÊU¿ÃÉnÆ¢Ã@À2ËRÌÂvÈlÍ ÆÄZÎ – ”Lazy Optimization” [PLoPD2] ¿(À2Á , Chapters 22 - 24, Addison-Wesley Publishing Co., 1998.

29-Nov-1999 [email protected] 9 29-Nov-1999 [email protected] 10

How GoF Describe Design The GoF Definition Patterns? ”The design patterns in this book are descriptions of – Pattern Name and – Consequences communicating objects and classes that are Classification – Implementation customized to solve a general design problem in a – Intent – Sample Code particular context.” – Also Known As – Known Uses • In general, a pattern has four essential elements: – Motivation – Related Patterns – Applicability – Pattern name – Structure – Problem – Participants – Solution – Collaborations – Consequences

29-Nov-1999 [email protected] 11 29-Nov-1999 [email protected] 12

2

The GoF Catalog of Design Patterns How to Select a Design Pattern?

ÒÓÕÔ Ö

ÏlÐÑ Advice given by GoF:

×Ñ Ö ØÕÙ Ú Ó ÛØ;Ü Ý;Ù Ñ Ð@Þ Ù ÐÑ ØÕÜ ßnÖ àØ á;Ú ÓÕÑ ØÕÜ

Ó Ò@Ö ×Ü Ø;Ô Ô Ý;Þ Factory Method (107) Adapter (139) Interpreter (243) • Consider how design patterns solve design

Template Method (325) problems.

å æ ç âgãÕä Abstract Factory (87) Adapter (139) Chain of Responsibility (223) • Scan Intent sections. Builder (97) Bridge (151) Command (233) Prototype (117) Composite (163) Iterator (257) • Study how patterns interrelate. Singleton (127) Decorator (175) Mediator (273) Facade (185) Memento (283) • Study patterns of like purpose. Proxy (207) Flyweight (195) Observer (293) State (305) • Examine a cause of redesign. Strategy (315) Visitor (331) • Consider what should be variable in your design.

29-Nov-1999 [email protected] 13 29-Nov-1999 [email protected] 14

How to Use a Design Pattern? How to Use a Design Pattern? (cont.) Advice given by GoF: Advice given by GoF: • Read the pattern once through for an • Define application-specific names for overview. operations in the pattern. • Go back and study the Structure, • Implement the operations to carry out the Participants, and Collaborations sections. responsibilities and collaborations in the • Look at the Sample Code. pattern. • Choose names for pattern participants that are meaningful in the application context. • Define the classes. (These are just guidelines to get you started.)

29-Nov-1999 [email protected] 15 29-Nov-1999 [email protected] 16

OOA/OOD/OOP Booch Notation Diagrams and Notation

• Grady Booch, 1990

ê ënìví î;èrïlð ëlñ2í ëvòró(ïôaõöï÷ øEøEð ñaõúù'ð í ûü2ýgý$þ ð ìv÷í ð ôñgÿ • Three popular notations: – è‚é , – Booch Notation Addison-Wesley – Refined 1994 – OMT Notation • Part of the ”Booch OOA&D Methodology” – UML Notation • Major Contributions: – Distinguish Static from Dynamic models – Object Diagrams: depicting object and messages • Before UML: Used by ~30% of the OOP market

29-Nov-1999 [email protected] 17 29-Nov-1999 [email protected] 18

3

OMT Notation UML Notation

@"> AB

• Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, • Booch, Rumbaugh, Jakobson, ;= CED

F., Lorensen, W., ¢¡¤£¦¥¨§ ©  ¦¥¨¥©

BFAGH> POQA

 , 1997 ¥ ¥ § , 1991

– http://www.rational.com/uml

#$&%&' () +*-, $-.¨' $-/1032/$54 4 , .5687./"98$-:&, 6. – "! , Prentice Hall – Refined by later articles, adding state and object • A unification of several previous techniques diagrams • De-facto contemporary standard – Mostly identified with James Rumbaugh • Before UML: Used by 50% - 60% of the OOP market

29-Nov-1999 [email protected] 19 29-Nov-1999 [email protected] 20

GoF Guide to Notation GoF Guide to Notation vxwzy|{E}~€+€ƒ‚ „~†s‡"~ˆ

• Three different diagrammatic notations:

TU&UWVYX TZ[T\ – A R S depicts classes, their structure,

and the static relationships between them. fghfi – An ]^_a`¨b¨c"dYe depicts a particular object structure at run-time.

– An j¤kl-m nopl-j¤qksrYj¤otnou shows the flow of requests between objects.

29-Nov-1999 [email protected] 21 29-Nov-1999 [email protected] 22

GoF Guide to Notation GoF Guide to Notation

‰xŠŒ‹|Ž-‘"‘“’ ”•–+— ˜x™zš|˜œ›H=ž8Ÿ W¡ ¢£¤s¥"£¦

29-Nov-1999 [email protected] 23 29-Nov-1999 [email protected] 24

4

GoF Guide to Notation FACADE

º+»±¼½«»±¼ §©¨¨«ª«¬®­"¯±°-²8³+´ª°µ¨¢¯·¶ µ-´3¸³"´s¹

Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

29-Nov-1999 [email protected] 25 29-Nov-1999 [email protected] 26

FACADE FACADE

¾ ¿¿ÁÀ¨ÂëıŁÂÀÂÆ Ç ÈzɁÊË-Ì8ÍÎÊËÉ«Ï

• Want to provide a simple interface to a complex subsystem. • Decouple the subsystems from clients and other subsystems, thereby promoting subsystems independence and portability. • You want to layer your subsystems.

29-Nov-1999 [email protected] 27 29-Nov-1999 [email protected] 28

FACADE FACADE

×EØ«ÙxÚÁÛÜÝ«Þàß áâÙxÚÁÜÝ Ð Ñ3ÒsÓxÔÁÕÖ

29-Nov-1999 [email protected] 29 29-Nov-1999 [email protected] 30

5

OBSERVER OBSERVER

ã+äÎåæ«ä±å çzèéê-ë8ìÎéêè«í

Define a one-to-many dependency between A common side-effect of partitioning a system objects so that when one object changes state, into a collection of cooperating classes is the all its dependents are notified and updated need to maintain consistency between related automatically. objects. You don’t want to achieve consistency by making the classes tightly coupled, because that reduces their reusability.

29-Nov-1999 [email protected] 31 29-Nov-1999 [email protected] 32

OBSERVER OBSERVER

õ±ö-÷«ø«ùöø¢÷"ú îzïsðñò«ó±ðñï¢ô

29-Nov-1999 [email protected] 33 29-Nov-1999 [email protected] 34

OBSERVER OBSERVER

ûLüsý«þÿ¡ 3ÿ ¢ ü¤£±þ¦¥ ¤ ! ¦"¤ #$&%¦')(*"¤+,%-¦. /

• 021436587!9!:¦9;=<6>4?@9A5B: • §©¨© ©  – Stores state of interest to ConcreteObserver objects. – Knows its observers. Any number of Observer – Sends a notification to its observers when its state objects may observe a subject. changes.

– Provides an interface for attaching and • C2D4E6F8G!H!I¦HAJLK6MNHAG@OPHAG detaching Observer objects. – Maintains a reference to a ConcreteSubject object. – Stores state that should stay consistent with the • © subject's. – Defines an updating interface for objects that – Implements the Observer updating interface to keep its should be notified of changes in a subject. state consistent with the subject's.

29-Nov-1999 [email protected] 35 29-Nov-1999 [email protected] 36

6 OBSERVER

OBSERVER ^-_¤`!a¤b!cB_ dfeBgih¤j¤kmln`¦go QSR¤TAT¦UV¤R,WXUZY![!R \¤]

Subject::Notify() { for (i = 0; i < _ObsNumber; i++) _my_obs[i]->Update(this); } Observer Subject 0..n Update(subject *) = 0 Attach(Observer*) 1 my_obs Detach(Observer *) A Notify() A

ConcreteSubject::ChangeData() { // make some chance Notify(); } Observer 1 Update(subject *) Concrete Subject Observer 2 ChangeData( ) Update(subject *)

29-Nov-1999 [email protected] 37 29-Nov-1999 [email protected] 38

Pattern Tools Corporate Domain

• Pattern Template Library “What every corporate group in the world wants, however, is not a – Library which provides intrusive data structures and book of patterns written by someone outside the company, but a design patterns in the form of easy to use C++ collection of patterns that reflect the company's way of doing business. templates. Include a fast, dynamically reconfigurable The business goal is a handbook of best practices that documents the things the company has done well. This handbook would ensure that finite state machine. Includes a free demo, examples, corporate wisdom would be recorded and shared with current and and a full view of the documentation. future employees. It is almost certain that no one person already has all • ModelMaker Delphi CASE Tool this knowledge, so everyone in the company would become more

knowledgeable about the business. The whole organization would

s¡t¡u4vwr xyr s{z

– Supports UML and Patterns. Design Patterns in improve.” p qAr

„ u † r sP‡ ˆNx † ‰ x

ModelMaker are implemented as ”ready to use” active sƒr

 € agents which insert customable snippets of code. |},~¡€€P‚

29-Nov-1999 [email protected] 39 29-Nov-1999 [email protected] 40

Domain-Specific Patterns Part 8 in [PLoPD3]

êyë ì íî î ïð ñ òyó ô õö ÷ øù ú ûyü ý þÿ published in [PLoPD3] çè é

The Points and Deviations

“Œ”@• – —!˜¡•¦•™6šA› › ˜ƒœ—*•ž Ÿ6 ¡••¡žB¢@– š!› – ž*—¤£X¥ ¦B˜N¢ › • • ŠŒ‹w!Ž N‘’!’ : , by Business Patterns of A Pattern Language of Pattern Language of Fire

Lorraine L. Boyd Association Objects Transport Systems Alarm Systems

°²±¡³A´ ´ µ ¶{·Œ¸P³B·N¹4º@³N¹wµŒ» ¼©½¶{³!·*¾ ¿6»!¶¦´*ÀƒÁA¾ƒ´ µ ÂX¾Ã • §Œ¨w©!ª« ¬N­®!¯ : by Association Object Pattern Point Pattern Deviation Pattern Liping Zhao and Ted Foster

Customer Contact Pattern Route Pattern Point Pattern

ÍAÎAÏ=ÐÑAÒ ÓÔ Õ6ÖBÓ!׌ØÙσÚNÒ Ö!Ô Ò Ñ!Ó*ÕÐÖAÔ Ô ÏƒÛÓŒÜÖBÓ@ÝwÞ@Ö@ÝwÏ • ČÅwÆ!ÇÈ ÉNÊËAÌ :

3-Level Order Pattern Pool Pattern

ß6àŒÒ ۦρáâ Ö!۝ãåä æ!ÕƒÔ ÏƒãXÕ Ñ , by Peter Molin and Lennart Ohlsson Lazy State Pattern Periodic Object Pattern

Data Pump Pattern

29-Nov-1999 [email protected] 41 29-Nov-1999 [email protected] 42

7 Business Patterns of Association Objects Association Object Pattern

• Two main types of persistent objects in large-scale

business systems:

¤¥¢ ¦ §©¨ §¢ 

– ¡£¢ - examples are product, customer, and employee. An Association Object represents something that happens

£ ¥    ¥     –  - represents something that happens at a point at a specific point in time, associating two other objects. in time, associating two other objects (either static or other associating objects). Examples are order, customer contact, and assignment. • Patterns for associations during the analysis phase can help in finding and defining business needs.

29-Nov-1999 [email protected] 43 29-Nov-1999 [email protected] 44

Association Object Pattern (3)

Association Object Pattern (2) ,.-+/10¥24310 !#"%$'&'(¥)+*

• Examples on business systems that focus on changes or movements of items over time: How can the associations and movements between static – Scheduling systems objects be identified? – Assignment systems – Inventory-tracking systems • An association may change from describing future plans to describing a current state or history. • Understanding the association is key to developing a solid software design.

29-Nov-1999 [email protected] 45 29-Nov-1999 [email protected] 46

Association Object Pattern (4) Association Object Pattern (5)

DFE'G@H'I@JKE%L

576+8:9<;+=

QSR T U V U W X©Y • Often simple relationship between two related objects if M N O¥N P we examine only the current state of association (known as Name Name >@?BAC? Description Description relationship). But when we add history and/or Set Set planning, the nature of that relationship changes. Get Get • Integrating history, planning, and current state all in one 1 1

approach will increase quantities of information stored and

Z¥[¥[¥\^]`_ Z a _ \cb accessed. This may have a significant negative impact on 0..m 0..m Begin_Date performance. End_Date Cost • Separating history, planning, and current state associations Allocate_Costs may increase the amount of code needed. Create_Current_from_Plan

29-Nov-1999 [email protected] 47 29-Nov-1999 [email protected] 48

8 Association Object Pattern (6)

dfehgjilknm¥o Customer Contact Pattern s t u v^w¥x yKt z¥x p¥q`qcr • This pattern is a variation on the Association Object Name Name pattern. Description Description Calculate_Room_Costs Calculate_Dept_Costs • It represents the association between the business and the Set Set

Get Get customer and is particularly important in systems that ŒKŽ£‘ˆ£’@¥Ž

1 1 emphasize ˆ^‰cŠ ‹ .

{¥|^|B}£~ ^€ ‚ ~ƒ „¥„ †c‡£}K€ ‡¥‚ 0..m 0..m Begin_Date End_Date Allocate_Percent Contact_Name Allocate_Costs Create_Assignment Notify_Contact

29-Nov-1999 [email protected] 49 29-Nov-1999 [email protected] 50

Customer Contact Pattern (3)

Customer Contact Pattern (2) ­.®+¯1°¥±4²1° “#”%•'–'—¥˜+™

• In a day-to-day operational system, customers use the services of the business. How can we change the focus of a business system from • Customers contact business with questions and complaints;

information šœ›K@žKŸ the customer to information about past, the business contacts customers to evaluate services or to

¡œ¢ £`¤¥§¦^¢ ¨B¡K©«ª: ¢ ¬ current and future the customer? encourage the use of services. • To provide optimal customer care, the business system must know the history of its customer contacts, be able to detect trends in these contacts, and then use these trends to drive responses to current questions and proactive contacts in the future.

29-Nov-1999 [email protected] 51 29-Nov-1999 [email protected] 52

Customer Contact Pattern (4) Customer Contact Pattern (5)

¹Fº'»@¼'½@¾Kº%¿

³7´+µ:¶<·+¸

ÈcÉ¥Ê`Ë^Ì Í Î Ë Ï Í ÈcÌ • Customers are contacted by many different organizations À^Á  à ÄcÅKÆ¥Ç within the business. The organizations may be competitive Name Name and protective of their individual information. Description Description • Customers want to be treated the same way no matter which organization is contacting them. 1 1

• To track every customer contact in one class would create Ð^Ñ Ò Ó ÔcÕKÖ¥× Ø Ð£ÔcÙ Ó Ú Ð£Ó

à á¥Û^â ã ä Þ 0..m 0..m Û^ÜcÝ Þ ß¥Û^Þ many similar instances. Date_Time 1 Type • Management wants to know about trends in customer Results Steps Date_Follow_Up 0..m Determine_Contact_Rules queries. Thus, there is a need to store and examine large Schedule_Follow_Up Create_Contact amounts of data. Determine_Patterns

29-Nov-1999 [email protected] 53 29-Nov-1999 [email protected] 54

9