CS352 – Software Engineering II Lecture 3: Software Design I

1. CS352 – Software Engineering IILecture 3: Software Design I Slides by Mohammad El-Ramly, PhD http://www.acadox.com/join/24VZEM http://www.acadox.com/class/3962

2. تذكرة من كان يريد العاجلة عجلنا له فيها ما نشاء لمن نريد ثم جعلنا له جهنم يصلاها مذموما مدحورا ومن أراد الآخرةوسعى لها سعيها وهو مؤمن فأولئك كان سعيهم مشكورا كلا نمد هؤلاء وهؤلاء من عطاء ربك وما كان عطاء ربك محظورا انظر كيف فضلنا بعضهم على بعض وللآخرة أكبر درجات وأكبر تفضيلا

3. Lecture 3 Outline • Assignment 1 • Project • OO Design Principles • Single Responsibility Principle • Open Close Principle • Liskov’ Substitution Principle

4. Course Contents We will cover as much of these as we can: • Design and design patterns 33.3% • Introduction to Design (~4 wks) • Software Architecture • Design Principles • Design Patterns • Design QA & Evaluation • Transforming Design to Code • Quality Assurance and Audits 33.3% • Testing 33.3%

6. SWEBOK v3.0 Design KA

7. SWEBOK v3.0 Design KA • SWD Fundamentals • Key Issues in SWD • SW Structure and Arch. • UI Design • SWD QA and Evaluation • SWD Notations • SWD Strategies and Methods • SWD Tools

8. Software Architecture • Architecture is the organizational structure of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems. (UML 1.3)

9. Example SW Architecture

10. Architecture Styles • pipe and filter • object oriented • event based • layered • repositories • process control

12. Characteristics of Bad Design (Robert Martin) • Rigidity - It is hard to change because every change affects too many other parts of the system. • Fragility - When you make a change, unexpected parts of the system break. • Immobility - It is hard to reuse in another application because it cannot be disentangled from the current application.

13. Characteristics of Bad Design (Robert Martin) • Viscosity: • SW Viscosity – hacking is easier than taking good design decision. • Development environment Viscosity - It takes forever to edit, compile, test loop. • Needless complexity: There are lots of very clever code structures that aren’t actually necessary or can be written in simpler ways.

14. SW Design Principles (SOLID) by Robert Martin • A a set of guidelines that helps us to avoid having a bad design. • Single Responsibility Principle • Open Close Principle • Liskov's Substitution Principle • Interface Segregation Principle • Dependency Inversion Principle

15. SW Design Principles (SOLID) by Robert Martin • Author of • Clean Code • And other books

16. I. Single Responsibility Principle • A class should have only one reason to change. • A class represents one concept andcarries one responsibility only.

17. I. Single Responsibility Principle • This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes. • Each class will handle only one responsibility and on future if we need to make one change we are going to make it in the class which handle it.

18. I. Single Responsibility Principle • When we need to make a change in a class having more responsibilities the change might affect the other functionality of the classes. • Single Responsibility Principle was introduced Tom DeMarco in his book Structured Analysis and Systems Specification, 1979. Robert Martin reinterpreted the concept and defined the responsibility as a reason to change.

19. I. Single Responsibility Principle1 • Badly coupled code

20. I. Single Responsibility Principle2 • The above class is fragile. • change from Access to Oracle • change the format of the tax report • Need to change Employee! • In reality, we want to separate all these concepts into their own classes so that each class has one, and only one, reason to change.

21. I. Single Responsibility Principle3 • A better structure

23. II. Open Close Principle • Software entities like classes, modules and functions should be open for extension but closed for modifications. • OPC is a generic principle. • The same principle can be applied for modules, packages, libraries.

24. II. Open Close Principle • When writing a class, ensure that when you need to extend its behavior you don’t have to change the class but to extend it. • If you have a library containing a set of classes there are reasons for you to prefer to extend it without changing the existing code (backward compatibility, regression testing, �).

25. II. Open Close Principle • Open Close Principle can be ensured by use of Abstract Classes and concrete classes for implementing their behavior. • Template Pattern and Strategy Pattern.

26. II. Open Close Principle Violations • Among the systems that are plagued by violations of OCP are GUIs. • All too often the code that manipulates the GUI API is inextricably bound to the code that manages and manipulates the data being displayed.

27. II. Open Close Principle GUI Example

28. II. Open Close Principle Examples • http://joelabrahamsson.com/a-simple-example-of-the-openclosed-principle/ • http://joelabrahamsson.com/the-openclosed-principle-a-real-world-example/

30. III. Liskov's Substitution Principle • Derived types must be completely substitutable for their base types. • It is an extension of the Open Close Pr. • New derived classes must extend the base classes without changing their behavior. • Derived classes should be able to replace the base classes without any change in the code.

31. III. Liskov's Substitution Principle • What is the problem with this diagram? • Solution: Inheritance -> Composition

32. III. Liskov's Substitution Principle • Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. • Likov's Substitution Principle states that if a program module is using a Base class, then the reference to the Base class can be replaced with a Derived class without affecting the functionality of the program module.

33. III. Liskov's Substitution Principle • All the time we derive new classes from base ones. • New derived classes must just extend without replacing the functionality of old classes. • Otherwise the new classes can produce undesired effects when they are used in existing program modules.

34. III. Liskov's Substitution Principle • In any client code, if subtype object is substituted for supertype object, the client’s expectations are still met • A subclass must keep all the external observable behavior of its superclass • A subclass may extend the external observable behavior, but never modify it • External observable behavior = behaviour of public methods

35. III. Liskov's Substitution Principle Importance • Programmers that write client modules usually assume Inclusion Polymorphism when writing OO Programs • If we don’t comply with LSP, we may compromise not only reusability, but also correctness!

36. III. Liskov's Substitution Principle Importance • The users of base classes should not have to do anything special in order to use derivatives. • Specifically, they should not have to use instanceof, or downcasts. • They should know nothing about the derivatives at all. Not even that they exist

37. III. Liskov's Substitution Principle Example1 • Payroll system

38. III. Liskov's Substitution Principle Example2 • What would happen if we decided to add a VolunteerEmployee? • Wrong! Might mail a paycheck with a gross pay of zero.

39. III. Liskov's Substitution Principle Example3 • Maybe the best thing to do is to throw an exception: • But the following code is now illegal.

40. III. Liskov's Substitution Principle Example4 • To make it legal, we have

41. III. Liskov's Substitution Principle Example5 • This is ugly, complicated, and distracting. We might change it to:

42. III. Liskov's Substitution Principle Example7 • This is even worse because now code that was supposed to operate on the Employee base class makes explicit reference to one of its derivatives. • Violates the LSP! • VolunteerEmployee is not substitutable for Employee. • User of Employee are impacted by the very presence of VolunteerEmployee.

43. III. Liskov's Substitution Principle Example6 • Solutions • Volunteers are not employees. • VolunteerEmployee should not derive from Employee. • VolunteerEmployee should not be passed to functions that need to call calcPay.

45. Lecture 4 Outline • Assignment 1 • Rest of OO Design Principles • Single Responsibility Principle • Open Close Principle • Liskov's Substitution Principle • Interface Segregation Principle • Dependency Inversion Principle • Steve McConnell’s Views on Design • Characteristics of a Good Design • How to tackle the Design Problem

46. IV. Interface Segregation Principle • No client should be forced to depend on methods (interfaces) it does not use. • Take care how you write our interfaces. • Add only methods that should be there. • If we add methods that should not be there the classes implementing the interface will have to implement those methods as well.

47. IV. Interface Segregation Principle • Interfaces containing methods that are not specific to it are called polluted or fat interfaces. Avoid them. • Many client specific interfaces are better than one general purpose interface

48. IV. Interface Segregation Principle • If we want to extend our application adding another module that contains only some of the methods of the original system, we are forced to implement the full interface and to write some dummy methods.

49. IV. Interface Segregation Principle Without ISP • Some interfaces are created with huge amount of functionalities. But when those interfaces are implemented by client implementor classes, not required functionalities are forced to be implemented, and so the code will have many dummy or empty implementations.

50. IV. Interface Segregation Principle With ISP • This situation can be prevented by segregating (i.e separating) big interfaces into smaller ones. Only strictly related method definitions must be in the same interface. Different types of functionalities must be placed in different interfaces. This is ISP.