1. Design Patterns Standardized Recurring model Fits in many location Opposite of customization Fundamental types of pattern Choose and use as desired and befitting Adapt the pattern to your application

2. Loop pattern –Initialize loop parameter values and loop variant –Loop – if (check condition) – { – statements – } – else – { – quit/exit Loop – } – change loop variant – continue Loop Is syntax diagram a pattern?

3. This is an algorithmic code pattern for iteration You need to know what the loop parameters are, their initial values, and how they should be initialized You need to know the condition to be checked Obviously, the statements to be executed when the condition is true Precisely how the loop variant is to be changed for your application

4. Definite iteration Going from 0 to N Going from –M to +N by step k Indefinite iteration How to obtain loop variant? How to validate loop variant? We have a pattern for definite iteration; and another for indefinite iteration How about a pattern for linear search? How about pattern for search in a 2-D array?

5. Why we use Design Patterns We use patterns to make the design and implementation flexible Flexible w.r.t. requirements Flexible w.r.t. to inputs Flexible w.r.t. to implementation – move things around an plug in components

6. Fundamental types of Design Patterns Creational Structural Behavioral One may find patterns pertinent to domains that you may not find in other domains Patterns for dynamic behavior may also be identified

7. Creational Patterns Factory Abstract Factory Builder Prototype Singleton

8. The Factory Pattern Constructor creates an object of a particular class Similar objects based on input values are to be created then you can have different class and the driver parses the input and uses the appropriate constructor A factory pattern streamlines this

9. The Abstract Factory Pattern Level higher in abstraction to the factory pattern In some cases it actually returns a Factory for that group of classes Example: –Type of garden –Types of plants in the garden Investment example

10. The Builder Pattern Configurable system – configuration file (XML files) Assembles objects to make a new object or system Based on the data in the config. File Uses a factories to build objects Separates construction from representation

11. The Prototype Pattern Copies or clones an existing class Used when creating a new instance is expensive Use java clone() method Classes have to implement cloneable

12. The Singleton Pattern Is a pattern that insures there is one and only one instance of an object Globally accessible object Final class with static methods Constructor is privatized Avoids global variables getInstance() method returns reference to this object

13. Maintain a registry of singletons Pass singletons to other objects Type checking may be needed on singletons – if using a registry How to adapt singletons for X instances

14. More info and examples http://www.fluffycat.com/java/patterns.html http://www.dofactory.com/Patterns/Pattern s.aspxhttp://www.dofactory.com/Patterns/Pattern s.aspx http://c2.com/cgi/wiki?DesignPatterns http://channah.com/portfolio/talk/Paper/Go F-patterns/http://channah.com/portfolio/talk/Paper/Go F-patterns/ http://www.patterndepot.com/put/8/JavaPa tterns.htmhttp://www.patterndepot.com/put/8/JavaPa tterns.htm

15. Structural Patterns Adapter –Adapt a user familiar interface to an available class interface Composite –A mechanism to camouflage the distinction between like items with different constraints Proxy –An intermediary assisting until the actual is available Flyweight –A mechanism to avoid having many classes – differing only by a few parameters – a sharable instance of a class Façade –A simplified interface to the generic system, as the system evolves Bridge –A class that integrates interface to implementation Decorator –A class with possible decorators (rather than derived classes)

16. Behavioral Pattern Observer or listener class Mediator – communication interface (stub?) Chain of Responsibility – chain of mediators Template – abstract definition of an algorithm Interpreter – appears like a language construct Strategy – a mechanism to choose algorithm by the driver Visitor – driver on multiple instance of a class (non-object oriented approach used for efficiency) State – class retains its state and switches its choice of class Command – traps and forwards the command to a specific class Iterator – a mechanism to move through a collection through an interface

17. Framework Domain oriented design Can take this design (as a whole) and utilize it for multiple applications Service industry Distribution industry Health care industry Manufacturing Marketing Embedded Controls –Aircraft controls –Chiller controls

18. Summary What is UML? What is it unifying? What is the fundamental premise of UML? Define system Architecture. List the views of a system What is UP? Describe the axioms of UP. List the phases and workflows prescribed in UP

19. Summary (cont.) Who is responsible for the inception Phase? Who is responsible for other phases? Do we have to do all the workflows for every requirement? How are testing benchmarks to be developed? What would make systems developed using UML and UP obsolete?

20. Summary (Cont.) Argue for and against maintaining legacy systems. What is meant by a Quality Product? What is a Quality Process? Is UML/UP applicable to areas other than software development? Suggest some applications

21. Summary (Cont.) What is not covered in the UP? When can we consider the software a success? Who is responsible for the ultimate success or the failure of the software? When can we consider the software development process a success?

22. Not covered Human Factors –Timeliness –Judgments and Evaluations –Sufficiency, Completeness, Soundness –Effect of culture Technical Factors –Choice of tools may affect product –Unknown exceptions in the domain –Technical issues intentionally/unintentionally ignored

23. Other topics Patterns and their effects Frameworks and their effects

24. Non Programmer Roles Systems Analyst Requirements Engineer Use-case engineer Software analyst Design Engineer Architect Component Engineer

25. Overall Experience Adoption of UP and UML Experience in large scale software Analysis and Design Experience in inter-group and intra-group discussions Multiple projects assist in revisiting analysis and design Development from other team deliverables Communication - oral and written Opportunity to contribute and assimilate from other projects First hand view of commonality among various software Non Programmer roles