Software design - Lecture 11. The main topics covered in this chapter include: software design components; sequential cohesion; functional cohesion – highly cohesive; scale of cohesion vs maintainability; general rule of cohesion; principles for achieving extensibility;...
1 Software Design Lecture : 11 Software Design Components Ø Principle Ø Criteria(this lecture) Ø Techniques (this lecture) Range of Cohesion High Cohesion Functional Sequential Communicational Procedural Temporal Logical Coincidental Low Sequential Cohesion Ø The output of one component is the input to another Ø Occurs naturally in functional programming languages Ø Example i Retrieve customer Data ii Retrieve customer order iii Generate invoice iv Get and edit input data Functional Cohesion – Highly cohesive Ø Definition: Every essential element to a single computation is contained in the component Ø A functionally cohesive module performs one and only one problem related task Examples Ø Calculate Net Pay Ø A complex module with numerous sub modules may still be functionally cohesive if all of its subordinate modules are only performed to carry out the task of the parent module Scale of Cohesion Vs Maintainability 10 General Rule of Cohesion ü A module will be cohesive if most of the methods defined in a class use most of the data members most of the time. If we find different subsets of data within the same module being manipulated by separate groups of functions then the module is not cohesive and should be broken down as shown below 32 Polymorphism Ø In the context of objectoriented programming, is the ability to create a variable, a function, or an object that has more than one form Ø Polymorphism is the ability to process objects differently depending on their data types 33 Types of Polymorphism Ø Compile time Polymorphism Ø Compile time Polymorphism also known as method overloading Ø Method overloading means having two or more methods with the same name but with different 34 Example of Compile Time Polymorphism 35 Runtime Polymorphism Ø Run time Polymorphism also known as method overriding Ø Method overriding means having two or more methods with the same name , same signature but with different implementation 36 Example of Runtime Polymorphism 37 38 39 Example ü We have to design a banking system in which there are several clients who are availing the facility of maintaining the account in the bank. As an international norm bank is offering multiple type of accounts to it’s customers like savings, current etc. Each account is having a facility of deposit and withdrawal attached with it for it’s client. 40 Example Ø Task to do: ü We have to design the system in such a way that should accommodate the addition of new account types ie profit and loss account etc without change in the design of the system 41 42 Another Example Ø You are going to design a library application where a particular request for issuance of book is passed through a issueValidator to approve the issue request. The 43 Code in Java 44 public class libraryRequestHandler { private int balance; private int period; public libraryRequestHandler(int balance, int period) { this.balance = balance; this.period = period; } public void approverequest(issuanceValidator validator) { if(validator.isValid(balance)) System.out.println(“Request approved "); else 45 PersonalLoanValidator Class public class issuanceValidator { public issueanceValidator() { } public boolean isValid(int balance) { if(balance>5) return true; else return false; 46 Task To Do • • • In future the bank should be able to handle business type of accounts also Identify the violation of open/close principle in classes defined Reverse Engineered it and generate the class design of the code and create a solution with no violation of open/close principle ...2 Software? ?Design Components Ø Principle Ø Criteria(this? ?lecture) Ø Techniques (this? ?lecture) Range of Cohesion High Cohesion Functional Sequential... functions then the module is not cohesive and should be broken down as shown below 11 12 Extensibility ü Extendibility is the ease of adapting? ?software? ? products to changes of specification 13 Extensibility ü... For small programs change is usually not a difficult issue; but as? ?software? ?grows bigger, it becomes harder and harder to adapt ü A large? ?software? ?system often looks to its maintainers as a giant house of cards in which