Patterns

1. Patterns Roberto Damiani Mendes

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

3. MOTIVATION • Reuse; • 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”. 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].

6. Essential Elements • A patterns has four essential elements • Patterns name; • Problem; • Solution; • 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. • 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.

9. Solution • 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]. • 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; • 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; • 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.

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

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

19. CLASSIFICATION • 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. • 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.

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

26. STRUCTURE

27. EXAMPLE

28. COMPOSITE • 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]

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

33. GRASPGeneral 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. • 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]; • They are assigned to classes of objects during 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

35. RESPONSIBILITY x METHOD • 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. GRASP Patterns: • Information Expert; • Creator; • High Cohesion; • Low Coupling; • Controller; • Polymorphism; • Fabrication; • Indirection; • 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 cotains A objects; • B records instances of A objects; • 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)

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?

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