Engineering of Software II

1. Engineering of Software II Spring 2003

2. Why Design Patterns?Problems • The hard part about object-oriented design is decomposing a system into objects • The task is difficult because many factors influence the decomposition, often in conflicting ways: • encapsulation, • granularity, • dependency, • aggregation, • flexibility, • performance, • evolution, • reusability

3. Why Design Patterns?Solutions Expressing proven techniques as design patterns makes them more accessible to developers of new systems. Design patterns: • Make it easier to reuse successful designs and architectures • Can even improve the documentation and maintenance of existing systems • Help you identify less-obvious abstractions and the objects that can capture them Put simply, design patterns help a designer get a design "right" faster.

4. Introduction to Design Patterns • History of Design Patterns • Summary of Patterns • Characterizing Design Patterns • Visualizing Design Patterns • Creational Design Patterns - concern the process of object creation • Behavioral Design Patterns - deal with the composition of classes or objects • Structural Design Patterns - characterize the ways in which classes or objects interact and distribute responsibility

5. History of Design Patterns • The history of design patterns in object-oriented programming is most often attributed to Erich Gamma, the initiating author of “Design Patterns: Elements of Reusable Object-Oriented Software.” • The true father of design patterns is Christopher Alexander, an architect educated in mathematics, science, and engineering. • Alexander believes you can design a building by simply applying one pattern after another. His theory does not deny the necessity of creativity in design and implementation, but his precise description of how patterns generate design is a clear implication that a pattern language can make the design process deterministic and repeatable.

6. Model View Controller (MVC)

7. Summary of Patterns Scope: Class patterns deal with static relationships between classes and their subclasses, which are fixed at compile-time. Object patterns deal with dynamic object relationships, which can be changed at run-time.

8. Characterizing Design Patterns • name to communicate the design element. • problem describes when to apply the pattern. • solution describes the elements that make up the design, their relationships, responsibilities, and collaborations. The solution doesn't describe a particular concrete design or implementation, because a pattern is like a template that can be applied in many different situations. • consequences are the costs/benefits of applying the pattern.

9. Characterizing Design PatternsMore Detailed Characterization • Intent • Also Known As • Motivation • Applicability • Structure • Participants • Collaborations • Consequences • Implementation • Sample Code • Known Uses • Related Patterns

10. Visualizing Design Patterns • Initially, the Object Modeling Technique (OMT) was used to represent design patterns, however, the Unified Modeling Language (UML) has replaced OMT. • UML captures real-world concepts (objects), their attributes, and the associations between these concepts. • UML is used to visualize and represent design patterns.

11. Creational Design Patterns • Creational Design Patterns abstract the instantiation process • By abstracting the instantiation process, the system is independent of how its objects are created, composed, and represented • Creational Patterns can be implemented by objects, or by class inheritance

12. Creational Design Patterns • Encapsulates knowledge about which concrete classes a system uses • Hides how objects are instantiated and how they are composed • Creational patterns are closely related, sometimes they complement one and another or are competitors

13. Behavioral Design Patterns • Behavioral patterns are concerned with algorithms and the assignment of responsibilities between objects • Behavioral patterns describe patterns of objects and classes, but also the communication between them • Behavior patterns are implemented using inheritance and object composition

14. Behavioral Design Patterns • Behavioral patterns use inheritance to distribute behavior between classes • Behavioral object patterns use object composition rather than inheritance • Some describe how a group of peer objects cooperate to perform a task that no single object can carry out by itself • Other behavioral object patterns are concerned with encapsulating behavior in an object and delegating requests to it

15. Structural Design Patterns • Structural Patterns are concerned with how classes and objects are composed to form larger structures • Structural class patterns use inheritance to compose classes and implementations • Structural objects describe ways to compose patterns to realize new functionality • Structural patterns are related to some degree

16. Introducing Design Patterns into the Data Structures Class • Labs – Patterns introduced in laboratory exercises • Allow simple hands on experience using patterns • Demonstrate the power and usefulness of patterns • Lectures – Patterns introduced in lecture, and explained by example • Allow the introduction of design patterns used by Java but not used directly in the course • Tests – Students evaluated on pattern knowledge

17. Introduction by Labs

18. Lab 1 – Dense List OBJECTIVE: • To introduce the Abstract Data Type (ADT) • To introduce the class implementation of a ADT • To reinforce simple Java Applications, interfaces, and problem domain classes • To reinforce inheritance and composition • To introduce design patterns: Factory Method (Creational) and Iterator (Behavioral)

19. Lab 1 – Dense List

20. Lab 2 – Link List OBJECTIVE: • To demonstrate the Abstract Data Type (ADT) implementation independence • To introduce the dynamic linked list implementation of a basic data structure • To introduce the pointer concept • To reinforce simple Java Applications • To reinforce inheritance, polymorphism, and composition • To reinforce design patterns: Factory Method and Iterator

21. Lab 2 – Link List

22. Lab 3 – Priority Queue OBJECTIVE: • To introduce a sorting technique (priority queue sorting) • To introduce the measurement of algorithm performance • To reinforce the Abstract Data Type (ADT) • To reinforce the class implementation of a ADT • To introduce the Enumeration (Behavioral) and Adapter (Structural) design patterns

23. Lab 3 – Priority Queue

24. Lab 4 – Prefix Parser (Stack and Queue implementations) OBJECTIVE: • To introduce the stack and queue ADT. • To reinforce the structured approach to programming • To reinforce the Abstract Data Type (ADT) • To reinforce the class implementation of a ADT • To introduce the concept of a Singleton Pattern (Creational) • To introduce the concept of a History List

25. Lab 4 – Prefix Parser (Stack and Queue implementations)

26. Lab 5 – Iterative Heap Sort OBJECTIVE: • To reinforce the measurement of algorithm performance • To introduce a sorting technique (heap sorting) • To reinforce the concept of an Iterator pattern (Behavioral) • To reinforce the concept of an Factory Method pattern (Creational) • To introduce the concept of Decorator pattern (Structural) • To reinforce the concept of Code Reuse

27. Lab 5 – Iterative Heap Sort

28. Lab 6 – Binary Tree • To introduce a binary tree implementation • To introduce tree operations (insert, search, delete, and list) • To introduce basic Audit Trail techniques • To introduce the Visitor Pattern (Behavioral)

29. Example Sample Code • The Factory Method Pattern public AbstractIterator getIterator() { return new SomeIterator(listADT); } • The Singleton Pattern private static HistoryList list; private HistoryList(){ } public static HistoryList getHistoryList() { return list; }

30. Introduction by Lecture • Flyweight Pattern - Use sharing to support large numbers of fine-grained objects efficiently • Immutable - To create an object whose state does not change after creation • Bridge Pattern - Decouple an abstraction of an interface from its implementation so that the two can vary independently

31. Introduction by Lecture • Example Lecture (Immutable and Flyweight): String a = “hello”; String b = “hello”; String c = new String(“hello”); If(a==b) System.out.println(“1 equal?”); If(a==c) System.out.println(“2 equal?”); If(a.equals(b)) System.out.println(“3 equal?”); hello hello Output: 1 equal 3 equal

32. Design Pattern Solutions • Consider using data structure/design pattern proven implementations • Find problems matching patterns and mold an exercise around the problem • Introduce design patterns as an integral part of course, but emphasize their involvement as complementary, rather than supplementary • Use the tests to evaluate whether students are gaining the design pattern knowledge

33. Benefits to Learning Design Patterns • Design patterns make it easier to reuse successful designs • Design patterns provide a common design vocabulary • Design patterns provide a foundation for the documentation of software artifacts • Design patterns provide students with a stronger understanding of APIs • Design patterns provide an abstraction transcending the analysis, design, and implementation phases

34. References • IS 2002, Model Curriculum and Guidelines for Undergraduate Degree Programs in Information Systems, Gorgone, Davis, Valacich, Topi, Feinstein and Longenecker, http://www.acm.org/education/is2002.pdf. • Java BluePrints, Model-View-Controller, http://java.sun.com/blueprints/patterns/MVC-detailed.html. • Preiss, B. R., “Design Patterns for the Data Structures and Algorithms Course,” 1999, pages 95-99. • Nguyen, D., “Design Patterns for Data Structures,” 1998, pages 336-340. • Proulx, V. K., “Programming Patterns and Design Patterns in the Introductory Computer Science Course,” 2000, pages 80-84. •  Astrachan, O., G. Berry, L. Cox, and G. Mitchener, “Design Patterns: An Essentail Component of Computer Science Curricula,” 1998, pages 153-160. • Ghafarian, A., “Teaching Design Effectively in the Introductory Programming Courses,” 2001, pages 203-210. •  Gelfand, N., M. T. Goddrich, and R. Tamassia, “Teaching Data Structure Design Patterns,” 1998, pages 331-335. •  Clancy, M. J., M. C. Linn, “Patterns and Pedagogy,” 1999, pages 37-42. • Stelting, S., O. Maassen, “Applied Java Patterns,” Sun Microsystems Press: A Pretence Hall Title, Palto Alto, CA, 2002. • http://gee.cs.oswego.edu/dl/ca/ca/ca.html [Alexander93] Christopher Alexander:An Introduction for Object-Oriented DesignersDoug LeaSUNY Oswego / NY CASE Center.