The document provides an overview of software patterns including their objectives, types, UML modeling elements and diagrams, and examples of design patterns like Template Method and Strategy. It discusses architectural patterns like layers, MVC, and SOA. It also covers design patterns like Template Method, Strategy, and Iterator in terms of their intent, participants, consequences, and implementations.
34. Models, Views, and Diagrams Activity Diagrams A model is a complete description of a system from a particular perspective Models Use Case Diagrams Use Case Diagrams Use Case Diagrams Scenario Diagrams Scenario Diagrams Collaboration Diagrams State Diagrams State Diagrams Component Diagrams Component Diagrams Component Diagrams Deployment Diagrams State Diagrams State Diagrams Object Diagrams Scenario Diagrams Scenario Diagrams Statechart Diagrams Use Case Diagrams Use Case Diagrams Sequence Diagrams State Diagrams State Diagrams Class Diagrams
84. Architecture and the UML Design View Implementation View Process View Deployment View Organization Package, subsystem Dynamics Interaction State machine Components Classes, interfaces, collaborations Active classes Nodes Use Case View Use cases
87. System Architecture Logical View Implementation View Programmers Software management Process View Deployment View System topology Delivery, installation Communication System engineering Conceptual Physical Use Case View Conceptual Physical End-user Functionality Performance Scalability Throughput System integrators
88.
89. Frank Buschmann, Douglas Schmidt, Michael Stal, Hans Rohnert. Pattern-oriented Software Architecture Vol 2: Patterns for Concurrent and Networked Objects. John Wiley and Sons Ltd. 2000.
90.
91.
92. How a big system could be broken down into smaller components ?
121. Architecture is making decisions The life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partly in the dark.
142. Each pattern is a three-part rule , which expresses a relation between a certain context , a problem , and a solution .
143. GoF: The design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context
144.
145. Patterns are common solutions to recurring problems. If you have worked in applications for a while, you may well know most of them. They are industry’s old ideas . If you are new , pattern book can help you learn about those techniques. If you are familiar with the techniques, pattern book can help you communicate and teach them to others. An important part of patterns is trying to build a common vocabulary for communication . (Fowler)
146. Patterns constitute an effort to build on the collective experience of skilled designers and software engineers. (Buschmann et al.)
147. Experts already have solutions to many recurring design problems . (Buschmann et al.)
148. Patterns capture proven solutions in an easily-available and, hopefully, well-written form (Buschmann et al.)
149. Patterns support both novices and experts in software development. (Buschmann et al.)
203. A service is a unit of work done by a service provider to achieve desired end results for a service consumer
204. in SOA, services are the mechanism by which needs and capabilities are brought together.
205.
206. Interaction - the activity of using a capability. (usually message exchange - by contracts, constraints and policies, for example Web Service Description Language)
229. A class defines many behaviors, and these appear as multiple conditional statements in its operations. Instead, move related conditional branches into their own Strategy class.
259. Observer and observable are bonded in a contract and can be completely loosely coupled from one another.
260.
261. ensure that a class has only one instance, and to provide a global point of access to it Example: Class SomeClass { static SomeClass singleTonInstance = null; static SomeClass GetInstance() { if(singleTonInstance == null) singleTonInstance = new SomeClass() return singleTonInstance; } }
262.
263. Can be given to client (abstract), pass construction parameters or read creation types from configuration or system environment
265. Factory design pattern - example abstract class GUIFactory { public static GUIFactory getFactory() { int sys = readFromConfigFile("OS_TYPE"); return sys == 0 ? new WinFactory() : new OSXFactory(); } public abstract Button createButton(); } class WinFactory:GUIFactory { public override Button createButton() { return new WinButton(); } } class MacFactory:GUIFactory { public override Button createButton(){ return new MacButton(); } } abstract class Button { public string caption; public abstract void paint(); }
266. class WinButton:Button { public override void paint() { // paint a button with Win API…} } class MacButton:Button { public override void paint() { // paint a button Mac style… } } class Application { static void Main(string[] args) { GUIFactory aFactory = GUIFactory.getFactory(); Button aButton = aFactory.createButton(); aButton.caption = "Play"; aButton.paint(); } } Factory design pattern - example
267.
268. Provide a unified interface to a set of interfaces in a subsystem without damaging the genric form of the sub system.
271. Example: Java.IO package BufferedReader br = new BufferedReader( new InputStreamReader( new FileInputStream(inFile))); All derives from abstract io.Reader
273. Example // the Window interface interface Window { public void draw(); // draws the Window public String getDescription(); // returns a description of the Window } // implementation of a simple Window without any scrollbars class SimpleWindow implements Window { public void draw() { // draw window } public String getDescription() { return "simple window"; } } // abstract decorator class - note that it implements Window abstract class WindowDecorator implements Window { protected Window decoratedWindow; // the Window being decorated public WindowDecorator (Window decoratedWindow) { this.decoratedWindow = decoratedWindow; } }
274. Example // the first concrete decorator which adds vertical scrollbar functionality class VerticalScrollBarDecorator extends WindowDecorator { public VerticalScrollBarDecorator (Window decoratedWindow) { super(decoratedWindow); } public void draw() { drawVerticalScrollBar(); decoratedWindow.draw(); } private void drawVerticalScrollBar() { // draw the vertical scrollbar } public String getDescription() { return decoratedWindow.getDescription() + ", including vertical scrollbars"; } } // the second concrete decorator which adds horizontal scrollbar functionality class HorizontalScrollBarDecorator extends WindowDecorator { public HorizontalScrollBarDecorator (Window decoratedWindow) { super(decoratedWindow); } public void draw() { drawHorizontalScrollBar(); decoratedWindow.draw(); } private void drawHorizontalScrollBar() { // draw the horizontal scrollbar } public String getDescription() { return decoratedWindow.getDescription() + ", including horizontal scrollbars"; } }
275. Example public class DecoratedWindowTest { public static void main(String[] args) { // create a decorated Window with // horizontal and vertical scrollbars Window decoratedWindow = new HorizontalScrollBarDecorator ( new VerticalScrollBarDecorator( new SimpleWindow())); // print the Window's description System.out.println(decoratedWindow.getDescription()); } } Output: "simple window, including vertical scrollbars, including horizontal scrollbars"
276.
277. defines a family of interchangeable encapsulated algorithms that receives the same input type and provides the same output type in different manners that can be determined in run-time. static void Main( { SortedList studentRecords = new SortedList(); studentRecords.Add("Samual"); studentRecords.Add("Jimmy"); studentRecords.Add("Sandra"); studentRecords.SetSortStrategy(new QuickSort()); studentRecords.Sort(); studentRecords.SetSortStrategy(new ShellSort()); studentRecords.Sort(); }
278. Strategy Pattern - example abstract class SortStrategy { public abstract void Sort(ArrayList list) } class QuickSort : SortStrategy { public override void Sort(ArrayList list) { list.Sort(); // Default is Quicksort } } class ShellSort : SortStrategy { public override void Sort(ArrayList list) { //list.ShellSort(); not-implemented } }
279. class SortedList { private ArrayList list = new ArrayList(); private SortStrategy sortstrategy; public void SetSortStrategy(SortStrategy sortstrategy) { this.sortstrategy = sortstrategy; } public void Add(string name) { list.Add(name); } public void Sort() { sortstrategy.Sort(list); } } Strategy Pattern - example
335. Adapter makes existing unrelated classes work together; whereas Bridge is used in design in effort to avoid needing Adapters later
336.
337. This design pattern coordinates the concurrent production and consumption of information among producer and consumer objects that are working on different threads.
346. What is new is naming them and writing them down.
347. One drawback (from personal experience) is to assume everyone knows the pattern. Design documentation should note the name of the design pattern used, but that shouldn’t be the extent of the documentation.
356. Need to fill in the “white space” between the patterns.
357. Through teaching / discussion, patterns may support “generativity” – helping the reader solve problems that the pattern doesn’t address explicitly.
358.
359. Patterns can be found in analysis, maintenance, testing, documentation, organizational structure, etc.