Bernd Bruegge Applied Software Engineering Technische Universitaet Muenchen

Bernd Bruegge Applied Software Engineering Technische Universitaet Muenchen Using UML, Patterns, and Java Object-Oriented Software Engineering Object Design II: Design Patterns

What is this? 1. Nf 3 d 5 2. c 4 c 6 3. b 3 Bf 5 4. g 3 Nf 6 5. Bg 2 Nbd 7 6. Bb 2 e 6 7. OO Bd 6 8. d 3 O-O 9. Nbd 2 e 5 10. cxd 5 11. Rc 1 Qe 7 12. Rc 2 a 5 13. a 4 h 6 14. Qa 1 Rfe 8 15. Rfc 1 This is a fianchetto! The fianchetto is one of the basic building-blocks of chess thinking. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2

Fianchetto (Reti-Lasker) The diagram is from Reti-Lasker, New York 1924. We can see that Reti has allowed Lasker to occupy the centre but Rtei has fianchettoed both Bishops to hit back at this, and has even backed up his Bb 2 with a Queen on a 1! Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3

Is this a good Object Model? public interface Seat. Implementation { public int Get. Position(); public void Set. Position(int new. Position); } public class Aim. Seat implements Seat. Implementation { public int Get. Position() { // actual call to the AIM simulation system } …. } public class SARTSeat implements Seat. Implementation { public int Get. Position() { // actual call to the SART seat simulator }. . . } Not quite But it depends…. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4

A Game: Get-15 • The game starts with nine numbers 1, 2, 3, 4, 5, 6, 7, 8 and 9 • You and your opponent take alternate turns, each taking a number • Each number can be taken only once: If you opponent has selected a number, you can no longer take it • The first person to have any three numbers that total 15 wins the game • Example: You: 1 5 3 8 Opponent: Bernd Bruegge & Allen H. Dutoit 6 9 7 2 Object-Oriented Software Engineering: Using UML, Patterns, and Java 5 Opponent Wins!

Characteristics of Get-15 • Hard to play • The game is especially hard, if you are not allowed to write anything down • Why? • All the numbers must be scanned to see if you have won/lost • It is hard to see what the opponent will take if you take a certain number • The choice of the next number depends on all the previous numbers (your and your opponent’s numbers) • Not easy to devise an simple strategy. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6

Another Game: Tic-Tac-Toe Source: http: //boulter. com/ttt/index. cgi Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7

A Draw Sitation Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8

Strategy for determining a winning move Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9

Winning Situations for Tic-Tac-Toe Winning Patterns Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10

Tic-Tac-Toe is “Easy” Why? Reduction of complexity through patterns and symmetry Patterns: Knowing the following three patterns, the player can anticipate the opponents move. Symmetry: The player needs to remember only these three patterns to deal with 8 different game situations The player needs to memorize only 3 opening moves and their responses. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11

Get-15 and Tic-Tac-Toe are identical problems ¨ ¨ ¨ Any sequence of three numbers that wins the Get-15 game also wins at Tic-Tac-Toe Any Tic-Tac-Toe solution is also a solution the to Get-15 problem To see the relationship between the two games, we simply arrange the 9 digits into the following pattern 8 1 6 3 5 7 4 9 2 . Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12

You: 1 Opponent: 6 8 1 6 3 5 7 4 9 2 Bernd Bruegge & Allen H. Dutoit 5 3 9 8 7 2 8 1 6 3 5 7 4 9 2 Object-Oriented Software Engineering: Using UML, Patterns, and Java 13

• During object modeling we do many transformations and changes to the object model • It is important to make sure the system model stays simple during these model transformations • After all, the goal of a model is to be an abstraction, that is, a simplification, not a complication • Design patterns keep the system model simple. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14

Heuristics for Good Models • Modeling must address our mental limitations: • Our short-term memory has only limited capacity (7+-2) • Good models deal with this limitation, because … … they do not tax the mind • A good model requires a minimal mental effort to understand … they reduce complexity • Use of patterns • Use of symmetries … they use abstractions • Taxonomies … they have organizational structure • Memory limitations are overcome with an appropriate representation (“natural model”). Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15

Outline of the Lecture ü Two games ü Patterns and symmetry help to win the game ü Heuristics for good models • Reducing the complexity of models • Patterns covered in this lecture • • Composite: Model dynamic aggregates Facade: Interfacing to subsystems Adapter: Interfacing to existing systems (legacy systems) Bridge: Interfacing to existing and future systems • Next lecture (January 8) • • Factory and Abstract Factory Proxy Observer Strategy Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16

Review: Design pattern A design pattern is… …a reusable template for solving a recurring design problem • Basic idea: Don’t re-invent the wheel! … design knowledge • Knowledge on a higher level than classes, algorithms or data structures (linked lists, binary trees. . . ) • Lower level than application frameworks …an example of modifiable design • Learning how to design starts by studying other designs. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17

Why are modifiable designs important? A modifiable design… …enables an iterative and incremental development • concurrent development • risk management • flexibility to change … minimizes the introduction of new problems when fixing old ones … allows to easily add more functionality after the delivery of the system Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18

What makes a design modifiable? • Low coupling and high cohesion • Clear dependencies • Explicit assumptions How do design patterns help? • They are generalized from existing systems • They provide a shared vocabulary to designers • They provide examples of modifiable designs • Abstract classes • Delegation Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19

What is common between these definitions? • Definition Software System • A software system consists of subsystems which are either other subsystems or collection of classes • Definition Software Lifecycle • A software lifecycle consists of a set of development activities which are either other actitivies or collection of tasks. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 22

What is common between these definitions? • Definition Software System • A software system consists of subsystems which are either other subsystems or collection of classes • Composite: Subsystem (A software system consists of subsystems which consists of subsystems, which. . . ) • Leaf node: Class • Definition Software Lifecycle • A software lifecycle consists of a set of development activities which are either other actitivies or collection of tasks • Composite: Activity (A software lifecycle consists of activities which consist of activities, which. . ) • Leaf node: Task. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 23

Introducing the Composite Pattern • Tree structures that represent part-whole hierarchies with arbitrary depth and width can be used in the solution of many problems • The Composite Pattern lets a client treat individual objects and compositions of these objects uniformly Component Client Operation() Leaf Operation() * Composite Operation() Add. Component() Remove. Component() Get. Children() Children

Modeling a Software System������ with a Comp Pattern Software System User * Class Subsystem Bernd Bruegge & Allen H. Dutoit Children Object-Oriented Software Engineering: Using UML, Patterns, and Java 25

Modeling the Software Lifecycle with a Composite Pattern Software Lifecycle Manager * Task Activity Bernd Bruegge & Allen H. Dutoit Children Object-Oriented Software Engineering: Using UML, Patterns, and Java 26

The Composite Patterns models Dynamic Aggregates Fixed Structure: Car * * Doors Wheels Battery Engine Organization Chart (variable aggregate): * University * School Dynamic tree (recursive aggregate): Program Composite Pattern * Compound Statement Bernd Bruegge & Allen H. Dutoit Department * Block Simple Statement Object-Oriented Software Engineering: Using UML, Patterns, and Java 27

Graphic Applications use the Composite Pattern • The Graphic Class represents both primitives (Line, Circle) and containers (Picture). Graphic Client Line Draw() Bernd Bruegge & Allen H. Dutoit * Draw() Circle Draw() Picture Draw() Add(Graphic g) Remove. Graphic) Get. Child(int) Children Object-Oriented Software Engineering: Using UML, Patterns, and Java 28

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 29

The Java‘s AWT library can be modeled with the component pattern Graphics Component * get. Graphics() Text Component Text. Field Bernd Bruegge & Allen H. Dutoit Button Label Container add(Component c) paint(Graphics g) Text. Area Object-Oriented Software Engineering: Using UML, Patterns, and Java 30

Reducing the Complexity of Models • Modeling is about communication • To a human being as well as to a tool • To communicate a complex model to a human being we use navigation and reduction of complexity • Navigate through the model so the user can follow it • Start with a very simple model • Identify the key abstractions • Then decorate the model with additional classes • To reduce the complexity of the model further • Look for inheritance (taxonomies) • If the model is too complex, taxonomies should be placed in separate UML packages • Then identify or introduce patterns in the model • Make sure to use the name of the patterns. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31

Example: Modeling a Project Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32

How to reduce the Complexity of the Model 1. Look for the key abstractions • Project, Outcome, Schedule, Work, Resource 2. Identify patterns: For example, the project model has 3 composite patterns * 3. Find all the application domain taxonomies • Start with the taxonomies for the key abstractions 4. Key abstractions, patterns and/or taxonomies are candidates for separate UML packages. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 33

1. Find the Key Abstractions in the Model Key Abstractions Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 34

Key Abstractions in the Project Model Project Outcome Bernd Bruegge & Allen H. Dutoit Schedule Work Resource Object-Oriented Software Engineering: Using UML, Patterns, and Java 35

2. Find Patterns used in the Model Composite Patterns Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 36

Composite Patterns in the Project Model Work Outcome Set of Work Products * * * Work product Bernd Bruegge & Allen H. Dutoit Activity Task Organizational Unit Staff Object-Oriented Software Engineering: Using UML, Patterns, and Java 37 Participant

3. Find the Taxonomies used in the Model Taxonomies Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 38

Step 4: Package based on Key Abstractions Project Outcome Bernd Bruegge & Allen H. Dutoit Schedule Work Resource Object-Oriented Software Engineering: Using UML, Patterns, and Java 39

Step 4 continued: Additional Packages based on Patterns Work Outcome * * * Set of Work Products Organization Work product Bernd Bruegge & Allen H. Dutoit Activity Task Organizational Unit Staff Object-Oriented Software Engineering: Using UML, Patterns, and Java 40 Participant

Step 4 continued: Additional UML Packages based on Taxonomies Resource Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 41

Patterns are not the cure for everything • What is wrong in the following pictures? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 42

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 43

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 44

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 45

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 46

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 47

Summary • Design patterns are template solutions for common design problems such as • separating an interface from a number of alternate implementations • Accessing a set of legacy classes • protecting a caller from changes associated with specific platforms • A design pattern consists of a small number of classes • uses delegation and inheritance • provides a modifiable design solution • These classes can be adapted and refined for the specific system under construction • To provide the reuse of existing solutions • Customization of the system. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 49

Additional Readings • E. Gamma et. al. , Design Patterns, 1994. • M. Fowler, Analysis Patterns: Reusable Object Models, 1997 • F. Buschmann et. Al. , Pattern-Oriented Software Architecture: A System of Patterns, 1996 • T. J. Mowbray & R. C. Malveau, CORBA Design Patterns, 1997 • S. W. Ambler, Process Patterns: Building Large-Scale Systems Using Object Technology, 1998. • Dependency management: P. Feiler & W. Tichy, “Propagator: A family of patterns, ” in Proceedings of TOOLS-23'97, Santa Barbara, CA, Aug, 1997. • Configuration management: W. J. Brown et. Al. , Anti. Patterns and Patterns in Software Configuration Management, 1999. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 50

Backup Slides Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 51

Notation used in the Design Patterns Book • Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, 1995 • Based on OMT (a precursor to UML). Notational differences between the OMT notation and UML: Attributes come after the Operations Associations are called acquaintances Multiplicities are shown as solid circles Dashed line: Instantiation Association (Class can instantiate objects of associated class) (In UML it denotes a dependency) • UML Note is called Dog-ear box (connected by dashed line to class operation): Pseudo-code implementation of operation. • • Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 52