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.

1. Software Patterns Sudarsun Santhiappan Director – Research & Development Burning Glass Technologies Chennai 600010

3. Diagrammatic Representation

4. Software Architecture

5. Architecture Patterns

6. Design Patterns

8. Not a programming language oriented lecture, we will mainly discuss the paradigms and uses with examples in various programming languages.

10. Procedural Programming

13. design (micro-architectures) [Gamma-GoF]

15. organization patterns (structure of organizations/projects)

16. process patterns (software process design)

17. domain-specific patterns

19. specifying

20. constructing

21. documenting the artifacts of a software-intensive system

23. Relationships

24. Extensibility Mechanisms

25. Diagrams

28. Association

29. Generalization

30. Realization

32. Tagged value

33. Constraint

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

36. Provides a partial representation of the system

38. Dynamic views: sequence, collaboration, statechart, activity

41. Built in early stages of development

43. Capture the requirements of a system

44. Validate a system’s architecture

48. Built and refined throughout development

50. Specify collaborations

54. Built during analysis and design

59. Built as part of architectural specification

61. Construct an executable release

65. Built as part of architectural specification

71. Illustrate typical scenarios

75. Illustrate coordination of object structure and control

79. Model reactive objects (user interfaces, devices, etc.)

83. Model operations

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

86. An architectural prototype

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

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.

92. How a big system could be broken down into smaller components ?

93. Shared understanding of a system

94. How major components fit together ?

95. How components interact ?

98. behavior as specified in collaborations among those elements

99. Composition of these structural and behavioral elements into larger subsystem

100. architectural style that guides this organization

102. functionality

103. performance

104. resilience

105. reuse

106. comprehensibility

107. economic and technology constraints and trade offs

108. aesthetic concerns

111. Leadership, authority

115. Maintaining the architectural integrity of the software

116. Assessing technical risks related to the software design

117. Proposing the order and contents of the successive iterations

118. Consulting services

119. Assisting marketing for future product definition

120. Facilitating communications between project teams

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.

124. Important mechanisms

125. Processors and processes

126. Layers and subsystems

129. Identify main classes and their responsibility

130. Distribute behavio r on classes

131. Structure in subsystems, layers, define interfaces

132. Define distribution and concurrency

133. Implement architectural prototype

134. Derive tests from use cases

135. Evaluate architecture Iterate Use case view Logical view Deployment view Implementation view Process view

137. A pattern codifies specific knowledge collected from experience in a domain

139. Design patterns

140. Architectural patterns

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

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.)

150. Architectural Patterns

152. Event-driven  MVC

153. Frame-based  IR-centric

154. Batch  Subsumption

155. Pipes and filters  Disposable

156. Repository-centric

157. Blackboard

158. Interpreter

159. Rule-based

161. The controller changes the model

162. The View Listens to Model

163. Process Control!

165. What is high? What is low?

167. answers from lower layer to higher layer

168. incoming data or event notification from low to high

170. Interfaces should be stable

171. Interfaces may be prescribed by a standards body

172. Parts of the system should be exchangeable

173. Design for change!

174. May be necessary to build other systems at a later date with same low-level issues

175. Similar responsibilities should be grouped to help understandability and maintainability

176. No standard component granularity

177. Complex components may need further decomposition

179. Architecture influences team structure and vice versa

181. Think of lowest level as Layer 1; highest Layer N

182. This gives a conceptual view – not marching orders regarding sequence of further design

183. Within a layer, all subcomponents work at the same level of abstraction

184. Most of what Layer J provides is composed of services provided by Layer J-1, combined in a meaningful way for the application.

185. Illustration

187. Determine the number of abstraction levels according to your criterion

188. Name the layers and assign tasks to each of them

189. Specify the services

197. APIs

199. Application Logic

200. Domain Layer

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.

206. Interaction - the activity of using a capability. (usually message exchange - by contracts, constraints and policies, for example Web Service Description Language)

207. Effect – the result of an interaction

208. SOAP: Simple Object Access Protocol

209. WSDL: Web Service Description Language

210. SOA - example

211. Idioms

214. Design Patterns

217. Structural

218. Behavioral

219. Design Patterns Catalog

222. When common code in subclasses should be factored and localized in a common base class to avoid code duplication.

223. To control extensions to subclasses. (Hook operations)

227. You need different variants of an algorithm. For example, defining different algorithms based on space-time tradeoffs.

228. An algorithm uses data that a client shouldn’t know about.

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.

231. Maintains a reference to a Strategy object

232. May define an interface that lets Strategy access its data.

234. ShellSort

237. Alternative to subclassing which allows the developer to vary the algorithm independent of its context.

238. Strategies eliminate conditional statements.

240. Communication overhead between Strategy and Context – some concrete strategies may not need all the parameters passed into them.

241. Increased number of objects. See Flyweight pattern for an approach to solve this.

243. To implement multiple algorithms to traverse those nodes.

244. Class Diagram

247. Client hands an operation to the Iterator, Iterator tells every child in the aggregate to perform it.

252. It does this through registering the iterator with the aggregate. If any nodes are removed, it is notified.

256. Goes to a node matching specific criteria

259. Observer and observable are bonded in a contract and can be completely loosely coupled from one another.

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; } }

263. Can be given to client (abstract), pass construction parameters or read creation types from configuration or system environment

264. Can use object pool (Lightweight)

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

268. Provide a unified interface to a set of interfaces in a subsystem without damaging the genric form of the sub system.

270. Avoid excessive sub-classing and gain run time flexibility

271. Example: Java.IO package BufferedReader br = new BufferedReader( new InputStreamReader( new FileInputStream(inFile))); All derives from abstract io.Reader

272. Example

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"

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

282. Virtual Proxy – Creates expensive objects on demand.

283. Protection Proxy – Controls access to the original object.

285. Initial loading of persistent objects.

286. Object locking.

288. Provide identical interface to Subject so the Proxy can be substituted.

290. Proxy Pattern: Structure

291. Proxy Pattern: Example class Image; class ImagePtr { public: ImagePtr(const char* file); virtual ~ImagePtr(); virtual Image* operator->(); virtual Image& operator*(); private: Image* _image; const char* _file; Image* LoadImage(); }; Image* ImagePtr::LoadImage(){ If (_image == 0 ) { _image = LoadAnImageFile(_file); } return _image; } Image* ImagePtr::operator->() { return LoadImage(); } Image& ImagePtr::operator*(){ return *LoadImage(); } To implement the Real Subject methods: ImagePtr image = ImagePtr(“aFile”); image->Draw(Point(50,100)); //(image.operator->())->Draw(Point(50,100))

293. A Virtual Proxy can perform optimizations such as creation on demand.

297. Has both class and object forms

298. Adapts the interface of one class into that of an otherwise incompatible class

300. create reusable class that will play nice with others

301. use several subclasses without having to subclass each one to adapt their interface (object form)

305. Adapter can override Adaptee’s behavior

307. harder to override Adaptee behvarior – have to subclass Adaptee and make Adapter refer to the subclass

310. use multiple inheritance

314. put operations in abstract delegate class for different Adapters to subclass

316. Decorator – enhances object without changing its interface. Thus more transparent and supports recursive composition

317. Proxy – defines surrogate for another object without changing its interface

319. Decouples abstraction from its implementation

321. make both abstraction and implementations independently extensible

322. change implementation or abstraction without impacting clients, or hide them from clients

323. share implementation among clients without letting them know

332. change at runtime?

335. Adapter makes existing unrelated classes work together; whereas Bridge is used in design in effort to avoid needing Adapters later

337. This design pattern coordinates the concurrent production and consumption of information among producer and consumer objects that are working on different threads.

338. This pattern is used with some type of semaphore

339. Consumer/Producer - example static AutoResetEvent eventProducerDone = new AutoResetEvent(false); static AutoResetEvent eventConsumerDone = new AutoResetEvent(false); static int currentNum = 0; static void produce(object stateInfo) { eventProducerDone.Set(); while (true) { //wait for the consumer eventConsumerDone.WaitOne(); currentNum++; eventProducerDone.Set(); } }

340. static void Main(string[] args) { ThreadPool.QueueUserWorkItem(new WaitCallback(produce)); for (int i = 0; i < 20; i++) { eventProducerDone.WaitOne(); System.Diagnostics.Debug.WriteLine(currentNum); eventConsumerDone.Set(); } } Consumer/Producer - example

343. Patterns teach , so that the developer can tailor the solution to a variant of the problem.

344. Patterns have a name .

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.

349. Don’t make assumptions about all patterns based on a few patterns.

351. Pattern names form a vocabulary which helps developers communicate.

352. Documenting the design with the patterns in use helps people understand the system more quickly.

353. Patterns facilitate restructuring a system whether or not it was designed with patterns in mind.

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.

359. Patterns can be found in analysis, maintenance, testing, documentation, organizational structure, etc.

361. Thank You... [email_address]