Patterns Roberto Damiani Mendes. Roteiro Definition; Definition; Architecture Patterns; Architecture Patterns; Design Patterns; Design Patterns; GRASP.

Slides:



Advertisements
Similar presentations
GRASP: Designing Objects with Responsibilities
Advertisements

Object-Oriented Analysis and Design CHAPTER 17, 25: GRASP PATTERNS 1.
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
GRASP Patterns M Taimoor Khan
March R McFadyen1 Architecture Architecture involves the set of significant decisions about the organization of a software system, decisions.
© 2005 Prentice Hall8-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
NJIT More GRASP Patterns Chapter 22 Applying UML and Patterns Craig Larman Prepared By: Krishnendu Banerjee.
NJIT 1 GRASP: Designing Objects with Responsibilities Chapter 17 Applying UML and Patterns Craig Larman.
GRASP : Designing Objects with Responsibilities
October 20, 2005Architectural Design, ECEN Architectural Design Architecture Business Cycle Design for Maintainability ECEN 5543 / CSCI 5548 SW Eng.
CMPT 370: Information Systems Design Instructor: Curtis Cartmill, Simon Fraser University – Summer 2003 Lecture Topic: Layered Architecture Class Exercise:
PRESENTED BY SANGEETA MEHTA EECS810 UNIVERSITY OF KANSAS OCTOBER 2008 Design Patterns.
Logical Architecture and UML Package Diagrams
Feb 4, Ron McFadyen1 founded on principles of good OO design idea was first put forth by Christopher Alexander (1977) in their work concerning.
Design Patterns Discussion of pages: xi-11 Sections: Preface, Forward, Chapter
Chapter 13 Starting Design: Logical Architecture and UML Package Diagrams.
Logical Architecture and UML Package Diagrams 徐迎晓 复旦大学软件学院.
GRASP Pattern Zhen Jiang West Chester University
GRASP Principles. How to Design Objects The hard step: moving from analysis to design How to do it? –Design principles (Larman: “patterns”) – an attempt.
05 - Patterns Intro.CSC4071 Design Patterns Designing good and reusable OO software is hard. –Mix of specific + general –Impossible to get it right the.
Chapter 17. GRASP General Responsibility Assignment Software Patterns (Principles) OOD: after identifying requirements, create domain model, define responsiblities.
An Introduction to Design Patterns. Introduction Promote reuse. Use the experiences of software developers. A shared library/lingo used by developers.
1 SAD2 - UML 4 th Lecture Class Diagram in Construction Phase Patterns Case Study Lecturer: Dr Dimitrios Makris
SOEN 6011 Software Engineering Processes Section SS Fall 2007 Dr Greg Butler
Architecture GRASP Realization of use cases in interaction diagrams Design class diagram Design ( how )
Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman.
BTS430 Systems Analysis and Design using UML Design Patterns.
Chapter 17. Initial Object Design Inputs: requirements meetings various Use Cases – 10% complete Key risks addressed with preliminary programming System.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 27. Review UML dynamic view – State Diagrams.
Chapter 17 GRASP: Designing Objects with Responsibilities. 1CS6359 Fall 2011 John Cole.
Design Patterns. Patterns “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution.
CS212: Object Oriented Analysis and Design GRASP Design Principles.
COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler
Copyright © Craig Larman All Rights Reserved Responsibility-Driven Design with the GRASP Patterns.
Design Patterns CSCI 5801: Software Engineering. Design Patterns.
D ESIGN P ATTERNS Weslei A. de T. Marinho. T ALK O UTLINE Pattern Definition GRASP Patterns GoF Patterns GoF Patterns Classification Creational Patterns.
GRASP: Designing Objects with Responsibilities
IntellAgile Copyright © 2002 Craig Larman. All rights reserved. Object Design and Use- Case Realizations with GRASP Patterns.
What to remember from Chap 13 (Logical architecture)
ECE450S – Software Engineering II
OO Methodology Elaboration Iteration 2 - Design Patterns -
Copyright © Active Frameworks Inc. - All Rights Reserved - V2.0Design Pattern Catalog - Page L3-1 PS95&96-MEF-L10-1 Dr. M.E. Fayad Creationa.
OO Design Roshan Chitrakar. Analysis to Design Do the RIGHT thing Do the RIGHT thing Requirement Analysis Requirement Analysis Domain Modeling with addition.
TK2023 Object-Oriented Software Engineering CHAPTER 8 LOGICAL ARCHITECTURE.
Copyright © Craig Larman All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:
Chapter 17 Designing with Responsibilities. Fig
References: Applying UML and patterns Craig Larman
Design. 2 The Need for Software Blueprints Knowing an object-oriented language and having access to a library is necessary but not sufficient in order.
GRASP: More Patterns for Assigning Responsibilities Presented By Dr. Shazzad Hosain.
General Principles in Assigning Responsibilities Responsibilities Responsibility-Driven Design CRC Cards GRASP.
Elaboration: Iteration 2. Elaboration: Iteration 2 Basics Iteration 1 ends with : All the software has been tested: The idea in the UP is to do early,
GRASP – Designing Objects with Responsibilities
Design Patterns: MORE Examples
Software Design Patterns
GoF Patterns (GoF) popo.
Chapter 12: Collaboration Diagram - PART2
Conception OBJET GRASP Patterns
DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS
OO Methodology OO Architecture.
Apply Expert, Creator, Controller, Low Coupling, High Cohesion
The Object Oriented Approach to Design
GRASP : Designing Objects with Responsibilities
Object Oriented Design Patterns - Structural Patterns
Patterns.
SOEN 343 Software Design Computer Science and Software Engineering Department Concordia University Fall 2005 Instructor: Patrice Chalin.
Starting Design: Logical Architecture and UML Package Diagrams
SOEN 343 Software Design Computer Science and Software Engineering Department Concordia University Fall 2004 Instructor: Patrice Chalin.
Chapter 22 Object-Oriented Systems Analysis and Design and UML
Logical Architecture & UML Package Diagrams
GoF Patterns Ch. 26.
Presentation transcript:

Patterns Roberto Damiani Mendes

Roteiro Definition; Definition; Architecture Patterns; Architecture Patterns; Design Patterns; Design Patterns; GRASP Patterns; GRASP Patterns;

MOTIVATION Reuse; Reuse; Common Language; Common Language;

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

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

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

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

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.

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.

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

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.

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.

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.

Pattern: Layers

Inter-Layer and Inter Package Coupling

Inter-Layer and Inter-Package Interaction Scenarios

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.

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.

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.

CLASSIFICATION GOF

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.

STRUCTURE

EXAMPLE

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

STRUCTURE

EXAMPLE

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

STRUCTURE

EXAMPLE

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]

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]

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.

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

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.

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;

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.

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)

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

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

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

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.

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.

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.

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.

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.

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

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