Software Design Principles 7th February, 2007

Slides:



Advertisements
Similar presentations
Testing Relational Database
Advertisements

Lecture 6: Software Design (Part I)
ARCHITECTURES FOR ARTIFICIAL INTELLIGENCE SYSTEMS
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Quality of a Class Abstraction: Coupling & Cohesion Michael L. Collard, Ph.D. Department of Computer Science Kent State University.
COMPSCI 105 S Principles of Computer Science 12 Abstract Data Type.
1 Software Design Introduction  The chapter will address the following questions:  How do you factor a program into manageable program modules that can.
What is Software Design?  Introduction  Software design consists of two components, modular design and packaging.  Modular design is the decomposition.
Copyright Irwin/McGraw-Hill Software Design Prepared by Kevin C. Dittman for Systems Analysis & Design Methods 4ed by J. L. Whitten & L. D. Bentley.
Module: Definition ● A logical collection of related program entities ● Not necessarily a physical concept, e.g., file, function, class, package ● Often.
Design The goal is to design a modular solution, using the techniques of: Decomposition Abstraction Encapsulation In Object Oriented Programming this is.
Jump to first page 1 System Design (Finalizing Design Specifications) Chapter 3d.
Introduction to Systems CSCI102 - Systems ITCS905 - Systems MCS Systems.
Introduction to Databases Transparencies
PVK-Ht051 Contents Introduction Requirements Engineering Project Management Software Design Detailed Design and Coding Quality Assurance Maintenance.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Software Issues Derived from Dr. Fawcett’s Slides Phil Pratt-Szeliga Fall 2009.
Systems Design. Analysis involves understanding and documenting user requirements in a clear and unambiguous way. It focuses on the business side and.
Computer Science 240 Principles of Software Design.
Chapter 7 Software Engineering Objectives Understand the software life cycle. Describe the development process models.. Understand the concept of modularity.
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
Chapter 9: Coupling & Cohesion Omar Meqdadi SE 273 Lecture 9 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Chapter 5CSA 217 Design in Construction Chapter 5 1.
1/19 Component Design On-demand Learning Series Software Engineering of Web Application - Principles of Good Component Design Hunan University, Software.
An Introduction to Software Architecture
Software Design Fundamentals Design Principles
CSE 303 – Software Design and Architecture
Coupling and Cohesion Pfleeger, S., Software Engineering Theory and Practice. Prentice Hall, 2001.
Design (1) Design involves decisions on how to deliver the agreed functionality to the users. Design involves development of a clear, unambiguous and consistent.
Program Design Simple Program Design Third Edition A Step-by-Step Approach 9.
Computer Science 240 © Ken Rodham 2006 Principles of Software Design.
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
SOFTWARE DESIGN.
SOFTWARE DESIGN Design Concepts Design is a meaningful engineering representation of something that is to be built It can be traced to a customer’s requirements.
SE: CHAPTER 7 Writing The Program
Cohesion and Coupling CS 4311
Software Engineering Principles. SE Principles Principles are statements describing desirable properties of the product and process.
CCSB223/SAD/CHAPTER131 Chapter 13 Designing the System Internals.
1 CMPT 275 High Level Design Phase Modularization.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Introduction to Software Architecture.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Software Engineering and Object-Oriented Design Topics: Solutions Modules Key Programming Issues Development Methods Object-Oriented Principles.
Topic 4 - Database Design Unit 1 – Database Analysis and Design Advanced Higher Information Systems St Kentigern’s Academy.
SEG 4110 – Advanced Software Design and Reengineering Topic T Introduction to Refactoring.
Chapter 2 Principles of Programming and Software Engineering.
Design CS 470 – Software Engineering I Sheldon X. Liang, PH.D.
Chapter 9: Coupling & Cohesion Omar Meqdadi SE 273 Lecture 9 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Basic Characteristics of Object-Oriented Systems
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.
 System Requirement Specification and System Planning.
7. Modular and structured design
Coupling and Cohesion Rajni Bhalla.
Basic Concepts in Software Design
Coupling and Cohesion 1.
System Design and Modeling
Basic Concepts in Software Design
Software Design Mr. Manoj Kumar Kar.
Improving the Design “Can the design be better?”
CS223: Software Engineering
Programming Logic and Design Fourth Edition, Comprehensive
Software Design Lecture : 9.
Software Design Lecture : 8
Software Design Lecture : 10
Paper by D.L Parnas And D.P.Siewiorek Prepared by Xi Chen May 16,2003
Cohesion and Coupling.
Presentation transcript:

Software Design Principles 7th February, 2007 Naveed Arshad Assistant Professor LUMS naveedarshad@lums.edu.pk

Agenda Design Principles Abstraction Modularity Information Hiding Cohesion Coupling

Design Principle - Abstraction It is a means by which one can focus on the important aspects of a problem at a particular level without the hindrance of unnecessary or irrelevant and/or low-level detail.

Design Principle - Abstraction (cont’d) Hiding Low Level Details Where the details are coming from in the first place? How to hide details? What are details? How to extract important information from a mess of information?

Design Principle - Abstraction Everyday example

Design Principle - Abstraction Abstraction is a central topic both in CS and in SE. It is a cognitive means according to which, in order to overcome complexity at a specific stage of a problem solving situation, we concentrate on the essential features of our subject of thought, and ignore irrelevant details. Abstraction is especially essential in solving complex problems as it enables the problem solver to think in terms of conceptual ideas rather than in terms of their details. Abstraction can be expressed in different ways. [Jeff Kramer]

Abstraction – Why do we need it? Our mind can work with only 7(+/-) 2 items at one time. If we are given a long list of items we abstract out commonalities between different items and put these items into various categories.

Jet Drone VTOL Military Space Shuttle Glider Turboprop Helicopter Airship

Types of Abstraction Abstraction of appearance Abstraction of structure   Abstraction of functionality   Abstraction of privilege   Abstraction of purpose

Exercise: Abstraction of Appearance? Jet Drone VTOL Military Space Shuttle Glider Turboprop Helicopter Airship

Exercise: Abstraction of Structure? Jet Drone VTOL Military Space Shuttle Glider Turboprop Helicopter Airship

Exercise: Abstraction of Functionality? Jet Drone VTOL Military Space Shuttle Glider Turboprop Helicopter Airship

Exercise: Abstraction of Privilege? Jet Drone VTOL Military Space Shuttle Glider Turboprop Helicopter Airship

Exercise: Abstraction of Purpose? Jet Drone VTOL Military Space Shuttle Glider Turboprop Helicopter Airship

Levels of Abstraction Abstraction layers e.g. Database

Levels of Abstraction Describe this device in at least four different ways of abstraction? Describe the context, meaning and purpose of these abstraction?

Where is Abstraction Used? Abstraction is everywhere in Computer Science and Software Engineering

Abstraction in Software Engineering? Requirements Engineering - gather the critical aspects of the environment and required system while neglecting the irrelevant. Goals Assumptions Constraints Scope Properties Use Cases? Requirements Requirement Specification

Abstraction in Software Engineering? Design - articulate the software architecture and component functionalities which satisfy functional and non-functional requirements while avoiding unnecessary implementation constraints. User Interface Goals Assumptions Constraints Scope Properties Use Cases? Business Logic Data Layer Requirement Specification Software Architecture

Design Principle - Modularity What is Modularity (or Modularisation): Decomposing large software into a number of smaller as independent as possible components, usually with the goal of placing different functionalities or responsibilities in different components. A Component – the basic unit of modularisation (also called Modules) is A method A class A package Or other design element

Design Principle - Modularity Everyday Example

Design Principle - Modularity Why Modularity: Software consists of thousands or millions of lines of code and the complexity can be easily be overwhelming. Modularity allows such complexity to be manageable for purposes of implementation and maintenance Where Modularity is needed: Architectural Design: Layered software architecture is an example of modularity Independent Design: Enable the ability to design different components in different ways.

Design Principle - Modularity Where Modularity is needed: Component Design: Make sure each component has a single well-defined purpose or function, with few, clear connection (for example, by interfaces) with other components Debugging: Make bug finding easier as modularity allows bug finding to be with a particular component rather than the whole software Make bug fixed easier as correction to a single component will not produce “knock-on” effects Testing: Modularity makes it possible that the testing can be carried out in a piecemeal fashion – one component at a time. This is crucial important for testing of large and integrated software systems

Design Principle - Modularity Where Modularity is needed: Independent Implementation and Development : Make possible to distribute large software development into each individual in a team of people as far as the interface between components are clear and few. Summary: In conclusion, modular based design are useful for each phase of software development, from design, implementation, test, to maintenance. The reason behind this is that the as much as possible independence between the different components allows that the software tasks can be done separately to overcome high complexity in software development. So modularity is one of the key principles in software design

Design Principle - Modularity How to achieve modularity: Hierarchical decomposition design with the different level of abstraction: Decompose the components with clearly defined input and output and well identified purpose Decompose the components from higher more abstract level to lower more detailed level Minimise the interactions between components Balance component size and complexity The small size components will require a lot of connections between them in total although less complexity in each component The large size components will require less connections in total but more complexity in each component Therefore, a balance of component size is required

Design Principle – Information Hiding How to achieve modularity: Apply information hiding principle and approach What is the information hiding In modularisation context: Components hides the internal details and processing from one another In more general context: grouping and packaging the elements and internal details of an abstraction (a component, an abstract data type, a class or a object etc ) and making those details inaccessible Also called data hiding or encapsulation

Design Principle – Information Hiding Everyday example: Suppose you have to pay the bill of your newspaper subscription to your hawker. You can give your bill in two ways. Take out your wallet and give the wallet to the hawker so that he can take his bill’s amount out of your wallet. Take out your wallet, ask the bill amount from the hawker and give him the asked amount. Which option is better?

Design Principle – Information Hiding Why information hiding in design: each component hides a design decision from the others to achieve Changeability If a design decision is changed, such as a data structure, changes are confined to as few components as possible whereas the design as a whole can remain intact Independent development Enable independent development as far as the interfaces between components are simple and well defined. Also access methods are often simpler than access data Comprehensibility For design, debug, testing and maintenance, it is vital to understand each component independently of others. Information hiding improves our understanding by eliminating confusing from unrelated functions and data.

Design Principle – Information Hiding How to achieve information hiding Apply the information hiding principle in design Aiming at the end of the design process, any data structure or file is accessed only via certain well-defined specific methods (interfaces) Separation of interface and implementation Separating interface and implementation involves defining a component by specifying a public interface, separate from (or hid) the details of how the component is realized. Choose programming languages support Information hiding Such as Java, C++, C#, Visual Basic, .Net

Design Principle – Coupling and Cohesion What are Coupling Coupling is a term to describe the interactions between components. The lower coupling, the less interaction (i.e., the more independence ) between components Design Principle: Minimise Coupling Coupling connections cause dependencies between components, which, in turn, have an impact on system qualities such as maintainability (a modification of a components may require modifications to its connected components) or testability (a fault in one components may cause a failure in a completely different, connected components). Thus, a common design principle is to minimize coupling.

Design Principle – Coupling and Cohesion What are Cohesion Cohesion is a term to describe the interactions within components. The more cohesive a component, the more related the internal parts of the component to each other and to its whole purpose Design Principle: Maximise Cohesion A low cohesive design element has been assigned many unrelated responsibilities. Consequently, the design element is more difficult to understand and therefore also harder to maintain and reuse. Design elements with low cohesion should be considered for refactoring, for instance, by extracting parts of the functionality to separate classes with clearly defined responsibilities.

Design Principle – Coupling and Cohesion Everyday Example

Design Principle – Coupling and Cohesion Everyday Example

Design Principle – Coupling and Cohesion Relationship between Coupling and Cohesion Coupling and cohesion are opposite sides in that strong cohesion tends to create weak coupling and vice versa

Design Principle – Coupling and Cohesion Examples of Coupling and Cohesion High Coupling Low Cohesion Low Coupling High Cohesion Which one is better from a software design point of view and why?

Design Principle – Coupling and Cohesion Types of coupling: Content coupling Common coupling Control coupling Stamp coupling Data coupling

Design Principle – Coupling and Cohesion Types of Coupling Content Coupling (i.e., modifying data within another component) Allowing one component to modify another component data. This is very strong coupling as a fault in one component may be caused by another Common Coupling (i.e., shared or global data) Several components sharing the same or global data cause strong coupling between the components via data

Design Principle – Coupling and Cohesion Types of Coupling Control Coupling (i.e., a method call with a parameter that is a switch) Passing parameters to control the activity of another component and allowing one component to control another component behaviour. This is a relatively strong couple as a fault in one component may be caused by another Sample Coupling This is the case where entire data structures are passed to the called component but only some individual fields are used

Design Principle – Coupling and Cohesion Types of Coupling Data Coupling Pass pure data parameters into another component. Often used interaction between components. This is a weak couple and leaves less room for errors Pass a series stream of data to another component without any transfer of control between components. This is the weakest coupling and supported by Java Conclusion Strong coupling increases dependency and complexity, decreases transparency of components, and leave more room for errors Weak coupling between components is desired as it increases the modularity, is easy to manage, and reduces errors

Design Principle – Coupling and Cohesion The different degree of coupling in order High Coupling Content Coupling Common Coupling Control Coupling Sample Coupling Data Coupling Uncoupled Low Coupling

Design Principle – Coupling and Cohesion Types of Cohesion Coincidental Cohesion Logical Cohesion Temporal Cohesion Procedural Cohesion Communication Cohesion Sequential Cohesion Functional Cohesion

Design Principle – Coupling and Cohesion Types of Cohesion Coincidental Cohesion The worst degree of cohesion in which unrelated functions, processes, or data are put into a same component coincidently such as order book, watch TV, walk dog, go shopping. This leads the component without well defined purpose Logical Cohesion The second worst degree of cohesion where several logically related functions or data elements are placed in the same component such as all output functions to screen, to printer, to fax machine, and to database are placed together but without taking into account the different purposes

Design Principle – Coupling and Cohesion Types of Cohesion Temporal Cohesion Very weak cohesion in which functions or processes are put into a same component only because they have to be carried out at about the same time such as: put out milk bottle, put out cat; turn off TV; brush teeth. They’re all part of an end-of-day routine. These activities are unrelated to one another except that they’re carried out at a particular time. Procedural Cohesion Weak cohesion in which functions or processes are put into a same component only because they happen in a certain order such as: enter data; check data, and calculation They are related by order of execution rather than by any single problem-related function.

Design Principle – Coupling and Cohesion Types of Cohesion Communicational Cohesion Relative weak cohesion in which functions or processes are put into a same component because they act on the same data such as find title of book; find price of book; find author of book; find publisher of book; find published date of book. These four activities are related because they all work on the same data – book The weakness is that it is narrow on one side (book) and arbitrarily broad on the other (find title, price, author, publisher, date etc) depending on the number of functions in the component. This could lead to duplication or redundant of functions (think about “book” is changed to PC, then all “find” functions needed to be recoded)

Design Principle – Coupling and Cohesion Types of Cohesion Sequential Cohesion Certain cohesion in which the output from one part of a component is input to the next part such as: clear car body; fill in holes in car; sand car body; apply primer This group of four activities can not be summed up as a single function (purpose), which means the component is not functionally cohesive (as they are not constructed to a well defined function or purpose). If adding one more step ”put final coat”, we would have a functionally cohesive component called REPAINT CAR.

Design Principle – Coupling and Cohesion Types of Cohesion Functional Cohesion Best cohesion in which every processing element is essential to the performance of a single function, and all essential elements are contained in one component. The functionally cohesive component performs the function for which it is designed, and only performs that function and nothing else. Conclusion Cohesion is the measure of the functional relatedness of elements (instructions, data definitions, etc.) within a single component. In a good design, the cohesion of every component is high. Together with coupling, cohesion is one of the good measures of the quality of a design.

Design Principle – Coupling and Cohesion The different degree of cohesion in order High Cohesion Functional Sequential Communication Procedural Temporal Logical Coincidental Low Cohesion

References To prepare these slides I have used notes and slides from these people Xiao-Jun Zeng Jeff Kramer