Software Design

1. Software Design Lecture : 11

2. Software Design Components • Principle • Criteria(this lecture) • Techniques (this lecture)

4. Range of Cohesion High Cohesion Functional Sequential Communicational Procedural Temporal Logical Coincidental Low

5. Sequential Cohesion • The output of one component is the input to another. • Occurs naturally in functional programming languages • Good situation

6. Example • Retrieve customer Data • Retrieve customer order • Generate invoice • Get and edit input data.

7. 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. • Ideal situation.

8. 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. • For example, Calculate Net Pay is functionally cohesive although it contains many different functions (e.g., calculate taxable deductions, calculate tax, calculate CPP deduction).

9. 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.

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 pulling out any one element might cause the whole structure to collapse

14. Extensibility • We need extendibility because at the basis of all software lies some human phenomenon and hence indecisiveness

15. Principles for achieving Extensibility • Design simplicity: a simple architecture will always be easier to adapt to changes than a complex one • Decentralization: the more autonomous the modules, the higher the likelihood that a simple change will affect just one module, or a small number of modules, rather than triggering off a chain reaction of changes over the whole system.

16. Problem Statement • In the electric subsystem of the house where there are electric wires and appliances running. Each appliance is having it’s own functionality and working. Each appliance is having it’s own clear boundary into which it works. • Task is to identify level of coupling and cohesion in the scenario. • Write a scenario which should reverse the solution

17. Solution to example • The given scenario is having no interdependency and each appliance is encapsulated within its own boundary so the system is having low or no coupling but high level of cohesion. • Hint for Task ii: “Central”

20. Open / Close Principle • Bertrand Meyer: “Software entities like classes, modules and functions should be closed but open for extension. • Closed • The source code of the module inviolate; no one is allowed to make changes to the code the module can be used without risk

21. Open / Close Principle • Open • The module is open for extension according to new requirements the module can be extended to behave in new and different ways.

22. Open / Closed Principle • A module that is open for extension is a module whose behavior can be altered to suit new requirements. • A module that is closed for modification is a module whose source code is frozen and cannot be changed

23. The “Open/Closed principle” – Usage in an object oriented paradigm • The Open/Closed principle can be applied in object oriented paradigms with the help of inheritance and polymorphism: • The interface of the module becomes an abstract class A • If needed new Subclasses of A can be derived; these subclasses may extend A

24. What is Class • Basic implementation unit in OOP. • It encapsulate data members and methods. • Classes have objects or classes are assessed via their objects. • Data members are accessed through getters and setters methods.

25. public class test { int a ; float b; public class() {} void seta(int a) { this.a=a; } int geta () { return this.a; }

26. Abstract Classes • Abstract class is a class that can not be instantiated, it exists extensively for inheritance and it must be inherited. There are scenarios in which it is useful to define classes that is not intended to instantiate; because such classes normally are used as base-classes in inheritance hierarchies

27. Inheritance • It implies the functionality of data sharing between super and sub class. • All the data members and methods of super class are available for use in sub class but not vice-versa. • Subclass extends the functionality of super class to use the base class methods.

28. Example of Abstract class and Inheritance • In an object-oriented drawing application, you can draw circles, rectangles, lines, Bezier curves, and many other graphic objects. These objects all have certain states (for example: position, orientation, line color, fill color) and behaviors (for example: moveTo, rotate, resize, draw) in common.

30. abstract class GraphicObject { int x, y; void moveTo(int newX, int newY) { ... } abstract void draw(); abstract void resize(); }

31. class Circle extends GraphicObject { void draw() { ... } void resize() { ... } }

32. Polymorphism • In the context of object-oriented 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. • Polymorphism is the ability to redefine methods for derived classes.

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 signatures

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 Run-time Polymorphism

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 i-e profit and loss account etc without change in the design of the system

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 issuanceValidator looks to see if the balance of book is above certain values and then approves the request. • Given this problem, one of the developer comes up with the following classes. The libraryrequestHandler can assess a issue request. This class holds the balance of remaining books and period of hold of books for a particular student account.

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 System.out.println("Sorry more books are in balance..."); }}

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