Design COP 3538 Summer 2012 © Lethbridge/Laganière 2001 Chapter 9: Architecting and - PowerPoint Presentation

Design COP 3538 Summer 2012

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 2 The Process of Design Definition: Design is a problem-solving process whose objective is to find and describe a way: To implement the system’s functional requirements ... w hile respecting the constraints imposed by non-functional requirements... Such as performance, maintainability, security, persistence, cost, reliability, portability, etc…..(long list) including also the budget, technologies, environment, legal issues, deadlines, ... a nd while adhering to general principles of good quality Consider this perspective:

3 Object-Oriented Analysis An investigation of the problem (rather than how a solution is defined)During OO analysis, there is an emphasis on finding and describing the objects (or concepts) in the problem domain.For example, concepts in a Library Information System include Book , and Library.

4 Object-Oriented Design Emphasizes a conceptual solution that fulfills the requirements. Need to define software objects and how they collaborate to fulfill (satisfy) the requirements.For example, in the Library Information System, a Book software object may have a title attribute, an ISBN number, and a getChapter method.Designs are implemented in a programming language .In the example, we will have a Book class in Java.

5 From Design to Implementation Book title print() public class Book { public void print(); private String title; } Book (concept) Analysis investigation of the problem Design logical solution Construction code Domain concept Representation in analysis of concepts Representation in an object-oriented programming language.

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 6 Process of Design Design is all about decisions . Approaches: Top down – start with the architecture  Bottom up – start with utilities There are a number of very serious design principles that lead to maintainable software that may persist for years We will look at satisfying functional requirements while accommodating portability, reuse potential, performance There are always TRADEOFFS! There is no free lunch!!!-- Will look at several of the tradeoffs Will look at a software architecture to support your high-level design

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 7 Design as a Series of Decisions A designer is faced with a series of design issues These are sub-problems of the overall design problem. Always several alternative solutions: design options . Designer makes a design decisions to resolve issues. This process involves choosing the best option from among alternatives. Recognize that there may be a number of solutions – in fact, there may be a number of good solutions for the problem to be solved. We would like the ‘best’ one.

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 8 Making decisions To make each design decision, the software engineer uses: Knowledge of the requirements (use cases, UI prototype, feature lists, supplementary specification document, class diagrams, interaction diagrams …) the design as created ‘so far’ Available technologies (RMI, RPC, xml, jsp , servlets, html, jdbc , etc .) given a development environment software design principles and ‘best practices’ what has worked well in the past Sometimes there is no single, best solution.Sometimes they conflict – each presenting pros and cons

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 9 ‘Design space’ – example Consider choice of thin client vs fat client options: The space of possible designs that could be achieved by choosing different sets of alternatives is often called the design space (more efficient use of CPU and of network resources) Why??? (simpler software) Adv of fat client: bandwidth, networking services, reduced need for powerful server… Adv of thin client: simpler client devices; maintaining services; central bus logic… Disadvantages? Know! Cost, reliability, maintenance, security, bandwidth, network traffic; Never a single answer for all cases!  Design! client-server monolithic separate user interface layer for client no separate user interface layer for client fat-client thin-client programmed in Java programmed in .Net programmed in C++; C#?

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 10 Criticality of Certain Design Decisions Some design decisions are critical ; others not so. Example: architectural design decision to separate the user interface module from rest of system. Yes: easier to develop and maintain, internationalize, employ reuse. No: Likely not as efficient ; (disadvantage. why ?) Recommend iterating User Interface as a part of iteration planning! As increments of value are produced, so too should the interface evolve.

Modeling – Design Model Note that the design model (assumes a good domain model depicting important concepts in the business domain) really is a set of diagrams showing logical design. This will include software class diagrams, design level sequence diagrams (as opposed to analysis level sequence diagrams using conceptual objects…. and lots of abstraction) as well as package diagrams. (Larman)The software architecture model will include a summary of design ideas and their motivations. Why??? © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 11

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 12 Features of Top-down and Bottom-up Design Top-down design First design the very high level structure of the system. Then gradually work down to detailed decisions about low-level constructs. Finally arrive at detailed decisions such as: the format of particular data items; the individual algorithms that will be used. Start with the software architecture and the type of database that will be used (not ‘which’ database). Ultimately arrive at specific data items and detailed algorithms.

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 13 Top-down and B ottom-up D esign Bottom-up design Make decisions about reusable low-level utilities. Then decide how these will be put together to create high-level constructs.

Hybrid A mix of top-down and bottom-up approaches is normally used: Top-down design is almost always needed to give the system a good structure (architecture) . Bottom-up design is normally useful so that reusable components can be created.

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 15 Different Aspects of Design – Very important!! All kinds of ‘design’ This is where the decisions are made!!!!  Architecture design : The division into subsystems and components , How these will be connected and interact. Interfaces . Class design: The various features of classes.User interface design Algorithm design: The design of computational mechanisms.Protocol design: The design of communications protocol. For a while, now, we will emphasize Architectural Design – after we discuss class design.

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 16 Principles Leading to Good Design Overall goals of Good Design: Increase profit by reducing cost and increasing revenue Ensure design accommodates requirements Speed up development for use / competing in marketplaceIncrease qualities such asUsability – learnability; ease of use; on-line help…EfficiencyReliabilityMaintainabilityReusability to reduce cost and increase revenues

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 17 Design Principle 1: Divide and conquer Trying to deal with something big all at once is normally much more difficult than dealing with a series of smaller, manag able, understandable things Hence the iterative approach to software development) A software engineer/software developer can specialize . Specialize in network, distribution, database, algorithms, searching / sorting techniques… Individual components smaller , easier to understand.Parts can be replaced or changed without having to replace or extensively change other parts.

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 18 Ways of Dividing a Software S ystem A distributed system is divided up into clients and servers A system is divided up into subsystems A subsystem can be divided up into one or more packages A package is divided up into classes A class is divided up into attributes and methods

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 19 Design Principle 2: Increase ( High ) C ohesion where possible Divide and Conquer says split things up. Smaller parts , easier to grasp. A subsystem or module has high cohesion if it keeps together things that are related to each other, and keeps other things out!Makes system as a whole easier to understand / change Type of cohesion:Functional, Layer, Communicational, Sequential, Procedural, Temporal, Utility

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 20 Functional Cohesion Achieved when all the code that computes a particular result is kept together - and everything else is kept out i.e. when a module only performs a single computation, and returns a result, without having side-effects.No changes to anything but the computationNormally implemented via parametersCan call other methods, if cohesion is preserved.(Recall: Call by Value; Call by Reference… as examples)Avoid things like common, global data, more Benefits to the system:Easier to understandMore reusableEasier to replaceExample: pass an array of integers; sort the array and return sorted array. Can change algorithms if interface remains unchanged…

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 21 Layer Cohesion All facilities for providing or accessing a set of related services are kept together, and everything else is kept out The layers should form a hierarchy ( Sample Layers – presentation (interface); business (domain) logic; application logic; technical services…) Higher layers can access services of lower layers, Lower layers do not access higher layersWill talk about architectural layers a great deal very soon…The set of procedures through which a layer provides its services is the application programming interface (API)Specification of API says how to use it.  You can replace a layer without having any impact on the other layers because you know that it does not access upper layers.E.g. Replace the UI layer….

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 22 Example of the Use of Layers Screen display facilities User account management File system Kernel (handling processes and swapping) Application programs User interface Application logic Database access Network communication Transmitting and receiving Dealing with packets Dealing with connections Dealing with application protocols a) Typical layers in an application program b) Typical layers in an operating system c) Simplified view of layers in a communication system Operating system access Examples: services for computations; transmissions of messages; storage of data; managing security, interacting with users; accessing the operating system; interacting with hardware, and more Sometimes we have a business services and then a domain (more general) layer… Will have a middleware layer often!

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 23 Communicational Cohesion All the modules that access or “manipulate certain data” are kept together (e.g. in the same class) - and everything else is kept ou t A class would have good communicational cohesion if all the system’s facilities for storing and manipulating its data are contained in this class. if the class does not do anything other than manage its data. Main advantage: When you need to make changes to the data, you find all the code in one place Keep methods where the data is, if possible.Talk about this extensively in Data Structures course!!

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 24 Other Measures of Cohesion Sequential Cohesion Procedures, in which one procedure provides input to the next , are kept together – and everything else is kept out You should achieve sequential cohesion, only once you have already achieved the preceding types of cohesion. Procedural Cohesion Keep together several procedures that are used one after another Even if one does not necessarily provide input to the next. Weaker than sequential. Temporal Cohesion Operations that are performed during the same phase of the execution of the program are kept together, and everything else is kept outFor example, placing together the code used during system start-up or initialization Weaker than procedural cohesion. Utility Cohesion Related utilities which cannot be logically placed in other cohesive units are kept together A utility is a procedure or class that has wide applicability to many different subsystems and is designed to be reusable.For example, the java.lang.Math class. 

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 25 Design Principle 3: Reduce ( Low ) Coupling where possible Coupling occurs when there are interdependencies between one module and another When interdependencies exist, changes in one place will require changes somewhere else . A network of interdependencies makes it difficult to see at a glance how some component works.Type of coupling: (in decreasing order of avoidance!)Content, Common, Control, Stamp, Data, Routine Call, Type use, Inclusion/Import, External

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 26 Content Coupling : The Wors t of the Bad! Occurs when one component surreptitiously modifies data (or instructions!) that is/are internal to another component To reduce content coupling you should therefore encapsulate all instance variablesdeclare them private and provide get and set methods A worse form of content coupling occurs when you directly modify an instance variable from outside the object. Discuss: how easy it is to do this and how/why it has been done in the past! (especially in non-object-oriented systems)Assembler; ‘Alter’ verb in Cobol

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 27 Common Coupling Avoid where possible and practical!!! Occurs whenever you use a global variable All the components using global variables become coupled to each other Can be acceptable for creating global variables that represent system-wide default values Clearly, when a value is changed, it may be very difficult to trace the source of the change!

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 28 Control Coupling not as bad, but still pretty strong coupling! if you are able to. Occurs when one procedure calls another using a ‘flag’ or ‘command’ that explicitly controls what the second procedure does (passing a switch….) To make a change you have to change both the calling and called method; that is, to avoid the flags … The use of polymorphic operations is normally the best way to avoid control coupling  One way to reduce the control coupling could be to have a look-up tablecommands are then mapped to a method that should be called when that command is issued

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 29 Example of control coupling public routineX (String command) { if ( command.equals (" drawCircle ") { drawCircle (); } else { drawRectangle(); }}See? Flag is passed (command) whose value is used to control flow! Can be handled better through polymorphism…

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 30 Other Forms of Coupling: Stamp Coupling Data Coupling Routine-call Coupling Type Use Coupling Inclusion or import Coupling External Coupling

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 31 Design Principle 4: Keep Level of Abstraction as High as Possible Ensure that your designs allow you to hide or defer consideration of details, thus reducing complexity A good abstraction is said to provide information hiding Abstractions allow you to understand the essence of a subsystem without having to know unnecessary details Allows us to grasp the essentials! Defer the less important grunt-level items until laterWe understand stacks, queues, trees, heaps…. Sufficient!!Allows us to deal with complexity!

© Lethbridge/Laganière 2001 26 Chapter 9: Architecting and designing software 32 Design Principle 5: Increase Reusability where Possible Design for Reusability ( in other contexts) Goal is to increase reusability ; Actively reuse the work of others . (think ‘application layer’ and ‘domain layer’) Generalize your design as much as possible Layers, packages, subsystems help greatly!Some address the GUI; some general business domain; others: application specifics. Design your system to contain hooks Essentially this means to design your system where some things are provided, but can be modified. Others must be added…Simplify your design as much as possible Divide and conquer; low coupling; high cohesion… Separation of ‘concerns’ (subsystems, packages) etc.

© Lethbridge/Laganière 2001 26 Chapter 9: Architecting and designing software 33 Design Principle 6: Reuse existing designs and code where possible Design with Reuse is Complementary to Design for Reusability Actively reusing designs or code allows you to take advantage of the investment you or others have made in reusable components

© Lethbridge/Laganière 2001 26 Chapter 9: Architecting and designing software 34 Design Principle 7 Design for Flexibility Actively anticipate changes that a design may have to undergo in the future, and prepare for them  Reduce coupling and increase cohesion of design elements Create abstractions like interfaces or super classes . These actions readily supports extensions and polymorphismDo not hard-code anything Remember, programming is the realization of design!!!This is not the time… Use reusable code and make code reusable (where practical…)

© Lethbridge/Laganière 2001 26 Chapter 9: Architecting and designing software 35 Design Principle 8 : Anticipate Obsolescence Plan for changes in the technology or environment so the software will continue to run or can be easily changed  Avoid using early releases of technology NEVER a good idea to use unproven technologies … Avoid using software libraries specific to particular environments – may not be supported in the future…Avoid using undocumented features or little-used features of software libraries  Avoid using software or special hardware from companies less likely to provide long-term support Use standard languages and technologies supported by multiple vendors

© Lethbridge/Laganière 2001 26 Chapter 9: Architecting and designing software 36 Design Principle 9 : Design for Portability Have software run on as many platforms as possible Avoid use of facilities specific to one particular environment e.g. a library only available in Microsoft Windows Remember: we develop systems that will hopefully be used ‘ for a long time .’ Platforms change! But: more and more technologies are here and coming along which support portability very nicely…. Don’t want to care how many bits there are in an integer or key definitions that apply only in a special environment.Be aware of these in your design decisions / choices.Document design decisions!!

© Lethbridge/Laganière 2001 26 Chapter 9: Architecting and designing software 37 Design Principle 10 : Design for Testability Take Steps to make Testing Easier Map your tests to use-cases Map the validation of your prototype to use cases. Design each test back to demonstrate satisfaction of functional / non-functional requirements One may design a program to automatically test the softwareDiscussed more in later lecturesStudy the testing discipline and be aware of the many faces of testing…many techniques.

© Lethbridge/Laganière 2001 26 Chapter 9: Architecting and designing software 38 Design Principle 11 : Design Defensively Never trust how others will try to use a component you are designing Handle all cases where other code might attempt to use your component inappropriately “ Robustness ” – Discuss tradeoffs and criticality … Check the validity of all inputs to your componentsthe preconditionsUnfortunately, over-zealous defensive design can result in unnecessarily repetitive checkingMore on Robustness:The 80-20 ruleMany ‘absolutely necessary’ features are never used; rather, test for ‘desired outcomes!’

© Lethbridge/Laganière 2001 26 Chapter 9: Architecting and designing software 39 Techniques for Making G ood Design Decisions Using priorities and objectives to decide among alternatives Step 1 : List and describe the alternatives for the design decision . Step 2 : List the advantages and disadvantages of each alternative with respect to your objectives and priorities. Prior to starting a design effort, main objectives and ‘priorities’ should be made clear. Objectives need to be measurable (e.g. Non-functional requirements and a host of other examples…Step 3: Determine whether any of the alternatives prevents you from meeting one or more of the objectives.If none prevent us from accomplishing the objectives…If ALL prevent… Step 4: Choose the alternative that helps you to best meet your objectives. Step 5: Adjust priorities for subsequent decision making.

© Lethbridge/Laganière 2001 26 Chapter 9: Architecting and designing software 40 Example Priorities and Objectives Imagine a system has the following objectives, starting with top priority: Security : Encryption must not be breakable within 100 hours of computing time on a 400Mhz Intel processor, using known cryptanalysis techniques. Maintainability . No specific objective. CPU efficiency . Must respond to the user within one second when running on a 400MHz Intel processor. Network bandwidth efficiency : Must not require transmission of more than 8KB of data per transaction. Memory efficiency . Must not consume over 20MB of RAM. Portability . Must be able to run on Windows 7, NT 4 and ME as well as Linux

© Lethbridge/Laganière 2001 26 Chapter 9: Architecting and designing software 41 Example Evaluation of Alternatives ‘NO’ means that the objective is not met

© Lethbridge/Laganière 2001 26 Chapter 9: Architecting and designing software 42 Using Cost-Benefit A nalysis to Choose A mong A lternatives To estimate the costs , add up : Incremental cost of doing software engineering work, including on-going maintenance Incremental costs of any development technology required Incremental costs end-users and product support personnel will experience Incremental costs refers to the extra costs involved if this option is selected.“The software engineering cost is proportional to the amount of time spent by software engineers, commonly measured in person-days or person-months. Most organizations convert this into monetary terms by multiplying by a factor that accounts for the average salary plus other costs associated with employing a person, such as their office space.” To estimate the benefits, add up:Incremental software engineering time saved Incremental benefits measured in terms of either increased sales or else financial benefit to users