Design Fundamentals - Computer Science

1 Design FundamentalsSoftware engineering I SE361 What is software Design ? The purpose of software Design is To produce a workable (implementable) solution to agiven problem. David Budgen in software Design : An Introduction Design is a problem-solving process whose objective is tofind and describe a way: To implement the system s functional While respecting the constraints imposed by the non-functional including the budget And while adhering to general principles of good qualitySoftware engineering I SE361 Design Concepts The Design should be based on requirements specification. The Design should be documented (so that it supportsimplementation, verification, and maintenance.) The Design should use abstraction (to reduce complexity andto hide unnecessary detail.) The Design should be modular (to support abstraction,verification, maintenance, and division of labor.)

2 The Design should be assessed for quality as it is beingcreated, not after the fact. Design should produce modules that exhibit independentfunctional characteristics. Design should support verification and engineering I SE361 Design Elements A system is a logical entity, having a set of definableresponsibilities or objectives, and consisting of hardware, software or both. A subsystem is a system that is part of a larger system, andwhich has a definite interface. A component is any piece of software or hardware that has aclear role. A component can be isolated, allowing you to replace itwith a different component that has equivalentfunctionality. A module is a component that is defined at the programminglanguage level For example, methods, classes and packages are modulesin engineering I SE361 UML diagram of system partsComponentnameModuledefined at programmming language levelSystemnamehas * * * * * *Frameworkspecifies interfaceSoftware engineering I SE361 Different Design Aspects Architecture Design : The division into subsystems and components, How these will be connected.

3 How they will interact. Their interfaces. Class Design : The various features of classes. User interface Design Algorithm Design : The Design of computational mechanisms. Protocol Design : The Design of communications engineering I SE361 Design Goals Overall goals of good Design : Increasing profit by reducing cost and increasingrevenue Ensuring that we actually conform with therequirements Accelerating development Increasing qualities such as Usability Efficiency Reliability Maintainability ReusabilitySoftware engineering I SE361 Design Principle 1:Divide and Conquer Trying to deal with something big all at once is normallymuch harder than dealing with a series of smaller things Separate people can work on each part. An individual software engineer can specialize. Each individual component is smaller, and thereforeeasier to understand.

4 Parts can be replaced or changed without having toreplace or extensively change other engineering I SE361 Design Principle 2:Increase Cohesion (where possible) A subsystem or module has high cohesion if it keepstogether things that are related to each other, and keeps outother things This makes the system as a whole easier to understandand change Type of cohesion: Functional Layer Communicational Sequential Procedural Temporal UtilitySoftware engineering I SE361 Design Principle 3:Reduce Coupling, where possible Coupling occurs when there are interdependencies between onemodule and another When interdependencies exist, changes in one place will requirechanges somewhere else. A network of interdependencies makes it hard to see at a glancehow some component engineering I SE361 Types of Coupling Content Common Control Stamp Data Routine Call Type use Inclusion/Import ExternalSoftware engineering I SE361 Design Principle 4: Keep the level ofabstraction as high as possible Ensure that your designs allow you to hide or deferconsideration of details, thus reducing complexity A good abstraction is said to provide informationhiding Abstractions allow you to understand the essence of asubsystem without having to know unnecessary detailsSoftware engineering I SE361 Abstraction and Classes Classes are data abstractions that contain proceduralabstractions Abstraction is increased by defining all variables asprivate.

5 The fewer public methods in a class, the better theabstraction Superclasses and interfaces increase the level ofabstraction Attributes and associations are also data abstractions. Methods are procedural abstractions Better abstractions are achieved by giving methods fewerparametersSoftware engineering I SE361 Design Principle 5: Increasereusability where possible Design the various aspects of your system so that they canbe used again in other contexts Generalize your Design as much as possible Follow the preceding three Design principles Design your system to contain hooks (which allow thesystem to be easily extended) Simplify your Design as much as possibleSoftware engineering I SE361 Design Principle 6: Reuse existingdesigns and code where possible Design with reuse is complementary to Design forreusability Actively reusing designs or code allows you to takeadvantage of the investment you or others have made inreusable componentsSoftware engineering I SE361 Design Principle 7.

6 Design forflexibility Actively anticipate changes that a Design may have toundergo in the future, and prepare for them Reduce coupling and increase cohesion Create abstractions Do not hard-code anything Leave all options open Do not restrict the options of people who have to modify thesystem later Use reusable code and make code reusableSoftware engineering I SE361 Design Principle 8: Anticipateobsolescence Plan for changes in the technology or environment so thesoftware will continue to run or can be easily changed Avoid using early releases of technology Avoid using software libraries that are specific toparticular environments Avoid using undocumented features or little-usedfeatures of software libraries Avoid using software or special hardware fromcompanies that are less likely to provide long-termsupport Use standard languages and technologies that aresupported by multiple vendorsSoftware engineering I SE361 Design Principle 9: Design forPortability Have the software run on as many platforms as possible Avoid the use of facilities that are specific to oneparticular environment a library only available in Microsoft WindowsSoftware engineering I SE361 Design Principle 10.

7 Design forTestability Take steps to make testing easier Design a program to automatically test the software Discussed more in Chapter 10 Ensure that all the functionality of the code can bydriven by an external program, bypassing agraphical user interface In Java, you can create a main() method in each classin order to exercise the other methodsSoftware engineering I SE361 Design Principle 10: Designdefensively Never trust how others will try to use a componentyou are designing Handle all cases where other code might attempt touse your component inappropriately. Check that all of the inputs to your component engineering I SE361 Design by contract A technique that allows you to Design defensively in anefficient and systematic way Key idea each method has an explicit contract with its callers The contract has a set of assertions that state: What preconditions the called method requires to be truewhen it starts executing What postconditions the called method agrees to ensureare true when it finishes executing What invariants the called method agrees will not changeas it executesSoftware engineering I SE361 Techniques for making good designdecisions Using priorities and objectives to decide among alternatives Step 1: List and describe the alternatives for the designdecision.

8 Step 2: List the advantages and disadvantages of eachalternative with respect to your objectives and priorities. Step 3: Determine whether any of the alternatives preventsyou from meeting one or more of the objectives. Step 4: Choose the alternative that helps you to best meet yourobjectives. Step 5: Adjust priorities for subsequent decision engineering I SE361 software Architecture software architecture is process of designing the globalorganization of a software system, including: Dividing software into subsystems. Deciding how these will interact. Determining their interfaces. The architecture is the core of the Design , so all softwareengineers need to understand it. The architecture will often constrain the overall efficiency,reusability and maintainability of the engineering I SE361 The importance of softwarearchitecture Why you need to develop an architectural model: To enable everyone to better understand the system To allow people to work on individual pieces of thesystem in isolation To prepare for extension of the system To facilitate reuse and reusabilitySoftware engineering I SE361 Developing an architectural model Start by sketching an outline of the architecture Based on the principal requirements and use cases Determine the main components that will be needed Choose among the various architectural patterns software engineering I SE361 Architectural Patterns The notion of patterns can be applied to software architecture.

9 These are called architectural patterns or architectural styles. Each allows you to Design flexible systems using components The components are as independent of each other as possible. Common Architectural Patterns Multi-Layer Pattern Client-Server Pattern Broker Pattern Transaction-Processing Pattern Pipe-an-Filter Pattern Model-View-Controller (MVC) PatternSoftware engineering I SE361 Multi-Layer Pattern In a layered system, each layer communicates only with the layerimmediately below it. Each layer has a well-defined interface used by the layerimmediately above. The higher layer sees the lower layer as a set of services. A complex system can be built by superposing layers at increasinglevels of abstraction. It is important to have a separate layer for the UI. Layers immediately below the UI layer provide the applicationfunctions determined by the use-cases.

10 Bottom layers provide general services. network communication, database accessSoftware engineering I SE361 Example of multi-layer systemsScreen display facilitiesUser account managementFile systemKernel (handling processes and swapping)Application programsUser interfaceApplication logicDatabase accessNetwork communicationTransmitting and receivingDealing with packetsDealing with connectionsDealing with application protocolsa) Typical layers in an application programb) Typical layers in an operating systemc) Simplified view of layers in a communication systemOperating system accessSoftware engineering I SE361 The multi-layer architecture anddesign principles1. Divide and conquer: The layers can be independently Increase cohesion: Well-designed layers have layer Reduce coupling: Well-designed lower layers do not know aboutthe higher layers and the only connection between layers is throughthe Increase abstraction: you do not need to know the details of howthe lower layers are Increase reusability: The lower layers can often be engineering I SE361 The multi-layer architecture anddesign principles6.