1 / 78

Lecture 10 Implementation

Lecture 10 Implementation. CSCI – 3350 Software Engineering II Fall 2014 Bill Pine. Overview. The Implementation Workflow Choosing a Programming Language Good Programming Practices Coding Standards Metrics for the Implementation Workflow. Overview (cont). Secure Coding Background

rafiki
Télécharger la présentation

Lecture 10 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. Lecture 10Implementation CSCI – 3350 Software Engineering II Fall 2014 Bill Pine

  2. Overview • The Implementation Workflow • Choosing a Programming Language • Good Programming Practices • Coding Standards • Metrics for the Implementation Workflow CSCI 3350

  3. Overview (cont) • Secure Coding Background • Buffer overflow attack • Strategies to reduce vulnerability • Guiding Principles for Software Security CSCI 3350

  4. Implementation Workflow • Goal: Clearly and accurately represent the detailed application design in the chosen implementation language • Define the unit tests • Write the code • Execute the unit test suite • Resolve any discrepancies • Submit to QA group for further evaluation CSCI 3350

  5. Choosing a Programming Language • Specified directly as a requirement • Specified indirectly as a requirement • Platform specified • If there is an opportunity for choice • “Most appropriate language” requirement • Or you may be driven by an object-oriented design and implementation requirement CSCI 3350

  6. Taking a Decision • Base upon • Cost benefit analysis • Risk analysis • Use the language strength of the organization • Procedural vs. object-oriented • Pure object-oriented • Hybrid • Acquiring needed skills issue • Hire new talent • Retrain existing employees • A mixture? CSCI 3350

  7. X- Generation Language • First-generation languages • Machine code • Second-generation language • Assembly • Third-generation language • High order language • Multiple (5-10) machine instructions/source line • Examples: FORTRAN, C, COBOL … CSCI 3350

  8. Fourth-Generation Language • Application-specific language • Original goal was 25 - 50 mi/source line • Database based • PowerBuilder • Oracle • DB2 • Report generators • Mathematics based • Mathmatica • SPSS CSCI 3350

  9. Good Programming Practices • Many best practices tend to be language specific • Some authors have made a career of adapting for each new language • Example: Henry Ledgard - authored > 25 works • Programming Proverbs • Programming Proverbs and Principles • Programming Proverbs for FORTRAN Programmers • FORTRAN with Style: Programming proverbs • Pascal with Style: Programming proverbs • Pascal with Excellence: Programming proverbs • Programming Language Landscape • Some general practices cut across specific languages CSCI 3350

  10. Best Coding Practices • The following slides on best practices draw heavily upon • Clean Code – full citation in reference • Agile Development Community is the origin of the Best Coding Practices • You must devote effort to writing and maintaining quality code • As the code deteriorates, so decreases team productivity • Decreasing productivity, causes less effort to be expended in maintaining code quality. Leading to lower productivity … • A positive feedback loop that is inherently unstable

  11. Best Coding Practices (cont) Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best. - Robert Martin

  12. Best Programming Practices • Will examine guidelines relating to the following areas • Identifier names • Functions • Comments • Formatting CSCI 3350

  13. Guidelines for Identifier Names • Meaning must be obvious to the maintenance programmer • Maximize communications • Use intention-revealing names • Much harder than it seems • Accept that the name will probably change as you are developing CSCI 3350 Lecture 10 - 13

  14. General Practices General Guidelines Variables should be nouns (noun phrases) Class and objects names should be nouns (noun phrases Function and method names should be verbs (verb phrases) Kernighan and Pike assert: “Long names for global identifies; short names for local identifiers” CSCI 3350 Lecture 10 - 14

  15. Identifier Names (cont) • Identifier name should answer the questions • Why does the entity exist? • What does the entity do? • How is the entity used? • If the identifier name requires a comment to answer these questions • The name does not reveal the identifier’s intent and needs to be changed CSCI 3350 Lecture 10 - 15

  16. Identifier Names (cont) • Avoid Disinformation • Use a difference in identifier only when you are making a meaningful distinction • Example: fetch, get, retrieve or controller, manager, driver • Don’t use lower case L or upper case O as variable name • Don’t use noise words • a, an, the - as prefixes without a convention • info, data – as suffixes • nameString instead of name? CSCI 3350 Lecture 10 - 16

  17. Contrived (?) Example int a = 1; if( 1 == O1 ) a = Ol else a = 01 CSCI 3350 Lecture 10 - 17

  18. Identifier Names (cont) • Use pronounceable names • Use searchable names • One or two letter variable names and literal constants yield too many matches • Avoid encoding the identifier type in the name • In particular, eschew Hungarian notation • No help with strongly typed languages • Allow for misleading information if the type changes • But the encoding doesn’t CSCI 3350

  19. Identifier Names (cont) Avoid mental mappings Short names / heavily abbreviated names require the reader to translate Avoid cute names Prefer solution domain names over problem domain names Who is the reading audience of your code? Prefer problem domain names over informal names CSCI 3350 Lecture 10 - 19

  20. Identifier Names (cont) Don’t add gratuitous context to identifier names Add context only as necessary accountAddress and customerAddress may be appropriate for instances of a class But not appropriate for a class name – Address would be a better choice CSCI 3350 Lecture 10 - 20

  21. Identifier Names (cont) Final comments Poor names Impede communications between the code author and the code reader Have been shown to be an indicator of overall poor code quality Indicate a less than complete understanding by the author Point to likely areas for code faults CSCI 3350 Lecture 10 - 21

  22. Guidelines for Functions First rule of functions A function should be small Second rule of functions A function should be smaller than would be produced by rule 1 Try for an average of 20 lines / function Indent depth should should be 1 or 2 levels CSCI 3350 Lecture 10 - 22

  23. Functions (cont) Functions should do 1 thing They should do it well They should do that 1 thing only All steps in the function should be at the same level of abstraction Principle of Least Surprise Based upon the function name, the code in the function is what you would expect CSCI 3350 Lecture 10 - 23

  24. Functions (cont) The ideal number of arguments is zero Niladic Followed by 1 argument – Monadic 2 arguments – Dyadic 3 arguments – Triadic Any more than 3 requires compelling justification CSCI 3350 Lecture 10 - 24

  25. Functions (cont) Why restrict the the number of arguments? An increasing number of argument requires increasing conceptual power Harder to test and requires an increasing number of tests Eschew flag arguments Indicate that a function is doing more than 1 thing Functions should have no side effects CSCI 3350 Lecture 10 - 25

  26. Functions (cont) Avoid output arguments The reader’s expectation is that an argument is an input Prior to object oriented programming, one could justify the use of output arguments With o-o, instead of having a function return a value through an argument, the function should change the state of the appropriate object CSCI 3350 Lecture 10 - 26

  27. Functions (cont) Functions should change the state of an object or return the state of an objects – never both Prefer exceptions over returning error codes Never duplicate code (i.e. copy &paste) Code bloat Multiple places to change the code => multiple places for faults to be injected CSCI 3350 Lecture 10 - 27

  28. Guidelines for Comments • Myth of “self-documenting” code • Goal: The code should not need comments to make clear the “how” of the code • Always need internal documentation • To meet the need of making clear the “why” • Block comments at the beginning of each unit • Comments interspersed (as needed) within the unit CSCI 3350

  29. Comments (cont) The previous slide not withstanding, which code would you rather read? Version 1 // // *** Check if employee is eligible for benefits // if( (employee.flags & HOURLY_FLAG) && (employee.age > 55 ) ) Version 2 if( employee.isEligibleForFullBenefits( ) ) CSCI 3350 Lecture 10 - 29

  30. Comments (cont) • Additional thoughts on comments • Don’t comment the obvious • Don’t use end-of-line comments with high-order languages • Format of the comments should reflect and reinforce the structure of the code • Comments must be accurate • Agree with the code and support reading the code CSCI 3350

  31. Comments (cont) Don’t comment closing braces Don’t use comments as a substitute for source code versioning systems Remove commented-out code from production code Don’t add bylines CSCI 3350 Lecture 10 - 31

  32. Guidelines for Formatting • Code formatting is important • Format as you write the code, not as a cleanup operation • Remember the PARC Design Principle • Indentation • Source code is a hierarchy • Use consistent indentation to reflect the hierarchy • Don’t violate indentation – ever – not even for short functions / methods CSCI 3350

  33. Formatting (cont) • Intra-line white space • Some freedom to improve readability if your editor / IDE doesn’t insist upon removing “extraneous”spaces • Consider the following root1 = (-b+sqrt(b*b-4ac))/(2*a) • Versus root2 = (-b - sqrt(b*b – 4*a*c))/(2*a) CSCI 3350

  34. Miscellaneous Practices Eschew literal constants for symbolic constants Higher informational content Easier to read Easier to maintain More readily searchable CSCI 3350 Lecture 10 - 34

  35. Miscellaneous (cont) • Layout • Use the block separators consistently • K & R • Allman • Whitesmith • One statement per line • Use parenthesis to eliminate misunderstanding • Order of precedence • Break complex expressions into simpler ones CSCI 3350

  36. Miscellaneous (cont) • Strive for clearness not cleverness • Be concise, but not at the expense of readability • Be aware of side effects • Some languages have operators that • Return a value • Modify the internal state of an item • Do not specify the exact order of execution CSCI 3350

  37. Miscellaneous (cont) • Idioms • Definition - an expression that has a meaning not readily understood from the meaning of the individual words • A central issue in learning any language is to absorb and use the idioms • Example • “Burf is a student after my own heart” • Array idioms (code patterns) • List walking CSCI 3350

  38. Coding Standards • Purpose is to define the practices that make the life of the development and maintenance programmers easier • Records, documents and clarifies the set of best programming practices that will be used by the • Organization • Team • Project CSCI 3350

  39. Recall The Distinction • Error - A discrepancy between an actual value and a expected value • Failure - Inability for the system to perform according to specifications • Fault - A condition that causes the system to fail • If an error is observed, then a failure must have occurred • If a failure has occurred, then there must be a fault in the system CSCI 3350

  40. Implementation Metrics • Code complexity metrics • Lines of code • Assumes a constant probability that a line of code contains a fault • More lines of code => more faults • A number of studies have shown a correlation between the number of faults and the size of the application CSCI 3350

  41. Implementation Metrics (cont) • McCabe’s cyclomatic complexity M • M = number of binary decision + 1 • A measure of the number of branches in the code • Recall white-box testing coverage criteria • M can be used as a measure of the number of test cases for branch coverage CSCI 3350

  42. Implementation Metrics (cont) • Advantages • Almost as easy to calculate as lines of code • Studies show a good correlation between M and number of faults • Disadvantages • M correlates strongly with lines of code • There may be little additional value over lines of code CSCI 3350

  43. Implementation Metrics (cont) • Testing metrics • Number of tests • McCabe’s M a good measure for number of tests for branch coverage • Total number of faults • Exceeding a threshold triggers rewrite of a “chunk” of code • Number of faults by faulty type • Use of the types of faults to generate checklists for non-execution based testing CSCI 3350

  44. Origins of Bad Software • Graff and van Wyk cite three factors • Technical • Psychological • Real world • Probably not due to • Ignorance • Stupidity • Laziness CSCI 3350

  45. Technical Factors • Secure software is intrinsically difficult to write • Complexity • Composition • System composed of multiple separate components • Each component standing alone is secure • Combination introduces a vulnerability CSCI 3350

  46. Psychological Factors • Software professionals make mistakes • Even when examining software for vulnerabilities, • Tend to discover only faults • That we are looking for • That we understand • That we know how to fix • Most people find it hard to • Assume that the “other guy” is a “bad guy” • We are too willing to trust others • Adopt a different view of the software CSCI 3350

  47. Different Views of Software • Software developers frequently employ mental models • When viewed only from the mental model, potential vulnerabilities are not apparent • The bad guy is successful in his attack by adopting a different mental model CSCI 3350

  48. Mouse Attack • An attacker was able to gain control of a Unix system by abusing a mouse driver • Purpose of the driver was to position the cursor at a specified screen location • Since the driver needed to interact with the display hardware it was installed with high privileges • Driver worked error-free for years • Until … CSCI 3350

  49. Mouse Attack (cont) • An attacker directly called the driver with very large values for the screen coordinates • Internal memory of the driver was overwritten • Allowing the attacker to gain control of the system • The attacker was successful by • Ignoring the mental model for the driver • Concentrating on the code bytes • Developer’s mental model did not admit the possibility for the driver being directly called by an application program • The ability to ignore the mental model is • A hard skill for developers to cultivate • An essential skill for locating vulnerabilities CSCI 3350

  50. Some Different Views of the System • An ordered set of algorithms • Lines of text on the screen • An ordered set of instructions for a specific processor • A series of bits ( 0 | 1 ) • In memory • On magnetic disk • On optical media CSCI 3350

More Related