Object-Oriented Design
|
|
- Earl Ball
- 6 years ago
- Views:
Transcription
1 Object-Oriented Design Department of Computer Engineering Lecture 12: Object-Oriented Principles Sharif University of Technology 1
2 Open Closed Principle (OCP) Classes should be open for extension but closed for modification. OCP states that we should be able to add new features to our system without having to modify our set of preexisting classes. One of the tenets of OCP is to reduce the coupling between classes to the abstract level. Instead of creating relationships between two concrete classes, we create relationships between a concrete class and an abstract class or an interface. Sharif University of Technology 2
3 Open Closed Principle (OCP) Example Sharif University of Technology 3
4 Open Closed Principle (OCP) Solution Sharif University of Technology 4
5 Liskov Substitution Principle (LSP) Subclasses should be substitutable for their base classes. Also called the substitutability principle. Sharif University of Technology 5
6 Dependency Inversion Principle (DIP) Depend upon abstractions. Do not depend upon concretions. The Dependency Inversion Principle (DIP) formalizes the concept of abstract coupling and clearly states that we should couple at the abstract level, not at the concrete level. DIP tells us how we can adhere to OCP. Sharif University of Technology 6
7 Dependency Inversion Principle (DIP) Sharif University of Technology 7
8 Dependency Inversion Principle (DIP) let's assume the Manager class is quite complex, containing very complex logic. Now we have to change it in order to introduce the new SuperWorker Solution: Manager class doesn't require changes when adding SuperWorkers. Minimized risk to affect old functionality present in Manager class since we don't change it. No need to redo the unit testing for Manager class. Sharif University of Technology 8
9 Dependency Inversion Principle (DIP) Sharif University of Technology 9
10 Interface Segregation Principle (ISP) Many specific interfaces are better than a single, general interface. Any interface we define should be highly cohesive. Sharif University of Technology 10
11 Composite Reuse Principle (CRP) Favor polymorphic composition of objects over inheritance. One of the most catastrophic mistakes that contribute to the demise of an object-oriented system is to use inheritance as the primary reuse mechanism. Delegation can be a better alternative to Inheritance. Sharif University of Technology 11
12 Composite Reuse Principle (CRP) Delegation can be seen as a reuse mechanism at the object level, while inheritance is a reuse mechanism at the class level. suppose an Employee class has a method for computing the employee's annual bonus: class Employee { Money computebonus() { /* skimpy default bonus */ } // etc.} Different subclasses of Employee: Manager, Programmer, Secretary, etc. may want to override this method to reflect the fact that some types of employees (managers) get more generous bonuses than others (secretaries and programmers): class Manager extends Employee { Money computebonus() { /* gerenous bonus */ } // etc.} There are several problems with this solution. Sharif University of Technology 12
13 Composite Reuse Principle (CRP) All programmers get the same bonus. What if we wanted to vary the bonus computation among programmers? Would we need to introduce a special subclass of Programmer? class SeniorProgrammer extends Programmer { Money computebonus() { /* gerenous bonus */ } // etc.} Note also that this leads to code duplication. What if we wanted to change the bonus computation for a particular employee? For example, what if we wanted to promote Smith from programmer to senior programmer? Would this require us to recompile any code? What if we decided to give all programmers the same generous bonus that managers get? What changes would we need to make? Should "generous bonus" become the new default algorithm that is overridden in the Secretary class with the skimpy bonus algorithm? Should we copy and paste the "generous bonus" algorithm from manager to Programmer? Sharif University of Technology 13
14 Composite Reuse Principle (CRP) Now different employees can have different bonus calculators, regardless of the class they instantiate. Even better, the bonus calculator used by a particular employee can be changed dynamically. Sharif University of Technology 14
15 Principle of Least Knowledge (PLK) For an operation O on a class C, only operations on the following objects should be called: itself, its parameters, objects it creates, or its contained instance objects. Also called the Law of Demeter. The basic idea is to avoid calling any methods on an object where the reference to that object is obtained by calling a method on another object (Transitive Visibility). The primary benefit is that the calling method doesn t need to understand the structural makeup of the object its invoking methods upon. Sharif University of Technology 15
16 Principle of Least Knowledge (PLK) LoD (or Principle of Least Knowledge): Each module should have only limited knowledge about other units: only units "closely" related to the current unit In particular: Don t talk to strangers! For instance, no a.getb().getc().foo() Motivated by low coupling Sharif University of Technology 16
17 GRASP Acronym stands for General Responsibility Assignment Software Patterns. A set of 9 Patterns introduced as a learning aid by Craig Larman. Describe fundamental principles for object-oriented design and responsibility assignment, expressed as patterns. The skillful assignment of responsibilities is extremely important in object design. Determining the assignment of responsibilities often occurs during the creation of interaction diagrams, and certainly during programming. Sharif University of Technology 17
18 1. Information Expert 2.Creator 3. Low Coupling 4.High Cohesion 5. Controller 6.Polymorphism 7. Indirection 8.Pure Fabrication GRASP: Patterns 9.Protected Variations Sharif University of Technology 18
19 GRASP: Information Expert As a general principle of assigning responsibilities to objects, assign a responsibility to the information expert: i.e. the class that has the information necessary to fulfill the responsibility. Sharif University of Technology 19
20 GRASP: Information Expert Given an object o, which responsibilities can be assigned to o? Expert principle says assign those responsibilities to o for which o has the information to fulfill that responsibility. They have all the information needed to perform operations, or in some cases they collaborate with others to fulfill their responsibilities. Sharif University of Technology 20
21 GRASP: Example for Expert Assume we need to get all the videos of a VideoStore. Since VideoStore knows about all the videos, we can assign this responsibility of giving all the videos can be assigned to VideoStore class. VideoStore is the information expert. Sharif University of Technology 21
22 GRASP: Another Example for Expert Who should be responsible for knowing the grand total of a sale? Sharif University of Technology 22
23 GRASP: Creator 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 closely uses 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). B is a creator of A objects. If more than one option applies, prefer a class B which aggregates or contains class A. Sharif University of Technology 23
24 GRASP: Creator Container object creates contained objects. Decide who can be creator based on the objects association and their interaction. Consider VideoStore and Video in that store. VideoStore has an aggregation association with Video. i.e, VideoStore is the container and the Video is the contained object. So, we can instantiate video object in VideoStore class Sharif University of Technology 24
25 GRASP: Low Coupling Assign a responsibility so that coupling remains low. A class with high (or strong) coupling relies on many other classes. Such classes may be undesirable; some suffer from the following problems: Changes in related classes force local changes. Harder to understand in isolation. Harder to reuse because its use requires the additional presence of the classes on which it is dependent. Sharif University of Technology 25
26 GRASP: Low Coupling Two elements are coupled, if One element has aggregation/composition association with another element. One element implements/extends other element. Sharif University of Technology 26
27 GRASP: Low Coupling Sharif University of Technology 27
28 GRASP: High Cohesion Assign a responsibility so that cohesion remains high. A class with low cohesion does many unrelated things, or does too much work. Such classes are undesirable; they suffer from the following problems: hard to comprehend hard to reuse hard to maintain Delicate: constantly affected by change Sharif University of Technology 28
29 GRASP: High Cohesion Sharif University of Technology 29
30 GRASP: Controller 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 (a usecase- or session-controller). Use the same controller class for all system events in the same use case scenario. Informally, a session is an instance of a conversation with an actor. Note that "window," "applet," "widget," "view," and "document" classes are not on this list. Such classes should not fulfill the tasks associated with system events, they typically delegate these events to a controller. Sharif University of Technology 30
31 GRASP: Controller Deals with how to delegate the request from the UI layer objects to domain layer objects. This object is called controller object which receives request from UI layer object and then controls/coordinates with other object of the domain layer to fulfill the request. It delegates the work to other class and coordinates the overall activity Sharif University of Technology 31
32 GRASP: Polymorphism When related alternatives or behaviors vary by type (class), assign responsibility for the behavior using polymorphic operations to the types for which the behavior varies. Define the behavior in a common base class or, preferably, in an interface. Sharif University of Technology 32
33 GRASP: Indirection Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled. The intermediary creates an indirection between the other components. Beware of transitive visibility. Sharif University of Technology 33
34 GRASP: Indirection Here polymorphism illustrates indirection Class Employee provides a level of indirection to other units of the system. Sharif University of Technology 34
35 GRASP: Pure Fabrication Assign a 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. Example: a class that is solely responsible for saving objects in some kind of persistent storage medium, such as a relational database; call it the PersistentStorage. This class is a Pure Fabrication a figment of the imagination. Sharif University of Technology 35
36 GRASP: Pure Fabrication Fabricated class/ artificial class assign set of related responsibilities that doesn't represent any domain object. Provides a highly cohesive set of activities. Examples: Adapter, Strategy Benefits: High cohesion, low coupling and can reuse this class. Sharif University of Technology 36
37 GRASP: Pure Fabrication Suppose we Shape class, if we must store the shape data in a database. If we put this responsibility in Shape class, there will be many database related operations thus making Shape incohesive. So, create a fabricated class DBStore which is responsible to perform all database operations. Similarly loginterface which is responsible for logging information is also a good example for Pure Fabrication. Sharif University of Technology 37
38 GRASP: Protected Variations Identify points of predicted variation or instability; assign responsibilities to create a stable interface around them. Note: The term "interface" is used in the broadest sense of an access view; it does not literally only mean something like a Java or COM interface. Sharif University of Technology 38
39 Design by Contract (DBC) A discipline of analysis, design, implementation, and management. Bertrand Meyer introduced Design by Contract in Eiffel as a powerful technique for producing reliable software. Its key elements are assertions: boolean expressions that define correct program states at arbitrary locations in the code. Sharif University of Technology 39
40 Design by Contract (DBC): Assertions Simple assertions belong to individual statements in a program, yet important DBC assertions are defined on classes: Per- method assertions: Precondition: A condition that must be true of the parameters of a method and/or data members if the method is to behave correctly PRIOR to running the code in the method. Postcondition: A condition that is true AFTER running the code in a method. Per-class assertions: Class Invariant: A condition that is true BEFORE and AFTER running the code in a method (except constructors and destructors). Sharif University of Technology 40
41 Design by Contract (DBC): Contract Assertions in a class specify a contract between its instances and their clients. According to the contract a server promises to return results satisfying the postconditions if a client requests available services and provides input data satisfying the preconditions. Invariants must be satisfied before and after each service. Neither party to the contract (the clients/consumers and servers/suppliers) shall be allowed to rely on something else than that which is explicitly stated in the contract. Sharif University of Technology 41
42 Design by Contract (DBC): Inheritance The class invariants of all ancestors must also be obeyed by all children; they can also be strengthened. Inherited preconditions may only be weakened. This means a new implementation may never restrict the circumstances under which a client call is valid beyond what has been specified by the ancestor. It may, however, relax the rules and also accept calls that would have been rejected by the ancestor. Inherited postconditions may only be strengthened. This means a new implementation must fulfil what the ancestors have undertaken to do, but may deliver more. "Children should not provide less or expect more than their ancestors." Sharif University of Technology 42
43 Reference Larman, C., Applying UML and Patterns: An Introduction to Object- Oriented Analysis and Design and Iterative Development, 3 rd Ed. Prentice-Hall, Sharif University of Technology 43
Object-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 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 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 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 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 informationObject-Oriented Design II - GRASP
Object-Oriented Design II - GRASP SWEN-610 Foundations of Software Engineering Department of Software Engineering Rochester Institute of Technology Controller Creator Indirection Information expert High
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 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 informationGRASP: Patterns for. chapter18
GRASP: Patterns for assigning responsibility chapter18 1 Chapter Objectives Learn about design patterns Learn how to apply five GRASP patterns 2 Building Collaboration diagrams System Design: how the system
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 informationObject-Oriented Design I
Object-Oriented Design I SWEN-261 Introduction to Software Engineering Department of Software Engineering Rochester Institute of Technology Single responsibility High cohesion Information expert Low coupling
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 informationSummary of the course lectures
Summary of the course lectures 1 Components and Interfaces Components: Compile-time: Packages, Classes, Methods, Run-time: Objects, Invocations, Interfaces: What the client needs to know: Syntactic and
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 informationEliminate enterprise software design instability - protect variations! Nickolay Kofanov
Eliminate enterprise software design instability - protect variations! Nickolay Kofanov Owning a hammer doesn't make one an architect. Responsibility-Driven-Design The way of thinking about the design
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 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 informationAssigning 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 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 informationGRASP 2. CSC 440: Software Engineering Slide #1
GRASP 2 CSC 440: Software Engineering Slide #1 GRASP Patterns General Responsibility Assignment Software Patterns Describe fundamental principles of object design and responsibility assignment. Five GRASP
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 informationFour More GRASP Principles CSSE 574: Session 5, Part 2
Four More GRASP Principles CSSE 574: Session 5, Part 2 Steve Chenoweth Phone: Office (812) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu GRASP II And Furthermore Polymorphism Indirection
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 information2009 Shawn A. Bohner. Shawn Bohner Office: Moench Room F212 Phone: (812)
2009 Shawn A. Bohner Shawn Bohner Office: Moench Room F212 Phone: (812) 877-8685 Email: bohner@rose-hulman.edu GRASP II And Furthermore Polymorphism Indirection Pure Fabrication Protected Variations 2
More informationCHAPTER 5: PRINCIPLES OF DETAILED DESIGN
CHAPTER 5: PRINCIPLES OF DETAILED DESIGN SESSION II: STRUCTURAL AND BEHAVIORAL DESIGN OF COMPONENTS Software Engineering Design: Theory and Practice by Carlos E. Otero Slides copyright 2012 by Carlos E.
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 informationSOLID Principles. Equuleus Technologies. Optional Subheading October 19, 2016
SOLID Principles Optional Subheading October 19, 2016 Why SOLID Principles? The traits of well designed software are as follows Maintainability - The ease with which a software system or component can
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 informationObject-Oriented Design I - SOLID
Object-Oriented Design I - SOLID SWEN-261 Introduction to Software Engineering Department of Software Engineering Rochester Institute of Technology Single responsibility Open/close Liskov substitution
More informationOODP OOAD Session 7a
OODP OOAD Session 7a Session times PT group 1 Monday 18:00 21:00 room: Malet 403 PT group 2 Thursday 18:00 21:00 room: Malet 407 FT Tuesday 13:30 17:00 room: Malet 404 Email: oded@dcs.bbk.ac.uk Web Page:
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 informationCOURSE 2 DESIGN PATTERNS
COURSE 2 DESIGN PATTERNS CONTENT Fundamental principles of OOP Encapsulation Inheritance Abstractisation Polymorphism [Exception Handling] Fundamental Patterns Inheritance Delegation Interface Abstract
More informationLearning Objectives. C++ For Artists 2003 Rick Miller All Rights Reserved xli
Identify and overcome the difficulties encountered by students when learning how to program List and explain the software development roles played by students List and explain the phases of the tight spiral
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 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 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 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 informationSoftware Engineering CSC40232: SOFTWARE ENGINEERING. Guest Lecturer: Jin Guo SOLID Principles sarec.nd.edu/courses/se2017
CSC40232: SOFTWARE ENGINEERING Guest Lecturer: Jin Guo SOLID Principles sarec.nd.edu/courses/se2017 Department of Computer Science and Engineering http://www.kirkk.com/modularity/2009/12/solid-principles-of-class-design/
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 informationOODP Session 5a. Web Page: Visiting Hours: Tuesday 17:00 to 19:00
OODP Session 5a Next week: Reading week Session times PT group 1 Monday 18:00 21:00 room: Malet 403 PT group 2 Thursday 18:00 21:00 room: Malet 407 FT Tuesday 13:30 17:00 room: Malet 404 Email: oded@dcs.bbk.ac.uk
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 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 informationPROCESS DEVELOPMENT METHODOLOGY The development process of an API fits the most fundamental iterative code development
INTRODUCING API DESIGN PRINCIPLES IN CS2 Jaime Niño Computer Science, University of New Orleans New Orleans, LA 70148 504-280-7362 jaime@cs.uno.edu ABSTRACT CS2 provides a great opportunity to teach an
More informationGRASP: MORE PATTERNS FOR
Chapter 22 GRASP: MORE PATTERNS FOR ASSIGNING RESPONSIBILITIES Luck is the residue of design. Branch Rickey Objectives Learn to apply the remaining GRASP patterns. Introduction Previously, we explored
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 informationAssertions. Assertions - Example
References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 11/13/2003 1 Assertions Statements about input to a routine or state of a class Have two primary roles As documentation,
More information17.11 Bean Rules persistent
17.10 Java Beans Java beans are a framework for creating components in Java. AWT and Swing packages are built within this framework Made to fit in with graphic development environments such as Jbuilder
More informationDesign patterns. Jef De Smedt Beta VZW
Design patterns Jef De Smedt Beta VZW Who Beta VZW www.betavzw.org Association founded in 1993 Computer training for the unemployed Computer training for employees (Cevora/Cefora) 9:00-12:30 13:00-16:00
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 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 informationa correct statement? You need to know what the statement is supposed to do.
Using assertions for correctness How can we know that software is correct? It is only correct if it does what it is supposed to do. But how do we know what it is supposed to do? We need a specification.
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 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 informationOO Design Principles
OO Design Principles Software Architecture VO (706.706) Roman Kern Institute for Interactive Systems and Data Science, TU Graz 2018-10-10 Roman Kern (ISDS, TU Graz) OO Design Principles 2018-10-10 1 /
More informationPrinciples of Object-Oriented Design
Principles of Object-Oriented Design 1 The Object-Oriented... Hype What are object-oriented (OO) methods? OO methods provide a set of techniques for analysing, decomposing, and modularising software system
More informationObject-Oriented Concepts and Design Principles
Object-Oriented Concepts and Design Principles Signature Specifying an object operation or method involves declaring its name, the objects it takes as parameters and its return value. Known as an operation
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 informationAgile Software Development
Agile Software Development Principles, Patterns, and Practices Robert Cecil Martin Alan Apt Series Prentice Hall Pearson Education, Inc. Upper Saddle River, New Jersey 07458 Foreword Preface About the
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 informationCMPS 115 Winter 04. Class #10 (2004/02/05) Changes/Review Programming Paradigms Principles of OOD <break> Design Patterns
CMPS 115 Winter 04 Class #10 (2004/02/05) Changes/Review Programming Paradigms Principles of OOD Design Patterns Changes & Lecture 9 Takeaway Changes/Notices 2/26 may be guest after all, on design-with-frameworks
More informationBCS Higher Education Qualifications. Diploma in IT. Object Oriented Programming Syllabus
BCS Higher Education Qualifications Diploma in IT Object Oriented Programming Syllabus Version 3.0 December 2016 This is a United Kingdom government regulated qualification which is administered and approved
More informationMSO Lecture Design by Contract"
1 MSO Lecture Design by Contract" Wouter Swierstra (adapted by HP, AL) October 8, 2018 2 MSO SO FAR Recap Abstract Classes UP & Requirements Analysis & UML OO & GRASP principles Design Patterns (Facade,
More informationLecture 17: Patterns Potpourri. Copyright W. Howden 1
Lecture 17: Patterns Potpourri Copyright W. Howden 1 GOF Patterns GOF: Gamma, Helm, Johnson, Vlissides Design Patterns, Addison Wesley, 1995 Patterns we have seen so far Creational Patterns e.g. Factory,
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 information09. Component-Level Design
09. Component-Level Design Division of Computer Science, College of Computing Hanyang University ERICA Campus 1 st Semester 2017 What is Component OMG UML Specification defines a component as OO view a
More informationThe following topics will be covered in this course (not necessarily in this order).
The following topics will be covered in this course (not necessarily in this order). Introduction The course focuses on systematic design of larger object-oriented programs. We will introduce the appropriate
More informationCSE 70 Final Exam Fall 2009
Signature cs70f Name Student ID CSE 70 Final Exam Fall 2009 Page 1 (10 points) Page 2 (16 points) Page 3 (22 points) Page 4 (13 points) Page 5 (15 points) Page 6 (20 points) Page 7 (9 points) Page 8 (15
More informationEINDHOVEN UNIVERSITY OF TECHNOLOGY
EINDHOVEN UNIVERSITY OF TECHNOLOGY Department of Mathematics & Computer Science Exam Programming Methods, 2IP15, Wednesday 17 April 2013, 09:00 12:00 TU/e THIS IS THE EXAMINER S COPY WITH (POSSIBLY INCOMPLETE)
More informationRequirements and Design Overview
Requirements and Design Overview Robert B. France Colorado State University Robert B. France O-1 Why do we model? Enhance understanding and communication Provide structure for problem solving Furnish abstractions
More informationAvancier Methods. Very basic design patterns. It is illegal to copy, share or show this document
Methods Very basic design patterns It is illegal to copy, share or show this document (or other document published at http://avancier.co.uk) without the written permission of the copyright holder Copyright
More informationReferences: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1
References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1 Assertions Statements about input to a routine or state of a class Have two primary roles As documentation,
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 informationCSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich
CSCD01 Engineering Large Software Systems Design Patterns Joe Bettridge Winter 2018 With thanks to Anya Tafliovich Design Patterns Design patterns take the problems consistently found in software, and
More informationOO Class Design Principles
3.3 Class Design Principles Single Responsibility Principle (SRP) Open/Closed Principle (OCP) Liskov Substitution Principle (LSP) a.k.a. Design by Contract Dependency Inversion Principle (DIP) Interface
More informationCS342: Software Design. November 21, 2017
CS342: Software Design November 21, 2017 Runnable interface: create threading object Thread is a flow of control within a program Thread vs. process All execution in Java is associated with a Thread object.
More informationDesign Pattern- Creational pattern 2015
Creational Patterns Abstracts instantiation process Makes system independent of how its objects are created composed represented Encapsulates knowledge about which concrete classes the system uses Hides
More informationDesign Principles: Part 2
Liskov Substitution Principle (LSP) Dependency-Inversion Principle (DIP) Interface-Segregation Principle (ISP) Design Principles: Part 2 ENGI 5895: Software Design Andrew Vardy Faculty of Engineering &
More informationOutline. Design Principles: Part 2. e.g. Rectangles and Squares. The Liskov Substitution Principle (LSP) ENGI 5895: Software Design.
Liskov Substitution Principle (LSP) Dependency-Inversion Principle (DIP) Interface-Segregation Principle (ISP) Liskov Substitution Principle (LSP) Dependency-Inversion Principle (DIP) Interface-Segregation
More informationSoftware Design and Analysis CSCI 2040
Software Design and Analysis CSCI 2040 Summarize UML Deployment and Component notation. Design a framework with the Template Method, State, and Command patterns. Introduce issues in object-relational (O-R)
More informationToday's Agenda. References. Open Closed Principle. CS 247: Software Engineering Principles. Object-Oriented Design Principles
CS 247: Software Engineering Principles Reading: none Object-Oriented Design Principles Today's Agenda Object-Oriented Design Principles - characteristics, properties, and advice for making decisions that
More informationObject Oriented. Analysis and Design
OODP- OOAD Session 5 Object Oriented Analysis and Design Oded Lachish Department of Computer Science and Information Systems Birkbeck College, University of London Email: oded@dcs.bbk.ac.uk Web Page: http://www.dcs.bbk.ac.uk/~oded
More informationObject- Oriented Design with UML and Java Part I: Fundamentals
Object- Oriented Design with UML and Java Part I: Fundamentals University of Colorado 1999-2002 CSCI-4448 - Object-Oriented Programming and Design These notes as free PDF files: http://www.softwarefederation.com/cs4448.html
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 informationReview Software Engineering October, 7, Adrian Iftene
Review Software Engineering October, 7, 2013 Adrian Iftene adiftene@info.uaic.ro Software engineering Basics Definition Development models Development activities Requirement analysis Modeling (UML Diagrams)
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 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 informationDesign Principles: Part 2
Liskov Substitution Principle (LSP) Dependency-Inversion Principle (DIP) Interface-Segregation Principle (ISP) Design Principles: Part 2 ENGI 5895: Software Design Andrew Vardy Faculty of Engineering &
More informationObject-Oriented Design II
Object-Oriented Design II SWEN-261 Introduction to Software Engineering Department of Software Engineering Rochester Institute of Technology Controller Pure fabrication Open/close Polymorphism Liskov substitution
More informationC++ Modern and Lucid C++ for Professional Programmers
Informatik C++ Modern and Lucid C++ for Professional Programmers part 13 Prof. Peter Sommerlad Institutsleiter IFS Institute for Software Rapperswil, HS 2015 Inheritance and dynamic Polymorphism base classes,
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 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 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 informationInheritance. One class inherits from another if it describes a specialized subset of objects Terminology:
Inheritance 1 Inheritance One class inherits from another if it describes a specialized subset of objects Terminology: the class that inherits is called a child class or subclass the class that is inherited
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 informationDesign by Contract in Eiffel
Design by Contract in Eiffel 2002/04/15 ctchen@canthink.com.com.tw.tw Reference & Resource Bertrand Meyer, Object-Oriented Oriented Software Construction 2nd,, 1997, PH. Bertrand Meyer, Eiffel: The Language,,
More informationWhy Design by Contract! CS 619 Introduction to OO Design and Development. Design by Contract. Fall 2012
Why Design by Contract What s the difference with Testing? CS 619 Introduction to OO Design and Development Design by Contract Fall 2012 Testing tries to diagnose (and cure) defects after the facts. Design
More informationLecture: Modular Design
Software Engineering Lecture: Modular Design Thomas Fritz Many thanks to Philippe Beaudoin, Gail Murphy, David Shepherd, Neil Ernst and Meghan Allen Reading! For next lecture: (all required) Composite
More informationInfluence of Design Patterns Application on Quality of IT Solutions
Influence of Design Patterns Application on Quality of IT Solutions NADINA ZAIMOVIC, DZENANA DONKO Department for Computer Science and Informatics Faculty of Electrical Engineering, University of Sarajevo
More informationApplying Design Patterns to accelerate development of reusable, configurable and portable UVCs. Accellera Systems Initiative 1
Applying Design Patterns to accelerate development of reusable, configurable and portable UVCs. Accellera Systems Initiative 1 About the presenter Paul Kaunds Paul Kaunds is a Verification Consultant at
More informationDesign Patterns #3. Reid Holmes. Material and some slide content from: - GoF Design Patterns Book - Head First Design Patterns
Material and some slide content from: - GoF Design Patterns Book - Head First Design Patterns Design Patterns #3 Reid Holmes Lecture 16 - Thursday November 15 2011. GoF design patterns $ %!!!! $ "! # &
More information