Final Exam Review
Contents
1. 1 Operating Database Network handling processes system access access communication levels of abstraction C Application programs Screen display facilities User account management a File system l I I gt User interface l l Kernel and swapping a Typical layers in an b Typical layers in an c Simplified view of layers application program operating system in a communication system Design Principles Divide and Conquer layers can be independently designed Increase Cohesion uses layer cohesion Reduce Coupling Lower level layers do not know about higher level ones higher level layers access lower level ones through well defined API s Increase abstraction You do not need to know how the lower level layers are implemented Increase reusability Lower level layers can often be designed generically Increase reuse Reuse layers in other applications that provide needed services Increase flexibility You can add new facilities to lower level layers or replace higher level ones Anticipate Obsolescence Isolating components makes the system obsolescent resistant Design for portability All dependent facilities can be isolated into lower layers Design for testability Layers can be tested independently Design defensively API s are natural pl2. O 1 e When a module only performs a single computation and returns a result without having side effects Layer Cohesion e All the facilities for providing or accessing a set of related services are kept together and everything else is kept out e The layers should form a hierarchy e Commonly organized into an API Application Programmer Interface Communicational Cohesion e All the modules that access or manipulate certain data are kept together i e in the same class and everything else is kept out e A class would have good communication cohesion if o All the system s facilities for manipulating and storing its data are contained in this class o Ifthe class does not do anything other than manage its data Sequential Cohesion e Procedures in which one procedure provides input to the next are kept together and everything else is kept out e You should achieve sequential cohesion only after achieving the other types of cohesion Procedural Cohesion e Keep together several procedures that are used one after the other o Even if one does not provide input to the next o Weaker than sequential cohesion Temporal Cohesion e Operations that are performed during the same phase of the program are kept together and everything else is kept out o For example placing together the code used during system start up or initialization o Weaker than procedural cohesion Utility Cohesion e When related utilities which cannot logically be placed in oth
3. times or one too few times e This is a particularly common type of defect Testing Strategy e Develop tests in which you verify that the program o Computes the correct numerical answer o Performs the correct number of iterations Operator Precedence Errors Defect e An operator precedence error occurs when a programmer omits needed parentheses or puts parentheses in the wrong place e Operator precedence errors are often extremely obvious o But can occasionally lie hidden until special conditions arise e E g Ifx y z should be x y z this would be hidden if z was normally zero Testing Strategy e In software that computes formulae run tests that anticipate such defects Use of Inappropriate Standard Algorithms Defect e An inappropriate standard algorithm is one that is unnecessarily inefficient or has some other property that is widely recognized as being bad Testing Strategies e The tester has to know properties of algorithms and design tests that will determine whether any undesirable algorithms have been implemented Examples e An inefficient sort algorithm o The most classical choice bad choice of algorithm is sorting using a so called bubble sort e An inefficient search algorithm o Ensure that the search time does not increase unacceptably as the list gets longer o Check that the position of the searched item does not have a noticeable impact on search time A non stable sort A
4. Occurs when one component imports a package o Asin Java e Or when one component includes another o Asin C External Coupling e When a module has a dependency on such things as the operating system shared libraries or the hardware o Keep the Level of Abstraction as High as Possible Ensure that your designs allow you to hide or defer consideration of details thus reducing complexity e A good abstraction is said to provide information hiding Classes are abstractions that contain procedural abstractions e Increased by defining all variables as private The fewer public methods in a class the better the abstraction Superclasses and interfaces increase the level of abstraction Attributes and associations are also abstractions Methods are procedural abstractions o Better abstractions are achieved by giving methods fewer parameters o Increase Reusability Where Possible Design the various aspects of your system so that they can be used again in other contexts o Reuse Existing Designs and Code Where Possible Design with reuse is complementary to design for reusability o Design for Flexibility Actively anticipate changes that a design may have to undergo in the future and prepare for them e Reduce coupling increase cohesion e Create abstractions e Do not hard code anything e Leave all options open o Do not restrict the options of people who have to modify the system later e Use reusable code and make code reusable o Anticipate Obsol
5. Software Engineering Final Exam Review Note This review supplements the previous reviews since the final will be cumulative Chapter 9 Design A problem solving process whose objective is to find and describe a way o Implement the system s functional requirements o While respecting the constraints imposed by the non functional requirements Including the budget o And while adhering to the general principles of good quality Design Issues o Sub problems of the overall design problem o Solutions design options To make decisions the software engineer uses knowledge of Requirements Design so far Technology Software design principles o What has worked well in the past O O O 0 Component Any piece of software or hardware that has a clear role Module A component that is defined at the programming language level System A logical entity having a set of definable responsibilities or objectives and consisting of hardware software or both Top down Design o First design the very high level structure of the system o Then gradually work down to detailed decisions about low level constructs o Finally arrive at detailed decisions such as The format of particular data items The individual algorithms that will be used Bottom up Design o Make decisions about reusable low level entities o Then decide how these will be put together to create high level constructs A mix of top down and bottom up approaches are normally used Different A
6. aces to build in rigorous assertion checking o Client Server and other Distributed Architectural Patterns At least one component has the role of server waiting for and then handling connections There is at least one component that has the role of client initiating connections in order to obtain some service Extension Peer to Peer pattern A system composed of various software components that are distributed over several hosts Example exchange messages Client 3 exchange messages look up addresses Client2 5 Design Principles Divide and Conquer Client and Server systems Increase Cohesion The server can provide a cohesive service to clients Reduce Coupling One communication channel exchanging simple messages Increase Abstraction Separate distributed components are often good abstractions Increase Reuse Possible to find suitable frameworks to build good distributed systems Design for Flexibility Easily reconfigured Design for Portability Write clients for new platforms without having to port the server Design for Testability Test clients and servers independently Design Defensively You can put rigorous checks into the message handling code o Broker Architectural Pattern Transparently distribute aspects of the software system to different nodes Example Remote Object Design Principles Divide and Conquer Remote objects c
7. an be independently designed Increase Reusability Possible to design remote objects so that other systems can use them too Increase Reuse You may be able to reuse remote objects that others have created Design for Flexibility Brokers can be updated as required or the proxy can communicate with a different remote object Design for Portability Can write clients for new platforms while still accessing brokers and remote objects on other platforms Design Defensively You can provide careful assertion checking in the remote objects o Transaction Processing Architectural Pattern A process reads a series of inputs one by one Each input describes a transaction There is a transaction dispatcher component that decides what to do with each transaction This dispatches a procedure call or message to one of a series of components that will handle the transaction Example Handler for a flight reservation transaction a Transaction __ _ _ ausactions Transaction input dispatcher Handler for 3 flight cancellation transaction Design Principles Divide and Conquer Transaction handlers are suitable system divisions Increase Cohesion Transaction handlers are naturally cohesive units Reduce Coupling Separating the dispatcher from the handler tends to reduce coupling Design for Flexibility You can readily add new transaction handlers Design Defensively You can add assertion c
8. arge Systems o Big bang testing versus integration testing In big bang testing you take the entire system and test it as a unit A better strategy in most cases is incremental testing e You test each individual subsystem in isolation e Continue testing as you add more and more subsystems to the final product o Top down Testing Start by testing just the user interface The underlying functionality are simulated by stubs Then you work downwards integrating lower and lower layers The big drawback to top down testing is the cost of writing the stubs o Bottom up Testing Start by testing the very lowest levels of the software You need drivers to test the lower layers of software Drivers in bottom up testing have a similar role to stubs in top down testing and are time consuming to write o Sandwich Testing A hybrid between bottom up and top down testing Test the user interface in isolation using stubs Test the very lowest level functions using drivers When the complete system is integrated only the middle layer remains on which to perform the final set of tests e The Test Fix Test Cycle o When a failure occurs during testing Failure is reported into a failure tracking system Screened assigned a priority Low level priorities are often put in a known bugs list and released with the software to be fixed later Someone is assigned to investigate the failure That person tracks down the defect and fixes it Final
9. e individual processes Design Defensively You rigorously check the inputs of each component or you can use design by contract o The Model View Controller MVC Architectural Pattern An architectural pattern used to help separate the user interface layer from other parts of the system Model Underlying classes whose instances are to be viewed and manipulated View Contains objects used to render the appearance of the data from the model in the user interface Controller Contains the objects that control and handle the user s interaction with the view and the model The Observable design pattern is normally used to separate the model from the view Example viewed by actor View _ create and update notify about changes d 7 J 7 modify P ria Modei E Divide and Conquer The three components can be somewhat independently designed Increase Cohesion The components have stronger layer cohesion than if the view and controller were together in a single UI layer Reduce Coupling The communication channels between the three components are minimal Increase Reuse The view and the controller normally make extensive use of reusable components for various kinds of UI controls Design for Flexibility It is usually quite easy to change the UI by changing the view the controller or both Design for Testability You can test the application separate fr
10. er cohesive units are kept together Reduce Coupling Where Possible Coupling occurs when there are interdependencies between one module and another Content Coupling e Occurs when one component surreptitiously modifies data that is internal to another component e Solution Encapsulate all instance variables declare them as private Common Coupling e Occurs whenever you use a global variable e Solution Use the Singleton pattern where applicable or simply do not use global variables Control Coupling e Occurs when one procedure calls another using a flag or command that explicitly controls what the second procedure does e Solution Use polymorphic methods or a lookup table Stamp Coupling e Occurs whenever one of your application classes is declared as the type of a method argument e Solutions Use an interface as the argument type or pass simple variables atomic types Data Coupling e Occurs whenever the types of method arguments are either primitive or else simple library classes e Solution Do not give methods unnecessary arguments e There is a trade off between data coupling and stamp coupling o Increasing one often decreases the other Routine Call Coupling e Occurs when one routine or method in an object oriented system calls another e Routine call coupling is always present in any system Type Use Coupling e Occurs when a module uses a data type defined in another module Inclusion or Import Coupling e
11. escence Plan for changes in technology or environment so the software will continue to run or can be easily changed o Design for Portability Have the software run on as many platforms as possible o Design for Testability Take steps to make testing easier o Design Defensively Never trust how others will try to use a component you are designing Design by Contract e A technique that allows you to design defensively in a systematic way e Key idea o Each method has an explicit contract with its callers o Each contract has Preconditions Postconditions Invariants e Techniques for Making Good Design Decisions o Using priorities and objectives to decide among alternatives List and describe the alternatives for the design decision List the advantages and disadvantages of each alternative with respect to objectives and priorities Determine whether any of the alternatives prevents you from meeting one or more of the objectives Choose the alternative that helps you to best meet your objectives Adjust priorities for subsequent decision making e Software Architecture o Software architecture is the process of designing the global organization of a software system including Dividing software into subsystems Deciding how these will interact Determining their interfaces o 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 the sy
12. ewing them Implies that once the product is finished everything else is maintenance The Phased Release Model Specification Requirements gathering and definition Implementation Planning 1 Integration and deployment Implementation Integration and deployment o It introduces the notion of incremental development After requirements gathering and planning the project should be broken up into separate subprojects or phases Each phase can be released to customers when ready However continues to suggest that all requirements be finalized at the start of development The Spiral Model Release 2 Release Review Analysis of risk Prototype N Requirements Integration and deployment Specification Implementation _ Design o It explicitly embraces prototyping and an iterative approach to software development Start by developing a small prototype Followed by a mini waterfall process primarily to gather requirements Then the first prototype is reviewed In subsequent loops the project team performs further requirements design implementation and review First thing to do before embarking on a new loop risk analysis Maintenance is simply a type of on going development The Evolutionary Model Development activity Time o It shows software development as a series of hills each representing a separate loop of the spiral Shows that loops or releases tend to overlap each othe
13. gram intensively in such a way that it uses many resources relinquishes them and then uses them again repeatedly o Defects in the process of recovering from a crash Defects e Any system will undergo a sudden failure if its hardware fails or if its power is turned off e Itis a defect if the system is left in an unstable state and hence is unable to fully recover e It is also a defect if a system does not correctly deal with the crashes of related systems Testing Strategies e Kill a program at various times during execution e Try turning the power off however operating systems themselves are often intolerant of doing that e Documentation Defects o Defect The software has a defect if the user manual reference manual or on line help e Gives incorrect information e Fails to give information relevant to a problem o Testing Strategy Examine all the end user documentation making sure it is correct Work through the use cases making sure that each of them is adequately explained to the user e Writing Formal Test Cases and Test Plans o A test case is an explicit set of instructions designed to detect a particular class of defect in a software system o A test plan is a document that contains a complete set of test cases for a system e Along with other information about the testing process The test plan is one of the standard forms of documentation The test plan should be written long before testing starts e Strategies for Testing L
14. hecking in each transaction handler and or in the dispatcher o The Pipe and Filter Architectural Pattern A stream of data in a relatively simple format is passed through a series of processes Each process transforms the data in some way The data is constantly fed into the pipeline The processes work concurrently The architecture is very flexible Example encoders for l Oy microphones microphone lt sou input Oy ound distant mucrophone gt ambient decoders noise lt for speaker lt decompress j lt receive output y cancel l E echo near source remove equalize cancel l w ee a 3 hija gt non voice gt dynamic gt compress gt transmit frequencies range i i l TCP IP Transmission I I encoder for l Design Principles Divide and Conquer Separate processes can be independently designed Increase Cohesion The processes have functional cohesion Reduce Coupling The processes have only one input and one output Increase Abstraction Pipeline components are often good abstractions Increase Reusability The processes can be used in many different contexts Increase Reuse It is often possible to find reusable components to insert into a pipeline Design for Flexibility There are several ways in which the system is flexible Design for Testability It is normally easy to test th
15. ls o Software process models are general approaches for organizing a project into activities The models should be seen as aids to thinking not rigid prescriptions of the way to do things Each project ends up with its own unique plan The Opportunistic Approach Erci Modify Think of Idea Until Prototype Lor yP Satisfied Improvement Is what occurs when an organization does not follow good engineering practices It does not stress the importance of working out requirements and a design first The design of software deteriorates if it is not well designed No plans no aim No recognition of a need for systematic testing The Waterfall Model Integration and deployment Maintenance o The classic way of looking at S E that accounts for the importance of requirements design and quality assurance The model suggests that software engineers should work in a series of stages Before the complete each stage they should complete quality assurance verification and validation The waterfall model also recognizes to a limited extent that you sometimes have to step back to earlier stages o Limitations of the Waterfall Model Suggests you should complete a stage before moving on to the next e Doesn t account for requirements changing e Customers cannot use anything until the entire system is complete Makes no allowances for prototyping Implies you can get the requirements right by simply writing them down and revi
16. ly a new version of the system is created ready to be tested again e 6 The Ripple Effect o There is a high probability that the efforts to remove the defects may have actually added new defects e Regression Testing o It tends to be far too expensive to re run every single test case every time a change is made to the software o Hence only a subset of the previously successful test cases is actually re run o This is called regression testing o The law of the conservation of bugs The number of bugs remaining in a large system is proportional to the number of bugs already fixed e Inspections o An inspection is an activity in which one or more people systematically Examine source code or documentation looking for defects Normally inspection involves a meeting e Although participants can also inspect alone at their desks Chapter 11 e What is project management o Project management encompasses all the activities needed to plan and execute a project Deciding what needs to be done Estimating costs Ensuring there are suitable people to undertake the project Defining responsibilities Scheduling Making arrangements for work Directing Being a technical leader Reviewing and approving decisions made by others Building morale and supporting staff Monitoring and controlling Coordinating the work with managers of other projects Reporting Continually striving to improve the process e Software Process Mode
17. n intermediate and the last iteration o Not Terminating a Loop or Recursion Defect e A loop or recursion does not always terminate 1 e it is infinite Testing Strategies e Analyze what causes a repetitive action to be stopped e Run test cases that you anticipate might not be handled correctly o Not Setting Up the Correct Preconditions for an Algorithm Defect e Preconditions state what must be true before the algorithm should be executed e A defect would exist if the program proceeds to do its work even when the preconditions are not satisfied Testing Strategy e Run test cases in which each precondition is not satisfied Not Handling Null Conditions Defect e A null condition is a situation where there are normally one or more data items to process but sometimes there are none e Jtisa defect when a program behaves abnormally when a null condition is encountered Testing Strategy e Brainstorm to determine unusual conditions and run appropriate tests Not Handling Singleton or Non singleton Conditions Defect e A singleton condition occurs when there is normally more than one of something but sometimes there is only one e A non singleton is the inverse e Defects occur when the unusual case is not properly handled Testing Strategy e Brainstorm to determine unusual conditions and run appropriate tests Off by one Errors Defect e A program inappropriately adds or subtracts one e Or loops one too many
18. om the UI Design Principles Chapter 10 e Basic Definitions o Failure Unacceptable behavior exhibited by a system Frequency of failures measures the reliability Design goal achieve low failure rate thus ensuring high reliability A failure can result from a violation of an explicit or implicit requirement Defect A flaw in any aspect of the system that contributes or may potentially contribute to the occurrence of one or more failures Error A slip up or inappropriate decision by a software developer that leads to the introduction of a defect e Effective and Efficient Testing O O To test effectively you must use a strategy that uncovers as many defects as possible To test efficiently you must find the largest possible number of defects using the fewest possible tests e Black box Testing o Testers provide the system with inputs and observe the outputs They can see none of e The source code e The internal data e lt Any of the design documentation describing the system s internals O e Glass box Testing o Also called white box or structural testing o Testers have access to the system design They can e Examine the design documents e View the code e Observe at run time the steps taken by algorithms and their internal data Individual programmers often informally employ glass box testing to verify their own code e Equivalence Classes o Inappropriate to test by brute force using every po
19. point value then the result will very rarely be computed exactly To test quality you should always test if it is within a small range around that value Testing Strategies Standard boundary testing should detect this type of defect e Defects in Timing and Co ordination o Deadlock and livelock Defects A deadlock is a situation where two or more threads are stopped waiting for each other to do something o The system is hung Livelock is similar but now the system can do some computations but can never get out of some states Testing Strategies Deadlocks and livelocks occur due to unusual combinations of conditions that are hard to anticipate or reproduce e Jtis often most effectual to use inspection to detect such defects rather than testing alone e However when testing o Vary the time consumption of different threads o Runa large number of threads concurrently o Deliberately deny resources to one or more threads o Critical races Defects e One thread experiences a failure because another thread interferes with the normal sequence of events Testing Strategies e It is particularly hard to test for critical races using black box testing alone e One possible although invasive strategy is to deliberately slow down one of the threads e Use inspection o Semaphore and synchronization Critical races can be prevented by locking data so that they cannot be accessed by other threads when they are not ready e One
20. r Makes it clear that development work tends to reach a peak at around the time of the deadline for completion Shows that each prototype or release can take e Different amounts of time to deliver e Differing amounts of effort The Concurrent Engineering Model Workon O Weakon component or component or component or layer A layer B layer X Integrate o It explicitly accounts for the divide and conquer principle e Choosing a Process Model o From the Waterfall Model Incorporate the notion of stages o From the Phased Release Model Incorporate the notion of doing some high level analysis and then dividing the project into releases o From the Spiral Model Incorporate prototyping and risk analysis o From the Evolutionary Model Incorporate the notion of varying amounts of time and work with overlapping releases o From the Concurrent Engineering Model Incorporate the notion of breaking the system down into components and developing them in parallel
21. search or sot that is case sensitive when it should not be or vice versa e Defects in Numerical Algorithms o Not using enough bits or digits Defect A system does not use variables capable of representing the largest values that could be stored When the capacity is exceeded an unexpected exception 1s thrown or the data stored is incorrect Testing Strategies Test using very large numbers to ensure the system has a wide enough margin of error o Not using enough places after the decimal point or significant figures Defects A floating point value might not have the capacity to store enough significant figures A fixed point value might not store enough places after the decimal point A typical manifestation is excessive rounding Testing Strategies Perform calculations that involve many significant figures and large differences in magnitude Verify that the calculated results are correct o Ordering operations poorly so errors build up Defect A large number does not store enough significant figures to be able to accurately represent the result Testing Strategies Make sure the program works with inputs that have large positive and negative exponents Have the program work with numbers that vary a lot in magnitude o Make sure computations are still accurately performed o Assuming a floating point value will be exactly equal to some other value Defect If you perform an arithmetic calculation on a floating
22. spects of Design o Architecture Design The division into subsystems and components o Class Design The various features of classes o User Interface Design o Algorithm Design The design of computational mechanisms o Protocol Design The design of communications protocol Principles Leading to Good Design o Goals Increase profit by reducing cost and increasing revenue Ensuring that we actually conform with the requirements Accelerating development Increasing RUMER qualities Design Principles o Divide and Conquer O O Trying to deal with something big all at once is normally much harder than dealing with a series of smaller things e Separate people can work on each part e An individual software engineer can specialize e Fach individual component is smaller and therefore easier to understand e Parts can be replaced or changed without having to replace or extensively change other parts Ways of Dividing a Software System e Distributed system clients and servers e System can be divided up into subsystems e Subsystem can be divided up into one or more packages e A package is divided up into classes e A class is divided up into methods Increase Cohesion Where Possible A subsystem or module has high cohesion if it keeps together things that are related to each other and keeps out other things Functional Cohesion e This is achieved when all code that computes a particular result is kept together and everything else is kept out
23. ssible input value o You should divide the possible inputs into groups which you believe will be treated similarly by all algorithms Such groups are called equivalence classes o Examples Valid input number 1 12 e Equivalence Classes are inf 0 1 12 13 inf Valid input is one of ten strings representing a type of fuel e Equivalence Classes are o 10 classes one for each string o A class representing all other strings e Detecting Specific Categories of Defects o A tester must try to uncover any defects the other software engineers might have introduced This means designing tests that explicitly try to catch a range of specific types of defects that commonly occur e Defects in Ordinary Algorithms o Incorrect Logical Conditions Defect e The logical conditions that govern looping and if then else statements are wrongfully formatted Testing Strategy e Use equivalence class and boundary testing e Consider as an input each variable used in a rule or logical condition o Performing a Calculation in the Wrong Part of a Control Construct Defect e The program performs an action when it should not or does not perform an action when it should e Typically caused by inappropriately excluding or including the action from a loop or an if construct Testing Strategy e Design tests that execute each loop zero times exactly once and more than once e Anything that could happen while looping is made to occur on the first a
24. stem in isolation To prepare for extension of the system To facilitate reuse and reusability o Contents of a good architectural model A system s architecture will often be expressed in terms of several different views e The logical breakdown into subsystems e The interfaces among the subsystems The dynamics of the interaction among components at runtime The data that will be shared among the subsystems The components that will exist at runtime and the machines or devices on which they will be located o Design stable architecture To ensure the maintainability and reliability of a system an architectural model must be designed to be stable o Developing an architectural model Start by sketching an outline of the architecture Architecture Patterns Based on the principle requirements and use cases Determine the main components that will be needed Choose among the various architectural patterns Refine the architecture Consider each use case and adjust the architecture to make it realizable Mature the architecture o The notion of patterns can be applied to software architecture o The Multi Layer Architectural Pattern Ina layered system each layer communicates only with the layer immediately below it Each layer has a well defined interface used by the layer immediately above o Lower layers Services A complex system can be built by superimposing layers at increasing Example Application logic
25. widely used locking mechanism is called a semaphore e In Java the synchronized keyword can be used o It ensures that no other thread can access an object until the synchronized method terminates e Defects in Handling Stress and Unusual Situations o Insufficient throughput or response time on minimal configurations Defect e Onamuinimal configuration the system s throughput or response time fails to meet requirements Testing Strategy e Perform testing using minimally configured platforms o Incompatible with specific configurations of hardware or software Defect e The system fails if it is run using particular configurations of hardware operating systems and external libraries Testing Strategy e Extensively execute the system with all possible configurations that might be encountered by users o Defects in handling peak loads or missing resources Defects e The system does not gracefully handle resource shortage e Resources that might be in short supply include o Memory disk space or network bandwidth permission e The program being tested should report the problem in a way the user will understand Testing Strategies e Devise a method of denying resources e Run avery large number of copies of the program being tested all at the same time o Inappropriate management of resources Defect e A program uses certain resources but does not make them available when it no longer needs them Testing Strategy e Run the pro
Download Pdf Manuals
Related Search