Criteria for good design. aim to appreciate the proper and improper uses of inheritance and appreciate the concepts of coupling and cohesion.

Slides:



Advertisements
Similar presentations
Understand and appreciate Object Oriented Programming (OOP) Objects are self-contained modules or subroutines that contain data as well as the functions.
Advertisements

Chapter 11 Component-Level Design
Lecture 9 Improving Software Design CSC301-Winter 2011 – University of Toronto – Department of Computer Science Hesam C. Esfahani
Solutions to Review Questions. 4.1 Define object, class and instance. The UML Glossary gives these definitions: Object: an instance of a class. Class:
Inheritance Inheritance Reserved word protected Reserved word super
Classes and Object- Oriented... tMyn1 Classes and Object-Oriented Programming The essence of object-oriented programming is that you write programs in.
ITEC200 – Week03 Inheritance and Class Hierarchies.
UHD::CS3320::CHAP61 INTRODUCTION TO OBJECTS Chapter 6.
1 Software Testing and Quality Assurance Lecture 12 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)
1 Inheritance Reserved word protected Reserved word super Overriding methods Class Hierarchies Reading for this lecture: L&L 8.1 – 8.5.
Inheritance and Class Hierarchies Chapter 3. Chapter 3: Inheritance and Class Hierarchies2 Chapter Objectives To understand inheritance and how it facilitates.
Copyright W. Howden1 Lecture 6: Design Evaluation and Intro to OO Design Patterns.
Module: Definition ● A logical collection of related program entities ● Not necessarily a physical concept, e.g., file, function, class, package ● Often.
1 SOFTWARE DESIGN QUALITY COHESION and COUPLING (Part I)
Jump to first page 1 System Design (Finalizing Design Specifications) Chapter 3d.
7M701 1 Class Diagram advanced concepts. 7M701 2 Characteristics of Object Oriented Design (OOD) objectData and operations (functions) are combined 
PowerPoint Presentation for Dennis, Wixom & Tegarden Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved. Slide 1.
Criteria for good design. aim to appreciate the proper and improper uses of inheritance and appreciate the concepts of coupling and cohesion.
PVK-Ht051 Contents Introduction Requirements Engineering Project Management Software Design Detailed Design and Coding Quality Assurance Maintenance.
Developed by Reneta Barneva, SUNY Fredonia Component Level Design.
Modelling classes Drawing a Class Diagram. Class diagram First pick the classes –Choose relevant nouns, which have attributes and operations. Find the.
Systems Design. Analysis involves understanding and documenting user requirements in a clear and unambiguous way. It focuses on the business side and.
C++ fundamentals.
Chapter 9: Coupling & Cohesion Omar Meqdadi SE 273 Lecture 9 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Objects and Components. The adaptive organization The competitive environment of businesses continuously changing, and the pace of that change is increasing.
Coupling and Cohesion Pfleeger, S., Software Engineering Theory and Practice. Prentice Hall, 2001.
Coupling and Cohesion Source:
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
Class Design III: Advanced Inheritance Additional References “Object-Oriented Software Development Using Java”, Xiaoping Jia, Addison Wesley, 2002 “Core.
Cohesion and Coupling CS 4311
© 2005 Prentice Hall9-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
CS212: Object Oriented Analysis and Design Lecture 13: Relationship between Classes.
Coupling Cohesion Chandan R. Rupakheti Steve Chenoweth (Chapter 18)
Object Oriented Software Development
Relationships Relationships between objects and between classes.
Learners Support Publications Object Oriented Programming.
CSC 131 Fall 2006 Lecture # 6 Object-Oriented Concepts.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 11a: Component-Level Design Software Engineering: A Practitioner’s Approach, 6/e Chapter.
Testing OO software. State Based Testing State machine: implementation-independent specification (model) of the dynamic behaviour of the system State:
Introduction to Object-Oriented Programming Lesson 2.
Coming up: Inheritance
Evaluating an Object-Oriented Design ©SoftMoore ConsultingSlide 1.
CHAPTER 3 MODELING COMPONENT-LEVEL DESIGN.
Inheritance and Class Hierarchies Chapter 3. Chapter 3: Inheritance and Class Hierarchies2 Chapter Objectives To understand inheritance and how it facilitates.
Inheritance and Class Hierarchies Chapter 3. Chapter Objectives  To understand inheritance and how it facilitates code reuse  To understand how Java.
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 5th Edition Copyright © 2015 John Wiley & Sons, Inc. All rights.
Class Diagrams Revisited. Parameterized Classes Parameterized Classes - are used to represent relationships between templates.
Chapter 9: Coupling & Cohesion Omar Meqdadi SE 273 Lecture 9 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
 Description of Inheritance  Base Class Object  Subclass, Subtype, and Substitutability  Forms of Inheritance  Modifiers and Inheritance  The Benefits.
SOFTWARE DESIGN & SOFTWARE ENGINEERING Software design is a process in which data, program structure, interface and their details are represented by well.
Coupling and Cohesion Schach, S, R. Object-Oriented and Classical Software Engineering. McGraw-Hill, 2002.
Coupling and Cohesion Pfleeger, S., Software Engineering Theory and Practice. Prentice Hall, 2001.
Java Programming: Guided Learning with Early Objects Chapter 9 Inheritance and Polymorphism.
7. Modular and structured design
Sections Inheritance and Abstract Classes
Coupling and Cohesion Rajni Bhalla.
Object-Oriented Modeling
Coupling and Cohesion 1.
Chapter 11 Object-Oriented Design
Types of Programming Languages
TIM 58 Chapter 8: Class and Method Design
Class and Method Design
Cohesion and Coupling Chapter 5, Pfleeger 01/01/10.
Component-Level Design
Improving the Design “Can the design be better?”
Object-Oriented Design
Chapter 20 Object-Oriented Analysis and Design
Software Design Lecture : 9.
Software Design Lecture : 10
Cohesion and Coupling.
Presentation transcript:

Criteria for good design

aim to appreciate the proper and improper uses of inheritance and appreciate the concepts of coupling and cohesion

Advanced Generalisation and Inheritance Modelling Generalisation (specialisation) and inheritance are not the same – generalisation is a semantic relationship between classes – the interface of the subclass must include all properties of the superclass Inheritance – the mechanism by which more specific elements incorporate structure and behaviour defined by more general elements Generalisation is a useful and powerful concept but can also create many problems due to the intricate mechanisms of inheritance

Generalisation and Substitutability Generalisation introduces additional classes and categorises them into generic and more specific classes – establishes superclass-subclass relationships into the model The benefits of generalisation arise from the substitutability principle – a subclass object can be used in place of a superclass object in any part of the code where the superclass object is accessed – this means it can reduce the overall number of association and aggregation relationships in the model – unfortunately, inheritance may be used in a way that defeats the benefits of the substitutability principle

The Substitution Principle Defined by Barbara Liskov, so known as the Liskov Substitution Principle (LSP) – it should be possible to treat a derived object as if it were a base object

Inheritance v. Encapsulation Encapsulation – an object's state should only be accessible via the operations in the object's interface Inheritance may compromise encapsulation – subclasses may be allowed to access protected attributes directly – objects belonging to different classes may be friends of each other or have elements with package visibility Applications should be designed so that they balance the desired level of encapsulation against inheritance

Interface Inheritance v. Implementation Inheritance Interface inheritance – when generalisation is used with the aim of substitutability, it can be realised using interface inheritance (subtyping, or type inheritance)  this is both a “harmless” as well as a very desirable form of inheritance  a subclass inherits attribute types and operation signatures  the implementation of inherited operations may be deferred – there is a difference between an interface class and an abstract class  interface classes defer the definition of operations – these are defined or implemented by another class  abstract classes can provide a partial implementation of some operations

Interface Inheritance v. Implementation Inheritance Implementation inheritance – when generalisation is used to imply code reuse it is realised using implementation inheritance – implementation inheritance combines the superclass properties in the subclasses and allows them to be overridden with new implementations when necessary -- overriding can mean the inclusion (or call) of a superclass method in the subclass method -- overriding can also mean a complete replacement of the superclass method by the subclass method Implementation inheritance can be harmful if it is not carefully controlled

Extension Inheritance The only proper use of inheritance is as an incremental definition of a class – a subclass has more properties than its superclass – a subclass is a kind of superclass This type of inheritance is known as extension inheritance In extension inheritance, the overriding of properties should be used with care – it should be used to make properties more specific, and not to change the meaning of the property

Extension Inheritance

Restriction Inheritance It is possible to use inheritance as a restriction mechanism whereby some of the inherited properties are suppressed or overridden in the subclass – this type of inheritance is known as restriction inheritance Restriction inheritance is problematic – a subclass does not include all the properties of the superclass but a superclass object can still be substituted by a subclass object -- whoever is using the object should be aware of the overridden properties Restriction inheritance may give rise to maintenance problems

Restriction Inheritence

Convenience Inheritance

The Evils of Implementation Inheritance

Aggregation as an Alternative to Generalisation

Delegation

Generalisation V Aggregation

Coupling and Cohesion

Example of Poor Coupling

Example of Poor Cohesion

Criteria for Good Design - Coupling Coupling – a good design will minimise coupling – describes the degree of interconnectedness between design components – is reflected by the number of links an object has and by the degree of interaction the object has with other objects Interaction coupling – a measure of the number of message types an objects sends and the number of parameters passed with these message types Inheritance coupling – the degree to which a subclass needs the features it inherits from its base class

Types of Interaction Coupling(1) No Direct Coupling –The methods do not relate to one another, that is, they do not call one another Data –The calling method passes a variable to the called method. If the variable is a composite, (i.e., an object), the entire object is used by the called method to perform its function. Stamp –The calling method passes a composite variable (i.e., an object) to the called method, but the called method only used a portion of the object to perform its function. Control –The calling method passes a control variable whose value will control the execution of the called method.

Types of Interaction Coupling(2) Common or Global –The methods refer to a “global data area” that is outside the individual objects. Content or Pathological –A method of one object refers to the inside (hidden part) of another object. This violates the principles of encapsulation and information hiding. good levelNo direct coupling bad levelcontent coupling

Inheritance Coupling - example Low inheritance

Criteria for Good Design - Cohesion

Types of Operation Cohesion (1) Functional –A method perform a single problem-related task (e.g., Calculate current GPA) Sequential –The method combines two functions in which the output from the first one is used as the input to the second one (e.g., format and validate current GPA) Communicational –The method combines two functions that use the same attributes to execute (e.g., calculate current and cumulative GPA) Procedural –The method supports multiple weakly related functions. (e.g., calculate student GPA, print student record, calculate cumulative GPA, and print cumulative GPA)

Types of Operation Cohesion (2) Temporal –A method support multiple related functions in time (e.g., initialize all attributes) Logical –The method support multiple related functions, but the choice of the specific function is chosen based on a control variable that is passed into the method (e.g., called method could open a checking account, open a saving account, or calculate a loan, depending on the message that is send by its calling method) Coincidental –The purpose of the method cannot be defined or it performs multiple functions that are unrelated to one another. (e.g., update customer records, calculate loan payments, print exception reports, and analyze competitor pricing structure) GoodBad FunctionalCoincidental

Class Cohesion - example

Specialisation Cohesion - example

Summary