1. Patterns Roberto Damiani Mendes

2. Roteiro Definition; Definition; Architecture Patterns; Architecture Patterns; Design Patterns; Design Patterns; GRASP Patterns; GRASP Patterns;

3. MOTIVATION Reuse; Reuse; Common Language; Common Language;

4. Definition Chirstopher Alexander says: “Each patterns describes a problem which occurs over and over again in our enviroment, and then describes their core of the solution to that problem, in such way that you can use this solution a million times over, without even doing it the same way twice”. Chirstopher Alexander says: “Each patterns describes a problem which occurs over and over again in our enviroment, and then describes their core of the solution to that problem, in such way that you can use this solution a million times over, without even doing it the same way twice”.GOF

5. Definition Patterns help you build on collective experience of skilled software enginer. They capture existing, well-proven experience em software development and help to promote good design practise. Every patterns deals with a specific, recurring problem in the design or implementation of a sofware system. Patterns can be used to contruct software architectures with specific properties [Buschmann]. Patterns help you build on collective experience of skilled software enginer. They capture existing, well-proven experience em software development and help to promote good design practise. Every patterns deals with a specific, recurring problem in the design or implementation of a sofware system. Patterns can be used to contruct software architectures with specific properties [Buschmann].

6. Essential Elements A patterns has four essential elements A patterns has four essential elements 1. Patterns name; 2. Problem; 3. Solution; 4. Consequences.

7. Pattern Name It’s a handler we can use to describe a design problem, its soltutions, and consequences in a word or two. It’s a handler we can use to describe a design problem, its soltutions, and consequences in a word or two. Finding good names has been one of the hardest parts of developing our catalog. Finding good names has been one of the hardest parts of developing our catalog.GOF

8. Problem It describes when to apply the pattern. It explains the problem and its context. It describes when to apply the pattern. It explains the problem and its context.

9. Solution It describes the elements that make up the design, their relationships, responsibilities, and collaborations. It describes the elements that make up the design, their relationships, responsibilities, and collaborations.

10. CONSEQUENCES The consequences are the results and trade-offs of applying the patterns.

11. ARCHITECTURAL PATTERNS Express fundamental structural organization schemas for software systems. They provide a set of predefined subsystems, specific their resposibilities, and include rules and guidelines for organizing the relationships between them [Buschmann]. Express fundamental structural organization schemas for software systems. They provide a set of predefined subsystems, specific their resposibilities, and include rules and guidelines for organizing the relationships between them [Buschmann]. Architectural patterns represent the highest-level patterns. Architectural patterns represent the highest-level patterns.

12. Pattern: Layers (Problem) Source code changes are rippling throughout the system – many part of systems are highly coupled; Source code changes are rippling throughout the system – many part of systems are highly coupled; Application logic is intertwined with user interface, and so can not be reused with a different interface, nor distributed to another processing node; Application logic is intertwined with user interface, and so can not be reused with a different interface, nor distributed to another processing node; Potentially general technical services or business logic is intertnwined with more application-specfic logic, and so can not reused, distributed to another node, or easily replaced with different implementation; Potentially general technical services or business logic is intertnwined with more application-specfic logic, and so can not reused, distributed to another node, or easily replaced with different implementation; There is high coupling across different areas concern. It is thus difficult to divide the work along clear bound aries for different developers; There is high coupling across different areas concern. It is thus difficult to divide the work along clear bound aries for different developers; Due to the high coupling and mixing of concerns, it is laborious and costly to evolve the applicattion’s functionality, scale up the system, or update it to use new technologies. Due to the high coupling and mixing of concerns, it is laborious and costly to evolve the applicattion’s functionality, scale up the system, or update it to use new technologies.

13. Pattern: Layers (Solution) Organize the large-scale logical structure of a system into discrete layers of distinct, related responsibilities, with a clean, cohesive separation of concerns such that the “lower” layers are low-level and general services and higher layers are more applications specific; Organize the large-scale logical structure of a system into discrete layers of distinct, related responsibilities, with a clean, cohesive separation of concerns such that the “lower” layers are low-level and general services and higher layers are more applications specific; Collaboration and coupling, is from higher to lower layers; lower-to-higher layer coupling is avoided. Collaboration and coupling, is from higher to lower layers; lower-to-higher layer coupling is avoided.

14. Pattern: Layers

15. Inter-Layer and Inter Package Coupling

17. Inter-Layer and Inter-Package Interaction Scenarios

18. DESIGN PATTERNS Design Patterns are medium-scale patterns. They are smaller in scale than architectural patterns, but are at a higher level than the programming language-specific idiom. Design Patterns are medium-scale patterns. They are smaller in scale than architectural patterns, but are at a higher level than the programming language-specific idiom.

19. CLASSIFICATION Purpose: should reflect what a pattern does. Purpose: should reflect what a pattern does. –Creational ->concern the process of object creation. –Structural ->category deal with the composition of classes or objects; –Bahavioural ->characterize the ways in which classes or objects interact and distribute responsibilities.

20. CLASSIFICATION Scope: specify whether a pattern applies primarily to classes or to object. Scope: specify whether a pattern applies primarily to classes or to object. –Object -> deal with object relationships; –Class -> deal with relationships between classes and their subclasses.

21. CLASSIFICATION GOF

22. ADAPTER Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.

23. STRUCTURE

24. EXAMPLE

25. FACADE Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use

26. STRUCTURE

27. EXAMPLE

28. COMPOSITE Composite lets clients treat individual objects and compositions of objects uniformly Composite lets clients treat individual objects and compositions of objects uniformly

29. STRUCTURE

30. EXAMPLE

31. DESIGN OBJECT After identifying your requirements and creating a domain model, then add methods to the software classes, and define the messaging between the objects to fulfill the requeriments. [Larman] After identifying your requirements and creating a domain model, then add methods to the software classes, and define the messaging between the objects to fulfill the requeriments. [Larman]

32. DESIGN OBJECT Decide what method belong where, and how the objects should interact, is terribly important and anything but trivial.[Larman] Decide what method belong where, and how the objects should interact, is terribly important and anything but trivial.[Larman]

33. GRASP General Responsibilitity Assignment Software Patterns The GRASP Patterns are a learning aid to help one understand essencial object design, and apply design reasoning in a methodical, rational, explainable way. The GRASP Patterns are a learning aid to help one understand essencial object design, and apply design reasoning in a methodical, rational, explainable way. This approach to undestanding and using design principles is based on patterns of assigning responsibilities. This approach to undestanding and using design principles is based on patterns of assigning responsibilities.

34. RESPONSIBILITY The UML define a responsibility as “ a contract or obligation of a classifier”[2]; The UML define a responsibility as “ a contract or obligation of a classifier”[2]; They are assigned to classes of objects during object design; They are assigned to classes of objects during object design; The skilfull assignment of responsibilities is extremely important in object design; The skilfull assignment of responsibilities is extremely important in object design; Determining and assignment of responsibilities often occurs during the creation of interaction diagrams, and certainly during programming Determining and assignment of responsibilities often occurs during the creation of interaction diagrams, and certainly during programming

35. RESPONSIBILITY x METHOD Responsibility is not same thing as a method, but method are implemented to fulfill responsibilities. Responsibility is not same thing as a method, but method are implemented to fulfill responsibilities.

36. GRASP PATTERNS They describe fundamental principles of object design and responsibility assignments, expressed as patterns. They describe fundamental principles of object design and responsibility assignments, expressed as patterns. GRASP Patterns: 1.Information Expert; 2.Creator; 3.High Cohesion; 4.Low Coupling; 5.Controller; 6.Polymorphism; 7.Fabrication; 8.Indirection; 9.Protected Variactions;

37. INFORMATION EXPERT Problem: What is a principle of assingment responsibilities to objects? Solution: Assign a responsibility to the information expert. The class that has the information necessary to fulfill the resposibility.

38. CREATOR Problem: Who should be responsible for creating a new instance os some class? Solution:Assign class B the resposibility to create an instance of class A if one or more of the following is true: B aggregates A objects; B aggregates A objects; B cotains A objects; B cotains A objects; B records instances of A objects; B records instances of A objects; B closely uses A object; B closely uses A object; B has the initializing data that will be passed to A when it is created(thus B is an Expert with respect to creating A) B has the initializing data that will be passed to A when it is created(thus B is an Expert with respect to creating A)

39. LOW COUPLING Problem: How to support low dependency, low change impact, and increase reuse? Solution: Assign a resposibility so that coupling reamains low.

40. HIGH COHESION Problem:How to keep complexity manageable? Solution: Assign a responsibility so that cohesion remains high;

41. CONTROLLER Problem: Who should be responsible for handling an input system event? Problem: Who should be responsible for handling an input system event?

42. CONTROLLER Solution:Assign the responsibility for receiving or handling a system event message to a class representing one of the following choices: Represents the overall system, device, or subsystem(facade controller); Represents the overall system, device, or subsystem(facade controller); Represents a use case scenario within which the system event occurs. Represents a use case scenario within which the system event occurs.

43. POLYMORPHISM PROBLEM: How to handle alternatives based on type? How create pluggable software components? Solution: When related alternatives or behaviors vary by type(class), assign responsibility for the bahavior – using polymorphic operations – to the types for which the behavior varies.

44. FABRICATION Problem: What object should have the responsibility when you do not want to violate High Cohesion and Low Coupling, or other goals, but solutions offered by Expert (for example) are not appropriate? Solution:Assign an highly cohesive set of responsibilities to an artificial or convenience class that does not represent a problem domain concept – something made up, to support high cohesion, low coupling, and reuse.

45. INDIRECTION Problem: Where to assign a responsibility, to avoid direct coupling between two (or more) things? How to de-couple objects so that low coupling is supported and reuse potencial remains higher? Solution: Assign the responsibility to an intermediate objetc to mediate between other componets or services so that they are not directly coupled.

46. PROTECTED VARIATIONS Problem: How to design objects, subsystems, and systems so that the variations or instanbility in these elements does not have an undesirable impact on other elements? Solution: Identify point of predicted variation or instability; assign responsibilities to create a stable interface around them.

47. IDIOMS Idioms are low-level patterns specific to a programming language. Idioms are low-level patterns specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them with the features of the given language An idiom describes how to implement particular aspects of components or the relationships between them with the features of the given language

49. REFERENCES [3] Larman, G., Applying UML and PATTERNS – Second Edition. [3] Larman, G., Applying UML and PATTERNS – Second Edition.