Lecture # 06 Design Principles II SWE 316: Software Design and Architecture Lecture # 06 Design Principles II Flexibility, Reusability, & Efficiency Ch 5 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Aspects of Flexibility Reusability Efficiency Trade-off between Principles 2/24 Aspects of Flexibility Flexible design implies a design that easily can accommodate the changes Anticipate.. … adding more of the same kind of functionality Example (banking application): handle more kinds of accounts without having to change the existing design or code … adding different functionality Example: add withdraw function to existing deposit functionality … changing functionality Example: allow overdrafts

Registering Website Members Flexibility Reusability Efficiency Trade-off between Principles 3/24 Registering Website Members members 0..n WebSite register() Member Example: Registering members at a web site (Design 1) What’s wrong with this design? Difficult to add new type of members since it is fixed here. It’s better to have member as abstract class.

Registering Website Members Flexibly Flexibility Reusability Efficiency Trade-off between Principles 4/24 Registering Website Members Flexibly members 0..n WebSite Member YMember XMember StandardMember Example: Registering members at a web site (Design 2: a flexible design)

Adding Functionality to an Application Flexibility Reusability Efficiency Trade-off between Principles 5/24 Adding Functionality to an Application Alternative Situations Accommodate adding new kinds of functionality Adding functionality to an application: alternative situations: Within the scope of … Within the scope of a list of related functions Example: add print to an air travel itinerary functions Within the scope of an existing base class Example: add “print road- and ship- to air itinerary ” Within the scope of: neither Example: add “print itineraries for combinations of air, road and ship transportation”

Adding Functionality When a Base Class Exists Flexibility Reusability Efficiency Trade-off between Principles 6/24 Adding Functionality When a Base Class Exists Trip printItinerary() SomeApplicationClass Method(s) call printItinerary() StandardTrip printItinerary() Case 1: Case 1 can be handled by adding the new method to an existing set of methods of a class Add method print() to the class Itinerary.

Adding Functionality Through a Base Class Flexibility Reusability Efficiency Trade-off between Principles 7/24 Adding Functionality Through a Base Class Trip printItinerary() SomeApplicationClass StandardTrip printItinerary() LandTrip printItinerary() SeaTrip printItinerary() Case 2: Adding functionality when a base class exists Case 3: covered later (chapter 9)

Additional Type of Flexibiliy Flexibility Reusability Efficiency Trade-off between Principles 8/24 Additional Type of Flexibiliy Flexibility Aspect: ability to … Described in … … create objects in variable configurations determined at runtime “Creational” design patterns … create variable trees of objects or other structures at runtime “Structural” design patterns … change, recombine, or otherwise capture the mutual behavior of a set of objects “Behavioral” design patterns … create and store a possibly complex object of a class. … configure objects of predefined complex classes – or sets of classes – so as to interact in many ways Component technology – chapter 10 Ch 7 Ch 8 Ch 9 Ch 10

Trade-off between Principles Flexibility Reusability Efficiency Trade-off between Principles 9/24 Reusability Designing a software system such that components of a developed system can be used again in developing new applications Reusability is an important factor in producing low cost applications Reusability at the architectural/design level (design patterns) Reusability at the implemented component level (design components) Our focus in this chapter is to cover: Reusable functions Reusable classes Reusable class combinations

Reusability of function design Flexibility Reusability Efficiency Trade-off between Principles 10/24 Reusability of function design Simple methods Guidelines for designing reusable methods Reusable methods must be defined completely Reusable methods must be independent of their environment, e.g., Static methods Makes the design looser coupling, less coherent and less object- oriented. Name of a reusable method must be reflective of its functionality

Making a Method Re-usable Flexibility Reusability Efficiency Trade-off between Principles 11/24 Making a Method Re-usable Specify completely Preconditions etc Avoid unnecessary coupling with the enclosing class Make static if feasible Include parameterization i.e., make the method functional But limit the number of parameters Make the names expressive Understandability promotes re-usability Explain the algorithm Re-users need to know how the algorithm works

Making a Class Re-usable Flexibility Reusability Efficiency Trade-off between Principles 12/24 Making a Class Re-usable Describe the class completely Make the class name and functionality match a real world concept Define a useful abstraction attain broad applicability Reduce dependencies on other classes Elevate dependencies in hierarchy alternatives

Reducing Dependency Among Classes Flexibility Reusability Efficiency Trade-off between Principles 13/24 Reducing Dependency Among Classes Replace … Student Course With !!! What do you think? Student Course Enrollment Increase the reusability of a class by reducing its dependencies.

Leveraging Inheritance, Aggregation and Dependency Flexibility Leveraging Inheritance, Aggregation and Dependency Reusability Efficiency Trade-off between Principles 14/24 Customer computeBill() (1) Leveraging inheritance RegularCustomer computeBill() Customer computeBill() (2) Leveraging aggregation Customer computeBill() Bill compute() Customer computeBill( Orders ) Orders value() (3) Leveraging dependency

Trade-off between Principles Flexibility Reusability Efficiency Trade-off between Principles 15/24 Efficiency Applications must execute required functionality within required time constraints Two dimensions of efficiency: time and space Ideally optimize a design for both time and space

Space-Time Trade-offs Flexibility Reusability Efficiency Trade-off between Principles 16/24 Space-Time Trade-offs Time to process one item Typical target Space

Basic Approaches to Time Efficiency Flexibility Reusability Efficiency Trade-off between Principles 17/24 Basic Approaches to Time Efficiency Design for Other Criteria, Then Consider Efficiency Design for flexibility, reusability , … At some point, identify inefficient places Make targeted changes to improve efficiency Design for Efficiency From the Start Identify key efficiency requirements up front Design for these requirements during all phases Combine These Two Approaches Make trade-offs for efficiency requirements during design Address remaining efficiency issues after initial design

Trade-off between Principles Flexibility Reusability Efficiency Trade-off between Principles 18/24 Speed efficiency Real-time applications are the most demanding in terms of speed Profiler--- an application that tracks resource usage during program execution

Impediments to Speed Efficiency Flexibility Reusability Efficiency Trade-off between Principles 19/24 Impediments to Speed Efficiency Loops while, for, do (think about sorting algorithms) Remote operations Requiring a network LAN The Internet Function calls -- if the function called results in the above Object creation

Trade-off between Principles Flexibility Reusability Efficiency Trade-off between Principles 20/24 Trade-off Between Number of Remote Calls and Volume Retrieved at Each Call Volume retrieved at each access Typical target Number of remote accesses

Attaining Storage Efficiency Flexibility Reusability Efficiency Trade-off between Principles 21/24 Attaining Storage Efficiency Store only the data needed Trades off storage efficiency vs. time to extract and re-integrate Compress the data Trades off storage efficiency vs. time to compress and decompress Store in order of relative frequency Trades off storage efficiency vs. time to determine location

Trading off Robustness, Flexibility, Efficiency and Reusability Trade-off between Principles 22/24 Trading off Robustness, Flexibility, Efficiency and Reusability I think you forgot to mention “Correctness” 1A. Extreme Programming Approach Design for sufficiency only 1B. Flexibility-driven Approach Design for extensive future requirements Reuse usually a by-product 2. Ensure robustness 3. Provide enough efficiency Compromise re-use etc. as necessary to attain efficiency requirements - or -

A More Flexible Design for Calculator Application Flexibility Reusability Efficiency Trade-off between Principles 23/24 A More Flexible Design for Calculator Application Existing Design New Design Calculator solicitNumAccounts() CalcDisplay display() CommandLineCalculator main() executeAdditions() solicitNumberAccounts() getAnInputFromUser() interactWithUser() CalcOperation execute() Add Multiply Divide

Summary of This Chapter Flexibility Reusability Efficiency Trade-off between Principles 24/24 Summary of This Chapter Flexibility == readily changeable We design flexibly, introducing parts, because change and reuse are likely. Reusability in other applications Efficiency in time in space (These add to Correctness & Robustness, covered in chapter 4)