GRASP: Patterns for. chapter18
|
|
- Randolf Bruce
- 5 years ago
- Views:
Transcription
1 GRASP: Patterns for assigning responsibility chapter18 1
2 Chapter Objectives Learn about design patterns Learn how to apply five GRASP patterns 2
3 Building Collaboration diagrams System Design: how the system will do what we decided it should do We must identify software classes and assign responsibilities. For each operation contract we build a collaboration diagram. We work through the postcondition state changes and design message interactions to satisfy the requirements. In doing so, we assign responsibilities to objects. Poor choices lead to hard to implement, maintain, reuse, or extend system design 3
4 Building Collaboration diagrams, cont Interaction diagrams are one of the most important artifacts created in OOAD. The skillful assignment of responsibilities that occurs while creating collaboration diagrams is very important. The amount of time and effort spent on their generation, and the careful consideration of responsibility assignment, should absorb a significant percentage of the design phase. Codified patterns, principles and idioms can be applied to improve the quality of their design. 4
5 Responsibilities and methods Responsibilities are related to the obligations of an object in terms of its behavior. Two types of responsibilities: 1. Doing responsibilities : Doing something itself (on its attributes). Initiating actions in other objects (by calling functions in them). Controlling and coordinating activities in other objects (receiving data from one object an send them to another object). 2- Knowing responsibilities : Private encapsulated data. Related objects. Things it can derive or calculate. 5
6 Responsibilities and methods, cont Responsibilities are assigned to objects during design. Example: Sale responsibilities 1. Printing itself (doing) 2. Knowing its date Responsibilities related to knowing (who know who) are often detected from conceptual model from the attributes and associations 6
7 Responsibilities and methods, cont responsibility method A responsibility is not the same thing as a method, but methods are implemented to fulfill responsibilities. For example, provide access to a relational database may involve dozens of classes and hundreds of methods, whereas create a Book Entry may involve only one or few methods. Methods either act alone or collaborate with other methods and objects. For example, Sale has a responsibility named print. To fulfill this responsibility, the Sale may collaborate with other objects, such as sending a message to SaleLineItem objects asking them to print themselves. 7
8 Responsibilities and Collaboration Diagrams print () :Sale 1*:[for each] sli:=next() :SaleLineItem 2:print() sli:salelineitem Responsibility of Sale objects is to print themselves Methods asking collaboration with other objects to print themselves 8
9 GRASP Describe fundamental principles of object design and responsibility. Acronym for General Responsibility Assignment Software Patterns GRASP is expressed as patterns. Patterns are problem/solution pairs that guide in assigning responsibilities by giving advice in how to apply it in varying circumstances Pattern Name: Name Solution: Proposed solution of a problem Problem it solves: describes the problem that this pattern solves 9
10 GRASP There are 5 basic GRASP patterns: 1. Expert. 2. Creator. 3. Low coupling. 4. High cohesion. 5. Controller. 10
11 1- The Expert Pattern Problem: What is the most basic principle of assigning responsibilities to objects? Solution: Assign a responsibility to the information expert class i.e. the class that has the information necessary to fulfill the responsibility is given the responsibility. Start by clearly stating the responsibility: Example: In POST, who should be responsible for knowing the grand total of the sale? By expert pattern, we should look for that class that has the information needed to determine the total. 11
12 Expert Example 12
13 Expert Example, cont Step 1: What information is needed to determine the grand total? It is necessary to know about all the SaleLineItems instances composing the Sale and their subtotals. Only Sale object knows the information about SaleLineItems it contains. So by Expert pattern, the Sale object is the information expert and should be one of its responsibilities to compute the sale total. Collaboration diagram so far: 13
14 Expert Example, cont Step 2: To determine the SaleLineItem subtotals, what information is needed? - We need SaleLineItem.quantity and Productspecfication.price. - The SaleLineItem object knows its quantity and its associated Productspecfication (which contains the price). -Thereby by Expert pattern, SaleLineItem object should determine the subtotal as it is the information expert. Collaboration diagram so far: T:=getTotal() :Sale 2: st:=subtotal() sli:salelineitem 1*:[for each] sli:=next() :SaleLineItem 14
15 Expert Example, cont Step 3: Finally, how the SaleLineItem will compute its subtotal? It should know its item price through ProductSpecfication. Thus, the ProductSpecfication object is the information expert of the item price; therefore a message must be sent to it from SaleLineItem object asking for the price. Thus, ProductSpecfication must have a method called price() that returns the item price. 15
16 Expert Example, cont T:=getTotal() From step1 :Sale 2: st:=subtotal() From step2 1*:[for each] sli:=next() :SaleLineItem sli:salelineitem 2.1: p:=price() From step3 :Product Specification 16
17 Expert Example, cont Class Responsibilities Class Responsibility Sale Knows sale total SaleLineItem ProductSpecification Knows line item subtotal Knows product price 17
18 2- The Creator Pattern Problem: Who should be responsible for creating a new instance of some class? The creation of objects is one of the most common activities in OO system. If assigned well, the design can support low coupling, encapsulation and reusability. Solution: Assign class B the responsibility to create an instance of class A if one or more of the following is true: B aggregates A objects. B contains A objects. B records instances of A objects. 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). 18
19 2- The Creator Pattern Thus B is called a creator of A objects. If more than option applies, prefer a class B which aggregates or contains class A. Example: In POST, who should be responsible for creating a SaleLineItem instance? By Creator, we should look for the class that aggregates, contains, records, closely uses, or has initializing data for SaleLineItem instances. 19
20 Creator Example From the conceptual model, a Sale contains (aggregates) many SaleLineItem objects. By creator, Sale is a good candidate to have the responsibility of creating SaleLineItem instances. A method called makelineitem is defined in Sale class to create the SaleLineItem objects (1.*). makelineitem(quantity) :Sale A new method is added to the Sale class Sale 1: create(quantity) Date Time :SaleLineItem gettotal() makelineitem() 20 20
21 3-Low Coupling Pattern Coupling: it is a measure of how strongly one element is connected to, has knowledge of, or relies upon other elements. A class with high coupling depends on many other classes (libraries, tools). Problems because of a design with high coupling: Changes in related classes force local changes. Harder to understand in isolation; need to understand other classes. Harder to reuse because it requires additional presence of other classes. 21
22 3Low Coupling Pattern, cont Problem: How to support low dependency, low change impact and increased reuse? Solution: Assign a responsibility so that coupling remains low. Example: In POST, we need to create a Payment instance and associate it with the Sale. Which class should be responsible for this? (creator) Payment POST Sale 22
23 Low coupling example - Since a POST records a Payment, by Creator, a POST should be responsible for creating a Payment instance p. - The POST instance then sends an addpayment message to the Sale, passing the new Payment instance as parameter. makepayment( ) :POST 1: create() p:payment 2: addpayment(p) :Sale - This solution couples POST with the knowledge of Payment class. 23
24 Low coupling example, cont Another alternative is to make Sale class responsible for creating a Payment and associate it with the Sale. makepayment( ) :POST 1: addpayment() :Sale 1.1: create() :Payment In both cases, eventually, Sale has to be coupled with the knowledge of Payment first design has an extra coupling. While second design does not increase coupling. We may face Low coupling vs. Creator tradeoff. 24
25 3- Low Coupling Pattern, cont There is no specific measurement for coupling, but in general, classes that are generic and simple to reuse have low coupling. Coupling will lead to highly interacting classes. There will always be some coupling among objects, otherwise, there would be no collaboration. A subclass is strongly coupled to its superclass. The decision to derive a subclass from superclass must be carefully considered as it produces a strong form of coupling. 25
26 3- Low Coupling Pattern, cont Benefits: Understandability: Classes are easier to understand in isolation Maintainability: Classes aren t affected by changes in other components Reusability: easier to grab hold of classes 26
27 4- High cohesion pattern Cohesion: (functional cohesion)it is a measure of how strongly related and focused the responsibilities of a class are. A class with low cohesion does many unrelated activities or does too much work. A class with high cohesion has highly related responsibilities, and does not do a large amount of work by itself. Problems because of a design with low cohesion: Hard to understand. Hard to reuse. Hard to maintain. 27
28 4- High cohesion pattern, cont Problem: How to keep complexity manageable? Solution: Assign a responsibility so that cohesion remains high. Example: In POST, we need to create a Payment instance and associate it with the Sale. Which class should be responsible for this? Payment POST Sale 28
29 High cohesion example Since a POST records a payment, by Creator, a POST should be responsible for creating a payment instance. makepayment( ) :POST 1: create() p:payment 2: addpayment(p) : Sale This solution gives the responsibility of creating payment with POST who records it (creator). We add more unrelated responsibilities to POST, thus it became incohesive. We can not let POST instance do all the work related to 29it.
30 High cohesion example, cont - Another alternative is to make Sale responsible for (take the job from POST) creating a Payment and associate it with it. makepayment( ) :POST 1: addpayment() :Sale 1.2: create() : Payment This solution supports high cohesion and low coupling more desirable than Creator. 30
31 4- High cohesion pattern, cont Benefits: Understandability: Clarity & ease of comprehension. Maintainability: Maintenance and enhancement is easier. Complements Low Coupling 31
32 5- The Controller Pattern Problem: Who should be responsible for handling an input system event? A system event is a high level system generated by an external actor; it is an external input event (which is found in the SSD). They are associated with system operations. For a cashier (external actor) using an a POST presses the EndSale button, he is generating a system event indicating the sale has ended. A controller is a non-user interface object responsible for handling a system event. A controller defines the method for the system operation. 32
33 5- The Controller Pattern, cont Solution: Assign the responsibility for receiving or handling a system event message to a class representing one of the four following choices: Represents the overall system. (façade controller) Represents the overall organization. (façade controller) Represents something in the real world that is active (the role of a person) that might be involved in the task. (role controller) Represents an artificial handler of all system events of a use case. (usecase controller) use the name <Use case name>handler Each use case has one controller for its operations (1 use case = 1 controller for all system events in the same use case) Note that windows, applets, etc. typically receive events and delegate them to a controller. They are NOT controllers. 33
34 5- The Controller Pattern, cont Example: In POST system, there are several system operations. Who should be the controller for the system events such as enteritem? There are many choices: System endsale() enteritem() makepayment() enteritem() :POST Overall System (façade controller) enteritem() :Store Overall Organization (façade controller) enteritem() :Cashier Active real world something (role controller) enteritem() :BuyItemHandler Artificial handler of all use case operations 34 (use-case controller)
35 5- The Controller Pattern, cont 35
36 5- The Controller Pattern, cont Many different controller can be used for different use cases. A common problem with the controller class is that it has much responsibilities (bloated controller), thus it should give some of the other work to other classes. Whichever you pick: never implement system operations in UI classes. only coordinate other objects responsibilities in the controller. POST endsale() enteritem() makepayment() POST if chosen to be the controller class 36
37 Summary Skillful assignment of responsibilities is extremely important in object-oriented design Patterns are named problem/solution pairs that codify good advice and principles related to assignment of responsibilities GRASP identifies five patterns or principles: Creator, Information Expert, Controller, Low Coupling and High Cohesion 37
Assigning Responsibilities (Patterns of Responsibility Assignment Principles: GRASP)
Subsystem design basics Assigning Responsibilities (Patterns of Responsibility Assignment Principles: GRASP) Dept. of Computer Science Baylor University Focus on modeling how subsystems accomplish goals
More informationAssigning Responsibilities by Larman
Assigning Responsibilities by Larman Core design activity: The identification of objects and responsibilities and providing a solution in terms of an interaction diagram this is the creative part where
More informationObject Analysis & Design in the textbook. Introduction to GRASP: Assigning Responsibilities to Objects. Responsibility-Driven Design
Object Analysis & Design in the textbook Chapter 2 Object Oriented Design Process Introduction to GRASP: Assigning Responsibilities to Objects CS 4354 Summer II 2016 Jill Seaman Much of the material in
More information17. GRASP: Designing Objects with Responsibilities
17. GRASP: Designing Objects with Responsibilities Objectives Learn to apply five of the GRASP principles or patterns for OOD. Dr. Ziad Kobti School of Computer Science University of Windsor Understanding
More informationInformation Expert (or Expert)
Page 2 Page 3 Pattern or Principle? Information Expert (or Expert) Class Responsibility Sale Knows Sale total SalesLineItem Knows line item total ProductDescription Knows product price The GRASP patterns
More informationCOMP 6471 Software Design Methodologies
COMP 6471 Software Design Methodologies Fall 2011 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/comp6471-fall2011.html Page 2 Sample UP Artifact Relationships Domain Model Context Business Modeling
More informationResponsibilities. Using several specific design principles to guide OO design decisions.
Designing Objects with Responsibilities Using several specific design principles to guide OO design decisions. Challenge Old-school advice on OOD After identifying i your requirements and creating a domain
More informationLast Time: Object Design. Comp435 Object-Oriented Design. Last Time: Responsibilities. Last Time: Creator. Last Time: The 9 GRASP Patterns
Last Time: Object Design Comp435 Object-Oriented Design Week 7 Computer Science PSU HBG The main idea RDD: Responsibility-Driven Design Identify responsibilities Assign them to classes and objects Responsibilities
More informationReferences: Applying UML and patterns Craig Larman
References: Applying UML and patterns Craig Larman 1 2 What are patterns? Principles and solutions codified in a structured format describing a problem and a solution A named problem/solution pair that
More informationADVANCED SOFTWARE DESIGN LECTURE 7 GRASP
ADVANCED SOFTWARE DESIGN LECTURE 7 GRASP Dave Clarke 1 TODAY S LECTURE We will discuss 7 of the GRASP design patterns cohesion and coupling were covered earlier. These provide principles for evaluating
More informationPrinciples of Software Construction: Objects, Design, and Concurrency. Assigning Responsibilities to Objects. toad. Jonathan Aldrich Charlie Garrod
Principles of Software Construction: Objects, Design, and Concurrency Assigning Responsibilities to Objects toad Fall 2014 Jonathan Aldrich Charlie Garrod School of Computer Science Key concepts from Thursday
More informationOn to Object-oriented Design
Dr. Michael Eichberg Software Technology Group Department of Computer Science Technische Universität Darmstadt Introduction to Software Engineering On to Object-oriented Design Object-oriented Design 2
More informationADVANCED SOFTWARE DESIGN LECTURE 4 GRASP. Dave Clarke
ADVANCED SOFTWARE DESIGN LECTURE 4 GRASP Dave Clarke TODAY S LECTURE We will discuss and apply the GRASP design patterns. These provide principles for evaluating and improving designs. friends User Name??
More informationGRASP Design Patterns A.A. 2018/2019
GRASP Design Patterns A.A. 2018/2019 Objectives Introducing design patterns Introduzione ai design pattern Designing objects and responsibilities GRASP design patterns A long corridor A passage room Does
More informationGRASP ing at the First 5 Patterns Principles CSSE 574: Session 3, Part 4
GRASP ing at the First 5 Patterns Principles CSSE 574: Session 3, Part 4 Steve Chenoweth Phone: Office (812) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu GRASP General Responsibility Assignment
More informationConstantinos Constantinides Computer Science and Software Engineering Concordia University Montreal, Canada
1 Disclaimer: These slides are based on the 2 nd edition of Applying UML and Patterns; An introduction to OOAD and the Unified process by Craig Larman (2002). I take responsibility for any errors. Constantinos
More information2 GRASP Patterns and basic OO Design. Roel Wuyts OASS
2 GRASP Patterns and basic OO Design Roel Wuyts OASS1 2009-2010 Patterns 2 Bit of history... Christoffer Alexander The Timeless Way of Building, Christoffer Alexander, Oxford University Press, 1979, ISBN
More informationIntroduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of
Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of Computer Science Technische Universität Darmstadt Dr.
More informationPrinciples of Software Construction: Objects, Design and Concurrency. Object-Oriented Design: Assigning Responsibilities.
Principles of Software Construction: Objects, Design and Concurrency 15-214 toad Object-Oriented Design: Assigning Responsibilities Christian Kästner Charlie Garrod School of Computer Science With slides
More informationObject-Oriented Design
Object-Oriented Design Department of Computer Engineering Lecture 12: Object-Oriented Principles Sharif University of Technology 1 Open Closed Principle (OCP) Classes should be open for extension but closed
More informationPatterns and Testing
and Lecture # 7 Department of Computer Science and Technology University of Bedfordshire Written by David Goodwin, based on the lectures of Marc Conrad and Dayou Li and on the book Applying UML and (3
More informationObject-Oriented Design
Object-Oriented Design Lecturer: Raman Ramsin Lecture 15: Object-Oriented Principles 1 Open Closed Principle (OCP) Classes should be open for extension but closed for modification. OCP states that we should
More informationCSSE 374: GRASP ing at the First Five Patterns Principles. Shawn Bohner Office: Moench Room F212 Phone: (812)
CSSE 374: GRASP ing at the First Five Patterns Principles Shawn Bohner Office: Moench Room F22 Phone: (82) 877-8685 Email: bohner@rose-hulman.edu Learning Outcomes: Patterns, Tradeoffs Identify criteria
More informationIntroduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of
Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of Computer Science Technische Universität Darmstadt What
More informationTecniche di Progettazione: Design Patterns
Tecniche di Progettazione: Design Patterns Design principles 1 Plan of the lecture Your state of the art SOLID Grasp (to be continued next week) 2 Short summary of what you must know Few things on design
More informationCTIS 359 Principles of Software Engineering SOFTWARE DESIGN OO(A)D
CTIS 359 Principles of Software Engineering SOFTWARE DESIGN OO(A)D Today s Objectives To explain the basic concepts of OO(A)D To describe some best practices regarding to OO(A)D What is NOT UML? The UML
More informationSoftware Engineering
Software Engineering 5. Software Design und Design Prinzipien Jonathan Brachthäuser Software Engineering Einordnung Problem Continuous Delivery & Feedback Lösung Anforderungsermittlung - (Nicht- )funktionale
More informationVEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE UNIT 1 UML DIAGRAMS
UNIT 1 UML DIAGRAMS Introduction to OOAD Unified Process - UML diagrams Use Case Class Diagrams Interaction Diagrams State Diagrams Activity Diagrams Package, component and Deployment Diagrams. INTRODUCTION
More informationADVANCED SOFTWARE DESIGN LECTURE 4 SOFTWARE ARCHITECTURE
ADVANCED SOFTWARE DESIGN LECTURE 4 SOFTWARE ARCHITECTURE Dave Clarke 1 THIS LECTURE At the end of this lecture you will know notations for expressing software architecture the design principles of cohesion
More informationSoftware Modeling & Analysis
Software Modeling & Analysis OOPT (Object Oriented Process with Trace) Lecturer: JUNBEOM YOO jbyoo@konkuk.ac.kr What is OOPT? OOPT (Object Oriented Process with Trace) A software process based on RUP Revision
More informationCS6502- OBJECT ORIENTED ANALYSIS AND DESIGN UNIT I
CS6502- OBJECT ORIENTED ANALYSIS AND DESIGN UNIT I Introduction to OOAD Unified Process - UML diagrams Use Case Class Diagrams Interaction Diagrams State Diagrams Activity Diagrams Package, component and
More informationMapping Designs to Code
Mapping Designs to Code Creating Class Definitions from DCDs public class SalesLineItem private int quantity; private ProductDescription description ; public SalesLineItem(ProductDescription desc, int
More informationOO Design2. Design Artifacts
OO Design2 POS example - revisited LAR Ch 8 has entire POS design explained READ THIS CHAPTER and ASK Q s in class Design class diagrams Kinds of visibility of objects to one another Navigability of associations
More informationAssigning Responsibilities
Principles of Software Construction: Objects, Design, and Concurrency (Part 2: Designing (Sub-)Systems) Assigning Responsibilities Christian Kästner Bogdan Vasilescu School of Computer Science 1 2 2 Learning
More informationCSSE 374: Logical Architecture. Shawn Bohner Office: Moench Room F212 Phone: (812)
CSSE 374: Logical Architecture Shawn Bohner Office: Moench Room F212 Phone: (812) 877-8685 Email: bohner@rose-hulman.edu An Engineering Decision Learning Outcomes: O-O Design Demonstrate object-oriented
More informationGoal: build an object-oriented model of the realworld system (or imaginary world) Slicing the soup: OOA vs. OOD
Domain analysis Goal: build an object-oriented model of the realworld system (or imaginary world) Slicing the soup: OOA vs. OOD OOA concerned with what, not how OOA activities focus on the domain layer
More informationDEPARTMENT OF COMPUTER SCIENCE & ENGINEERING CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN. Unit-I. Introduction to OOAD
DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN 1. What is Object-Oriented Analysis? Unit-I Introduction to OOAD PART-A (UML Notations has to be used wherever necessary)
More informationPROCESSI DI PRODUZIONE E GESTIONE DEL SOFTWARE. Analysis and Design with UML. Paola Turci
PROCESSI DI PRODUZIONE E GESTIONE DEL SOFTWARE Analysis and Design with UML Paola Turci What is Visual Modelling? Modelling captures essential parts of the system. Dr. James Rumbaugh Order Item Ship via
More informationDomain Modeling. CSSE 574: Week 1, Part 3. Steve Chenoweth Phone: Office (812) Cell (937)
Domain Modeling CSSE 574: Week 1, Part 3 Steve Chenoweth Phone: Office (812) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu s g Where we re going Sample UP Artifact Relationships date...
More informationCS6502-OBJECT ORIENTED ANALYSIS AND DESIGN Two Marks Question with Answers Unit-I Introduction to OOAD
CS6502-OBJECT ORIENTED ANALYSIS AND DESIGN Two Marks Question with Answers Unit-I Introduction to OOAD 1. What is Object-Oriented Analysis? Nov/Dec 2016 During object-oriented analysis there is an emphasis
More information18.1 Definitions and General OO Principles
Chapter 18: Design Patterns Design patterns are elegant, adaptable, and reusable solutions to everyday software development problems. Each pattern includes a description of a commonly occuring type of
More informationAbstraction. Design fundamentals in OO Systems. Fundamental Software Development Principles
Abstraction Design fundamentals in OO Systems Tool for abstraction: object Object structure: properties and values for those properties operations to query and update those properties We refer to the collection
More informationRelationships amongst Objects
Relationships amongst Objects By Rick Mercer with help from Object-Oriented Design Heuristics Arthur Riel Addison-Wesley, 1996, ISBN 0-201-6338-X 8-1 Outline Consider six relationships between objects
More informationROEVER ENGINEERING COLLEGE DEPARTMENT OF INFORMATION TECHNOLOGY CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN. Unit-I. Introduction to OOAD
ROEVER ENGINEERING COLLEGE CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN 1. What is Object-Oriented Analysis? Unit-I Introduction to OOAD PART-A During object-oriented analysis there is an emphasis on finding
More informationLogical Architecture & Design Preliminaries
Logical Architecture & Design Preliminaries CSSE 574: Week 2, Part 4 Steve Chenoweth Phone: Office (812) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu From Requirements to Architecture Customer
More informationObject-Oriented Functional Analysis and Design for POS Example
Object-Oriented Functional Analysis and Design for POS Example Focus in Analysis, Design, Implementation Analysis Investigation to the problem in problem domain Design Logical solution(model) for implementation
More informationIdioms and Design Patterns. Martin Skogevall IDE, Mälardalen University
Idioms and Design Patterns Martin Skogevall IDE, Mälardalen University 2005-04-07 Acronyms Object Oriented Analysis and Design (OOAD) Object Oriented Programming (OOD Software Design Patterns (SDP) Gang
More informationFinal Exam. Final Exam Review. Ch 1: Introduction: Object-oriented analysis, design, implementation. Exam Format
Final Exam Final Exam Review CS 4354 Fall 2012 Jill Seaman Friday, December 14, 11AM Closed book, closed notes, clean desk Content: Textbook: Chapters 1, 2, 4-10 Java Lectures, GRASP + JUnit 35% of your
More informationObject Oriented Analysis and Design CS6502
UNIT I (9) Introduction to OOAD What is OOAD? What is UML? What are the United process(up) phases - Case study the NextGen POS system, Inception -Use case Modeling - Relating Use cases include, extend
More informationDesigning for Visibility & Mapping to Code CSSE 574: Session 4, Part 3
Designing for Visibility & Mapping to Code CSSE 574: Session 4, Part 3 Steve Chenoweth Phone: Office (812) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu Agenda Designing for Visibility Mapping
More informationFrom designing to coding
From designing to coding l st step: sensibly split work among team members Choose splits along thin interfaces l Probably not equal parts; split biggest parts again later Formalize the interfaces think
More informationDomain Modeling- 2. Generalization
Generalization Domain Modeling- 2 Conceptual superclasses and subclasses When to create a subclass? A superclass? Abstract classes Modeling state changes Operation contracts Attaching pre- /post-conditions
More informationDesign Pattern Detection
Design Pattern Detection Design Patterns A design pattern systematically names, explains and evaluates an important and recurring design problem and its solution Good designers know not to solve every
More informationUnderstading Refactorings
Understading Refactorings Ricardo Terra terra@dcc.ufmg.br Marco Túlio Valente mtov@dcc.ufmg.br UFMG, 2010 UFMG, 2010 Understanding Refactorings 1 / 36 Agenda 1 Overview 2 Refactoring 3 Final Considerations
More informationFrom Design Patterns: Elements of Reusable Object Oriented Software. Read the sections corresponding to patterns covered in the following slides.
From Design Patterns: Elements of Reusable Object Oriented Software Read the sections corresponding to patterns covered in the following slides. DESIGN PRINCIPLES Modularity Cohesion Coupling Separation
More informationOBJECT ORIENTED ANALYSIS AND DESIGN SYLLABUS
OBJECT ORIENTED ANALYSIS AND DESIGN SYLLABUS CS6502 - OBJECT ORIENTED ANALYSIS AND DESIGN L T P C 3 0 0 3 UNIT I- UML DIAGRAMS Introduction to OOAD Unified Process - UML diagrams Use Case Class Diagrams
More informationObject-Oriented Design and Modeling Using the UML
Design Classes Object-Oriented Design and Modeling Using the UML Based on Chapter 18 of Whitten, Bentley, and Dittman: Systems Analysis and Design for the Global Enterprise (7th Ed). McGraw Hill. 2007
More informationCOMP 6471 Software Design Methodologies
COMP 647 Software Design Methodologies Fall 20 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/comp647-fall20.html Course Introduction Course People Course Components What the course is What the
More informationPrinciples of Software Construction: Objects, Design, and Concurrency
Principles of Software Construction: Objects, Design, and Concurrency Designing (sub-) systems Responsibility assignment Charlie Garrod Michael Hilton School of Computer Science 1 Administrivia Reading
More informationChapter 3: Object Oriented Design
Chapter 3: Object Oriented Design Object Oriented Design The boundaries between analysis and design are fuzzy, although the focus of each is quite distinct. In analysis, the focus is to fully analyze the
More informationOn to Object-oriented Design
Dr. Michael Eichberg Software Engineering Department of Computer Science Technische Universität Darmstadt Software Engineering On to Object-oriented Design Object-oriented Design 2 A popular way of thinking
More informationSoftware Design Patterns. Background 1. Background 2. Jonathan I. Maletic, Ph.D.
Software Design Patterns Jonathan I. Maletic, Ph.D. Department of Computer Science Kent State University J. Maletic 1 Background 1 Search for recurring successful designs emergent designs from practice
More informationDesign Pattern Detection
Design Pattern Detection Design Patterns EECS 6431 Design Pattern Detection 2/22 A design pattern systematically names, explains and evaluates an important and recurring design problem and its solution
More informationTopics in Object-Oriented Design Patterns
Software design Topics in Object-Oriented Design Patterns Material mainly from the book Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides; slides originally by Spiros Mancoridis;
More informationUNIT 1-UMAL DIAGRAMS. Q.No. Question Competence Level. 1 What is Object Oriented analysis & Design? Remembering BTL1
Year & Semester : III & VI Section : CSE 1 & 2 Subject Code : CS6502 Subject Name : OBJECT ORIENTED ANALYSIS AND DESIGN Degree & Branch : B.E (CSE) Staff in charge : Dr.B.VANATHI & Mr.K.SHANMUGAM PART
More informationSoftware Design and Analysis CSCI 2040
Software Design and Analysis CSCI 2040 http://data.science.uoit.ca -> Home -> Teaching -> Software Design and Analysis Software Design and Analysis CSCI 4030 2 Describe the goals. Define object-oriented
More informationSystem Sequence Diagrams. Based on Craig Larman, Chapter 10 and Anuradha Dharani s notes
System Sequence Diagrams Based on Craig Larman, Chapter 10 and Anuradha Dharani s notes Dynamic behaviors Class diagrams represent static relationships. Why? What about modeling dynamic behavior? Interaction
More informationFinal Exam CISC 475/675 Fall 2004
True or False [2 pts each]: Final Exam CISC 475/675 Fall 2004 1. (True/False) All software development processes contain at least separate planning, testing, and documentation phases. 2. (True/False) The
More information4 Software models. often more than what people can handle not necessary to know all details at all times
4 Software models Software is complex often more than what people can handle not necessary to know all details at all times Models offer simplified view concentrate on the important issues and omit the
More informationAppendix A - Glossary(of OO software term s)
Appendix A - Glossary(of OO software term s) Abstract Class A class that does not supply an implementation for its entire interface, and so consequently, cannot be instantiated. ActiveX Microsoft s component
More informationObject-Oriented Design
Object-Oriented Design Lecture 14: Design Workflow Department of Computer Engineering Sharif University of Technology 1 UP iterations and workflow Workflows Requirements Analysis Phases Inception Elaboration
More informationChapter 5 Object-Oriented Programming
Chapter 5 Object-Oriented Programming Develop code that implements tight encapsulation, loose coupling, and high cohesion Develop code that demonstrates the use of polymorphism Develop code that declares
More informationCompositional Design Principles
Chapter 16 Compositional Design Principles Learning Objectives In this chapter, I will more formally introduce the three principles that form the 3-1- 2 process. The learning focus is understanding how
More informationWhat is a Model? Copyright hebley & Associates
Modeling Overview... as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there
More informationThink of drawing/diagramming editors. ECE450 Software Engineering II. The problem. The Composite pattern
Think of drawing/diagramming editors ECE450 Software Engineering II Drawing/diagramming editors let users build complex diagrams out of simple components The user can group components to form larger components......which
More informationWelcome to Design Patterns! For syllabus, course specifics, assignments, etc., please see Canvas
Welcome to Design Patterns! For syllabus, course specifics, assignments, etc., please see Canvas What is this class about? While this class is called Design Patterns, there are many other items of critical
More informationChapter 1: Programming Principles
Chapter 1: Programming Principles Object Oriented Analysis and Design Abstraction and information hiding Object oriented programming principles Unified Modeling Language Software life-cycle models Key
More informationbe used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate
UNIT 4 GRASP GRASP: Designing objects with responsibilities Creator Information expert Low Coupling Controller High Cohesion Designing for visibility - Applying GoF design patterns adapter, singleton,
More informationSKP Engineering College
SKP Engineering College Tiruvannamalai 606611 A Course Material on Object Oriented Analysis and Design By G.Nanda Kumar Assistant Professor Computer Science and Engineering Department Computer Science
More informationChapter 8: Class and Method Design
Chapter 8: Class and Method Design Objectives Become familiar with coupling, cohesion, and connascence. Be able to specify, restructure, and optimize object designs. Be able to identify the reuse of predefined
More informationVALLIAMMAI ENGINEERING COLLEGE
VALLIAMMAI ENGINEERING COLLEGE SRM Nagar, Kattankulathur 603 203 DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING QUESTION BANK V SEMESTER CS6502-OBJECT ORIENTED ANALYSIS AND DESIGN Regulation 2013 Academic
More informationOperations Contracts and Preliminaries on Design
Operations Contracts and Preliminaries on Design CSSE 574: Week 2, Part 3 Steve Chenoweth Phone: Office (812) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu We are at System Operation Contracts
More informationDesign Pattern What is a Design Pattern? Design Pattern Elements. Almas Ansari Page 1
What is a Design Pattern? Each pattern Describes a problem which occurs over and over again in our environment,and then describes the core of the problem Novelists, playwrights and other writers rarely
More informationDesign Engineering. Overview
Design Engineering Overview What is software design? How to do it? Principles, concepts, and practices High-level design Low-level design N. Meng, B. Ryder 2 1 Design Engineering The process of making
More informationCHAPTER 5 GENERAL OOP CONCEPTS
CHAPTER 5 GENERAL OOP CONCEPTS EVOLUTION OF SOFTWARE A PROGRAMMING LANGUAGE SHOULD SERVE 2 RELATED PURPOSES : 1. It should provide a vehicle for programmer to specify actions to be executed. 2. It should
More informationProduced by. Design Patterns. MSc in Communications Software. Eamonn de Leastar
Design Patterns MSc in Communications Software Produced by Eamonn de Leastar (edeleastar@wit.ie) Department of Computing, Maths & Physics Waterford Institute of Technology http://www.wit.ie http://elearning.wit.ie
More information6.3 Patterns. Definition: Design Patterns
Subject/Topic/Focus: Analysis and Design Patterns Summary: What is a pattern? Why patterns? 6.3 Patterns Creational, structural and behavioral patterns Examples: Abstract Factory, Composite, Chain of Responsibility
More informationCPSC 427a: Object-Oriented Programming
CPSC 427a: Object-Oriented Programming Michael J. Fischer Lecture 22a November 17, 2011 CPSC 427a, Lecture 22a 1/20 CPSC 427a, Lecture 22a 2/20 CPSC 427a, Lecture 22a 3/20 General OO principles 1. Encapsulation
More informationThe Software Design Process. CSCE 315 Programming Studio, Fall 2017 Tanzir Ahmed
The Software Design Process CSCE 315 Programming Studio, Fall 2017 Tanzir Ahmed Outline Challenges in Design Design Concepts Heuristics Practices Challenges in Design A problem that can only be defined
More informationChapter 1: Principles of Programming and Software Engineering
Chapter 1: Principles of Programming and Software Engineering Data Abstraction & Problem Solving with C++ Fifth Edition by Frank M. Carrano Software Engineering and Object-Oriented Design Coding without
More informationDesign Patterns. Gunnar Gotshalks A4-1
Design Patterns A4-1 On Design Patterns A design pattern systematically names, explains and evaluates an important and recurring design problem and its solution Good designers know not to solve every problem
More informationDesign Patterns. CSC207 Fall 2017
Design Patterns CSC207 Fall 2017 Design Patterns A design pattern is a general description of the solution to a well-established problem using an arrangement of classes and objects. Patterns describe the
More informationModellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico
Modellistica Medica Maria Grazia Pia INFN Genova Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico 2002-2003 Lezione 8 OO modeling Design Patterns Introduction Creational Patterns Software
More informationUsing Design Patterns in Education and Tutoring for the Software Systems Projects in Economic
Using Design Patterns in Education and Tutoring for the Software Systems Projects in Economic Cornelia NOVAC-UDUDEC cornelia.novac@ugal.ro Dunarea de Jos University of Galati Abstract. The paper deals
More informationDesign Patterns V Structural Design Patterns, 2
Structural Design Patterns, 2 COMP2110/2510 Software Design Software Design for SE September 17, 2008 Department of Computer Science The Australian National University 19.1 1 2 Formal 3 Formal 4 Formal
More informationObject Relationships
Object Relationships Objects can work together in three different types of relationships: Uses: An object can use another to do some work (association). Composition: A complex object may be composed of
More informationPlan. Design principles: laughing in the face of change. What kind of change? What are we trying to achieve?
Plan Design principles: laughing in the face of change Perdita Stevens School of Informatics University of Edinburgh What are we trying to achieve? Review: Design principles you know from Inf2C-SE Going
More informationSoftware Engineering
Software Engineering CSC 331/631 - Spring 2018 Object-Oriented Design Principles Paul Pauca April 10 Design Principles DP1. Identify aspects of the application that vary and separate them from what stays
More informationCS 2340 Objects and Design
CS 2340 Objects and Design Software Design Christopher Simpkins chris.simpkins@gatech.edu Chris Simpkins (Georgia Tech) CS 2340 Objects and Design Software Design 1 / 6 Design Design (noun) A plan or protocol
More informationIndex. Index. More information. block statements 66 y 107 Boolean 107 break 55, 68 built-in types 107
A abbreviations 17 abstract class 105 abstract data types 105 abstract method 105 abstract types 105 abstraction 92, 105 access level 37 package 114 private 115 protected 115 public 115 accessors 24, 105
More information