1 / 54

Implementation

Implementation. CS 552 Spring ‘06. Figure 3: Kruchten’s “4 + 1”Model for Developing Software Architecture. + 1 Business Scenario. View 1. View 2. Process -- System Integrators. Logical -- End Users. + 1 Business Scenario. View 4. View 3. Development -- Programmers.

reed-sullivan
Download Presentation

Implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Implementation CS 552 Spring ‘06 CS 552 Spring 2006 Implementation

  2. Figure 3: Kruchten’s “4 + 1”Model for Developing Software Architecture + 1 Business Scenario View 1 View 2 Process -- System Integrators Logical -- End Users + 1 Business Scenario View 4 View 3 Development -- Programmers Physical -- Engineers This is an innovative and comprehensive integration of the abstractions needed to design the structure for writing system requirements. + 1 Business Scenario CS 552 Spring 2006 Implementation

  3. Development View -Tools • Coding Tools- map problem to solution domain; Concurrency • Testing tools- assures quality • Production tools- translates code into product. • System Management tools-OAM&P • Open Source • Documentation tools -record decisions and system changes. CS 552 Spring 2006 Implementation

  4. Code Review #include <stdio.h> #include <string.h> void foo(const char* input) { char buf[10];   printf(“My stack looks like: \n%p\n%p\n%p\n%p\n%p\n%p\n\n”);   strcpy(buf, input); printf(“%s\n”, buf);   printf(“Now the stack looks like: \n%p\n%p\n%p\n%p\n%p\n%p\n\n”); } CS 552 Spring 2006 Implementation

  5. Exercise Can you show how a static buffer overrun can be used to execute arbitrary code in this program? The objective is to find a flaw that has allows an input string that to execute a hack and insert a virus. CS 552 Spring 2006 Implementation

  6. Can you find the flaw • Detailed Design leads to fragile software or to robust software. • How could you prevent the ‘hack’ that can execute a virus? CS 552 Spring 2006 Implementation

  7. Now lets look at some examples of input: [d:\]StaticOverrun.exe Hello Address of foo = 00401000 Address of bar = 00401045 My stack looks like: 00000000 00000000 7FFDF000 0012FF80 0040108A < - - We want to overwrite the return address for foo 00410EDE to 00401045 which is the address of bar Hello Now the stack looks like: 6C6C6548 < - - You can see where “Hello” was copied in 0000006F 7FFDF000 0012FF80 0040108A 00410EDE CS 552 Spring 2006 Implementation

  8. Now for the classic test for buffer overruns – we input a long string [d:\]StaticOverrun.exe AAAAAAAAAAAAAAAAAAAAAAAA Address of foo = 00401000 Address of bar = 00401045 My stack looks like: 00000000 00000000 7FFDF000 0012FF80 0040108A 00410EDE AAAAAAAAAAAAAAAAAAAAAAAA < - - 24 A’s, A = 0x41 Now the stack looks like: 41414141 41414141 41414141 41414141 41414141 41414141 This would cause an application error message claiming the instruction at 0x41414141 tried to access memory at address 0x41414141 ! CS 552 Spring 2006 Implementation

  9. Now we want to try and find the location by feeding it different characters [d:\]StaticOverrun.exe ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890 Address of foo = 00401000 Address of bar = 00401045 My stack looks like: 00000000 00000000 7FFDF000 0012FF80 0040108A 00410EDE ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890 Now the stack looks like: 44434241 48474645 4C4B4A49 504F4E4D 54535251 58575655 CS 552 Spring 2006 Implementation

  10. We can see that the 54 stands for T and is on the line where we want to modify the return address to foo, so lets try this: [d:\]StaticOverrun.exe ABCDEFGHIJKLMNOPQRS Address of foo = 00401000 Address of bar = 00401045 My stack looks like: 00000000 00000000 7FFDF000 0012FF80 0040108A 00410EDE ABCDEFGHIJKLMNOPQRS Now the stack looks like: 44434241 48474645 4C4B4A49 504F4E4D 00535251 00410ECE CS 552 Spring 2006 Implementation

  11. Now we can see that if we could send it 0x45, 0x10, 0x40 instead of QRS we could get bar to execute, to do this we’ll have to use a perl script $arg = “ABCDEFGHIJKLMNOP”.”\x45\x10\x40”; $cmd = “StaticOverrun “.$arg; system(cmd); CS 552 Spring 2006 Implementation

  12. Running this script produces the desired result: [d:\devstudio\myprojects\staticoverrun]perl HackOverrun.pl Address of foo = 00401000 Address of bar = 00401045 My stack looks like: 00000000 00000000 7FFDF000 0012FF80 0040108A 00410EDE ABCDEFGHIJKLMNOPE?@ Now the stack looks like: 44434241 48474645 4C4B4A49 504F4E4D 00401045 00410ECA Augh! I’ve been hacked! CS 552 Spring 2006 Implementation

  13. How could you prevent the hack? • Check to make sure the input string does not exceed the buffer. • Add this code: if input > buffer exit, else strcpy(buf, input) CS 552 Spring 2006 Implementation

  14. Implementation Processes • Incremental Development • Component-based design. • Agile Methods. • Model Driven Development- maintains architectural integrity • Autonomic Computing — deals with system operation complexity. CS 552 Spring 2006 Implementation

  15. Agile Methods • Highly motivated and skilled individuals • Continuous customer collaboration • Minimizes risk with rapid iterative implementation • Small increments • Bottom up emphasis • Delivery of working software frequently - the measure of progress • Team work and collaboration vital CS 552 Spring 2006 Implementation

  16. Sprint Scrum Summary Feedback Control Standards, Conventions, Guidelines Product Backlog sQFD Sprint Backlog Sprint Planning Meeting Executable Product Increment Daily Scrum CS 552 Spring 2006 Implementation

  17. Model Driven Development . • Formal models may be executable • Traceability from requirements to implementation. • Complete development documentation to eliminate legacy code • Automatic code generation • Modifications and updates as design (not code) changes — avoids software aging or architectural drifts • Prototypes may become models. BUT the human thought process of transforming the design to implementation is still needed. This is a way to move to a higher level language. CS 552 Spring 2006 Implementation

  18. Information product delivery time Meir M. Current product information Lehman ~ 1980 legacy code Out of-date product information Time Legacy Code — M.M. Lehman Poorly documented source code that cannot be modified or updated because its exact operation is unknown. CS 552 Spring 2006 Implementation

  19. Open Source Code • The developer must be a user and there are: • No royalties • Accessible source code • Modifications and derivations are encouraged • No person, group or field of endeavor can be denied access to the program • The rights attached to the program must not depend on the program's being part of a particular software distribution • The licensed software cannot place restrictions on other software that is distributed with it. CS 552 Spring 2006 Implementation

  20. Free Open Source Software (FOSS) • The freedom to run the program, for any purpose • The freedom to study how the program works, and adapt it to your needs. Access to the source code is a must. • The freedom to redistribute copies so you can help others. • The freedom to improve the program, and release your improvements to the public, so that the whole community benefit. Access to the source code is again a must. CS 552 Spring 2006 Implementation

  21. FOSS Development Processes • Requirements as informal web notes - no apriori spec • Version Control and incremental releases- ‘committer’ • Zero Maintenance- evolutionary redevelopment • Layered Meritocracy with virtual project manager having source control and assignments • Explicit Software Technology Transfer as reported by Walt Scacchi UCSB CS 552 Spring 2006 Implementation

  22. Autonomic Computing Systems capable of running themselves, adjusting varying workloads — systems that allow users to concentrate on what they have to do, instead of how to do it. • Overcomes OAM&P complexity • Self-monitoring & self-configuring • Self-optimizing & self-adapting • Self-healing & self-protecting CS 552 Spring 2006 Implementation

  23. Multilayered Management CS 552 Spring 2006 Implementation

  24. A brief aside on measurement • A fault leads to a failure. It is essential to count everything, not just serious ones, (25:1 spread has been observed between all faults and serious ones). • Systems are often compared in fault density, (faults per KLOC). This is a function of time. It only makes sense when comparing mature systems, (the asymptotic value). • Definitions of a line of code can vary considerably, (range of 2:1 in C). • Definitions of time also vary. For mean time to fail, it is the time of use ! CS 552 Spring 2006 Implementation

  25. Categories of post-delivery failures in 1997 Study CAA Canadian Aviation Authority This data suggests that major / minor failure ratio is somewhere between 5% and 10%. CS 552 Spring 2006 Implementation

  26. The NASA data CS 552 Spring 2006 Implementation

  27. Strategic importance of reliability Reliability is becoming of strategic importance to companies in the 1990’s. Why ? CS 552 Spring 2006 Implementation

  28. The growth in maintenance costs Source: US Quality Assurance Institute CS 552 Spring 2006 Implementation

  29. The distribution of Life-Cycle Costs Source: NASA, Arnold (1983), Boehm and others CS 552 Spring 2006 Implementation

  30. Software maintenance costs • The Microsoft Help Desk costs were reported by Bender (1996) at Star’96 as follows:- • Cost prior to Window’s 95 was 25,000 calls per day at an estimated $50-100 per call. • Assuming $75 average, this gives $684 million per year. • It is estimated to have jumped to 100,000 calls per day since Window’s 95, giving an overhead of approximately $2.5 billion per year. CS 552 Spring 2006 Implementation

  31. Predicted Errors Demographics • Communications- Gossip • Parsers- Seimens • Graphics- Game • Data Schema- USPS CS 552 Spring 2006 Implementation

  32. The defect density U curve For Ada, assembler, C, C++, Cobol, Fortran, Pascal, and PL/M systems: Defects per KLOC Average component complexity CS 552 Spring 2006 Implementation

  33. Data-Driven Defect Isolation - Strategy 1 • Exploiting the U-curve: • Inspect components at the high end and low end preferentially over the medium-sized ones, (i.e. those near the middle of the U-curve). CS 552 Spring 2006 Implementation

  34. Data-Driven Defect Isolation • Exploiting the U-curve: • Complexity is a statically measurable property. • Using static deep-flow analysis, we can target human inspection resources to exploit the natural U-shape of the defect density curve. CS 552 Spring 2006 Implementation

  35. Defects per KLOC Average component complexity The defect density U curve - invasive truncation In those systems where excessive complexity has been restricted:- CS 552 Spring 2006 Implementation

  36. Data-Driven Defect Isolation - Strategy 2 • Exploiting the U-curve: • Forbid the appearance of components at the high end by static enforcement of size limits, and inspect the low end at the expense of the ones near the bottom of the U-curve. CS 552 Spring 2006 Implementation

  37. Eliminate Small Components Defects per KLOC Average component complexity CS 552 Spring 2006 Implementation

  38. Exploiting inheritance clustering CS 552 Spring 2006 Implementation

  39. Concise Code is Productive Defect density is relatively independent of programming language, so • Moving from assembler to any 3GL is a good idea. • Moving from one 3GL to another seems a bad idea. CS 552 Spring 2006 Implementation

  40. Inspections Probably the most significant step forward in defect removal prior to delivery which we have yet experienced • The evidence suggests that they are 5-10 times more efficient than any other form of defect removal. • The technology is mature, (some 20 years old), and in trained hands, exceptionally effective. CS 552 Spring 2006 Implementation

  41. Ignoring Inspections This impressive performance is rewarded by being ignored by most of the computing industry • Time-to-Market Pressure • Managers punish errors • Gurus do not suffer fools lightly • Bureaucratic Check Lists CS 552 Spring 2006 Implementation

  42. Inspections- Alcatel example, (1995) CS 552 Spring 2006 Implementation

  43. Inspections - HP example, 1987 Rate of faults found per hour, (Grady & Caswell, (1987), HP): CS 552 Spring 2006 Implementation

  44. Code Inspection Solution 1. Inspect code of newcomers. 2. Inspect code if bugs are found in system test. 3. Inspect code where there is a long history of change. 4. Measure Complexity and Code Inspect the outliers. 5. Ask all programmers to have their code read by someone else. CS 552 Spring 2006 Implementation

  45. Formal Methods • They can be are effective, but are not a quantum leap. It depends! • 3:1 defect density reduction is possible • They only appear to work in conjunction with other techniques. • Beware of over-reliance on them • In many system there are algorithms which you can’t get right any other way. CS 552 Spring 2006 Implementation

  46. Do Formal methods work ? CAA study CS 552 Spring 2006 Implementation

  47. Where defects were found in CAA Study 1997 This data tentatively suggests that either formal specifications lead to unusual fault distributions or that they lead to over-reliance at the expense of code inspection. CS 552 Spring 2006 Implementation

  48. Doubt on Poor object-orientation • Recent studies (Humphrey, Hatton, Tichy, Shepherd & Cartwright) together show: • • C++ OO systems have almost 25% more defects than conventional C or Pascal systems. • • Each defect in a C++ OO system takes between 2 and 3 times longer to fix than a conventional system. This is true for both simple defects AND difficult ones. The whole distribution is right shifted. • Components involved in inheritance have 6 times more defects than non-inheritance components. CS 552 Spring 2006 Implementation

  49. Doubt on object-orientation, (Humphrey) CS 552 Spring 2006 Implementation

  50. Doubt on object-orientation, (Hatton) CS 552 Spring 2006 Implementation

More Related