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/Patterns.aspx • http://c2.com/cgi/wiki?DesignPatterns • http://channah.com/portfolio/talk/Paper/GoF-patterns/ • http://www.patterndepot.com/put/8/JavaPatterns.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