CHAPTER 5

1. Object-Oriented and Classical Software EngineeringEighth Edition, WCB/McGraw-Hill, 2011Stephen R. Schach

2. CHAPTER 5 THE TOOLS OF THE TRADE

3. Overview • Stepwise refinement • Cost–benefit analysis • Divide-and-conquer • Separation of concerns • Software metrics • CASE • Taxonomy of CASE • Scope of CASE • Software versions • Configuration control • Build tools • Productivity gains with CASE technology

4. 1 Stepwise Refinement • A basic principle underlying many software engineering techniques • “Postpone decisions as to details as late as possible to be able to concentrate on the important issues” • Miller’s law • A human being can concentrate on 7 ± 2 items at a time • Bryce's Law • You eat elephants one spoonful at a time.

5. Example • Steps used by an architect designing a building • Develop artist rendering (to consider viability). • Design foundation and superstructure. • Design Floor plans. • Design electrical and plumbing diagrams. • The architect knows precisely what the building will look like and how it will work.

6. Stepwise Refinement in programming • The top level might be the function main(). • The SoftwareEngineer decides that main needs to call foo() and bar(), so she writes the function main() to call foo() and bar() but leaves foo() and bar() stubbed out with printf's. • She then runs her UnitTests and confirms that foo() and bar() are called correctly i.e. we get printfs coming out where expected, so main() works. • She then implements foo() which is straightforward, and runs the UnitTests once more to verify that both main() and foo() operate together correctly. • She then goes back to look at bar() but realizes that bar() needs another lower level function, baz() to work. • So, she implements bar() to call baz() but again just leaves baz() stubbed out. • Once more the UnitTests are run to confirm that the software works correctly. • The final stage is then to implement baz() and finished checking the software with the UnitTests. Source:http://c2.com/cgi/wiki?StepwiseRefinement

7. 1.1 Stepwise Refinement Mini Case Study • Design a product to update a sequential master file containing name and address data for the monthly magazine True Life Software Disasters • Three types of transactions • Type 1: INSERT (a new subscriber into the master file) • Type 2: MODIFY (an existing subscriber record) • Type 3: DELETE (an existing subscriber record) • Transactions are sorted into alphabetical order, and by transaction code within alphabetical order

8. Typical File of Input Transactions Figure 5.1

9. Decompose Process • No further refinement is possible Figure 5.2

10. First Refinement Figure 5.3

11. Stepwise Refinement Case Study (contd) • Assumption • We can produce a record when PROCESS requires it • Separate INPUT and OUTPUT, concentrate on PROCESS

12. Stepwise Refinement Case Study (contd) • What is this PROCESS? • Example: • Type 1: INSERT • Type 2: MODIFY • Type 3: DELETE

13. Stepwise Refinement Case Study (contd) • More formally:

14. Second Refinement Figure 5.6

15. Third Refinement • This design has a major fault • “Modify JONES” followed by “Delete JONES” is incorrectly handled Figure 5.7

16. Stepwise Refinement Case Study (contd) • After the third refinement has been corrected • Details like opening and closing files have been ignored up to now • Fix these after the logic of the design is complete • The stage at which an item is handled is vital • Opening and closing files is • Ignored in early steps, but • Essential later

17. Appraisal of Stepwise Refinement • A basic principle used in • Every workflow • Every representation • The power of stepwise refinement • The software engineer can concentrate on the relevant aspects • Warning • Miller’s Law is a fundamental restriction on the mental powers of human beings

18. 2 Cost–Benefit Analysis • Compare costs and future benefits • Estimate costs • Estimate benefits • State all assumptions explicitly

19. Cost–Benefit Analysis (contd) • Example

20. Cost–Benefit Analysis (contd) • Tangible costs/benefits are easy to measure • Make assumptions to estimate intangible costs/benefits • Improving the assumptions will improve the estimates

21. 3 Divide-and-Conquer • Solve a large, hard problem by breaking up into smaller subproblems that hopefully will be easier to solve • Divide-and-conquer is used in the Unified Process to handle a large, complex system • Analysis workflow • Partition the software product into analysis packages • Design workflow • Break up the upcoming implementation workflow into manageable pieces, termed subsystems

22. Divide-and-Conquer (contd) • A problem with divide-and-conquer • The approach does not tell us how to break up a software product into appropriate smaller components

23. 4 Separation of Concerns • The process of breaking a software product into components with minimal overlap of functionality • Minimizes regression faults • Promotes reuse • Separation of concerns underlies much of software engineering

24. Separation of Concerns (contd) • Instances include: • Modularization with maximum interaction within each module (“high cohesion”) • Modularization with minimum interaction between modules (“low coupling”) • Information hiding (or physical independence) • Encapsulation (or conceptual independence) • Three-tier architecture • Model-view-controller (MVC) architecture pattern,

25. 5 Software Metrics • To detect problems early, it is essential to measure • Examples: • LOC per month • Defects per 1000 lines of code

26. Different Types of Metrics • Product metrics • Examples: • Size of product • Reliability of product • Process metrics • Example: • Efficiency of fault detection during development • Metrics specific to a given workflow • Example: • Number of defects detected per hour in specification reviews

27. The Five Basic Metrics • Size • In lines of code, or better • Cost • In dollars • Duration • In months • Effort • In person months • Quality • Number of faults detected

28. 6 CASE (Computer-Aided Software Engineering) • Scope of CASE • CASE can support the entire life-cycle • The computer assists with drudge work • It manages all the details • Prerequisites to tool use • Need a collection of useful tools that help in every step of building a product • Need an organized layout that enables tools to be found quickly and used efficiently • Need a skilled craftsperson who understands how to use the tools effectively

29. Upper CASE requirements specification planning design Lower CASE implementation integration maintenance CASE Tools

30. CASE Building Blocks - 1 • CASE tools • Integration framework • specialized programs allowing CASE tools to communicate with one another • Portability services • allow CASE tools and their integration framework to migrate across different operating systems and hardware platforms without significant adaptive maintenance

31. CASE Building Blocks - 2 • Operating system • database and object management services • Hardware platform • Environmental architecture • hardware and system support

32. CASE Tool Taxonomy - 1 • Business process engineering tools • represent business data objects, their relationships, and flow of the data objects between company business areas • Process modeling and management tools • represent key elements of processes and provide links to other tools that provide support to defined process activities • Project planning tools • used for cost and effort estimation, and project scheduling

33. CASE Tool Taxonomy - 2 • Risk analysis tools • help project managers build risk tables by providing detailed guidance in the identification and analysis of risks • Requirements tracing tools • provide systematic database-like approach to tracking requirement status beginning with specification

34. CASE Tool Taxonomy - 3 • Metrics and management tools • management oriented tools capture project specific metrics that provide an overall indication of productivity or quality, technically oriented metrics determine metrics that provide greater insight into the quality of design or code • Documentation tools • provide opportunities for improved productivity by reducing the amount of time needed to produce work products

35. CASE Tool Taxonomy - 4 • System software tools • network system software, object management services, distributed component support, and communications software • Quality assurance tools • metrics tools that audit source code to determine compliance with language standards or tools that extract metrics to project the quality of software being built

36. CASE Tool Taxonomy - 5 • Database management tools • RDMS and OODMS serve as the foundation for the establishment of the CASE repository • Software configuration management tools • uses the CASE repository to assist with all SCM tasks (identification, version control, change control, auditing, status accounting) • Analysis and design tools • enable the software engineer to create analysis and design models of the system to be built, perform consistency checking between models

37. CASE Tool Taxonomy - 6 • PRO/SIM tools • prototyping and simulation tools provide software engineers with ability to predict the behavior of real-time systems before they are built and the creation of interface mockups for customer review • Interface design and development tools • toolkits of interface components, often part environment with a GUI to allow rapid prototyping of user interface designs

38. CASE Tool Taxonomy - 7 • Prototyping tools • enable rapid definition of screen layouts, data design, and report generation • Programming tools • compilers, editors, debuggers, OO programming environments, fourth generation languages, graphical programming environments, applications generators, and database query generators • Web development tools • assist with the generation of web page text, graphics, forms, scripts, applets, etc.

39. CASE Tool Taxonomy - 8 • Integration and testing tools • data acquisition • get data for testing • static measurement • analyze source code without using test cases • dynamic measurement • analyze source code during execution • simulation • simulate function of hardware and external devices • test management • cross-functional tools

40. CASE Tool Taxonomy - 9 • Static analysis tools • code-based testing tools, specialized testing languages, requirements-based testing tools • Dynamic analysis tools • intrusive tools modify source code by inserting probes to check path coverage, assertions, or execution flow • non-intrusive tools use a separate hardware processor running in parallel with processor containing the program being tested

41. CASE Tool Taxonomy - 10 • Test management tools • coordinate regression testing, compare actual and expected output, conduct batch testing, and serve as generic test drivers • Client/server testing tools • exercise the GUI and network communications requirements for the client and server

42. CASE Tool Taxonomy - 11 • Reengineering tools • reverse engineering to specification tools • generate analysis and design models from source code, where used lists, and other design information • code restructuring and analysis tools • analyze program syntax, generate control flow graph, and automatically generates a structured program • on-line system reengineering tools • used to modify on-line DBMS

43. Some Useful Tools • Data dictionary • Computerized list of all data defined within the product • Consistency checker • Report generator, screen generator

44. 8 Scope of CASE • Programmers need to have: • Accurate, up-to-date versions of all project documents • Online help information regarding the • Operating system • Editor • Programming language • Online programming standards • Online manuals • Editor manuals • Programming manuals

45. Scope of CASE (contd) • Programmers need to have: • E-mail systems • Spreadsheets • Word processors • Structure editors • Pretty printers • Online interface checkers

46. Online Interface Checker • A structure editor must support online interface checking • The editor must know the name of every code artifact • Interface checking is an important part of programming-in-the-large

47. Online Interface Checker (contd) • Example • The user enters the call average = dataArray.computeAverage (numberOfValues); • The editor immediately responds Method computeAverage not known • The programmer is given two choices • Correct the name of the method to computeMean • Declare new procedurecomputeAverage and specify its parameters • This enables full interface checking

48. Online Interface Checker (contd) • Example • Declaration ofqis void q (float floatVar, int intVar, String s1, String s2); • Call (invocation) is q (intVar, floatVar, s1, s2); • The online interface checker detects the fault • Help facility • Online information for the parameters of method q • Better: Editor generates a template for the call • The template shows type of each parameter • The programmer replaces formal by actual parameters

49. Online Interface Checker (contd) • Advantages • There is no need for different tools with different interfaces • Hard-to-detect faults are immediately flagged for correction • Wrong number of parameters • Parameters of the wrong type • Essential when software is produced by a team • If one programmer changes an interface specification, all components calling that changed artifact must be disabled

50. Online Interface Checker (contd) • Even when a structure editor incorporates an online interface checker, a problem remains • The programmer still has to exit from the editor to invoke the compiler (to generate code) • Then, the linker must be called to link the product • The programmer must adjust to the JCL, compiler, and linker output • Solution: Incorporate an operating system front-end into the structure editor