Busy. Please wait.

show password
Forgot Password?

Don't have an account?  Sign up 

Username is available taken
show password


Make sure to remember your password. If you forget it there is no way for StudyStack to send you a reset link. You would need to create a new account.
We do not share your email address with others. It is only used to allow you to reset your password. For details read our Privacy Policy and Terms of Service.

Already a StudyStack user? Log In

Reset Password
Enter the associated with your account, and we'll email you a link to reset your password.

Remove ads
Don't know
remaining cards
To flip the current card, click it or press the Spacebar key.  To move the current card to one of the three colored boxes, click on the box.  You may also press the UP ARROW key to move the card to the "Know" box, the DOWN ARROW key to move the card to the "Don't know" box, or the RIGHT ARROW key to move the card to the Remaining box.  You may also click on the card displayed in any of the three boxes to bring that card back to the center.

Pass complete!

"Know" box contains:
Time elapsed:
restart all cards

Embed Code - If you would like this activity on your web page, copy the script below and paste it into your web page.

  Normal Size     Small Size show me how

Software robustness

Robustness 1) Fault tolerant 2) Graceful shutdown 3) Meaningful feedback on errors 4) Recoverable 5) Reliable
How to obtain robust code 1) Program defensively 2) Hide information 3) Reduce Complexity 4) Expect the impossible
Program defensively 1) Require your preconditions to hold 2) Ensure your postconditions hold 3) Defend your gates against intruders 4) Let no spies get out
Hide information 1) Use the language’s build in incapsulation mechanisms 2) or trick the language to hide the information 3) With no walls, defending the gates alone is not very effective 4) Never reveal your weaknesses.
Reduce Complexity 1) Bundle parts of code with high cohesion 2) Decouple bundled parts 3) Be sure that your units are well organized and cooperating 4) Don’t let one unit’s defeat loose the battle
Expect the impossible Remember Murphy’s law . . . Anything that can go wrong will go wrong
Defensive programming 1) Always check the preconditions, trust nobody! 2) Check your postconditions, doubt yourself! 3) Check your invariants, Remember the ACID rules Atomicy Consistency Isolation Durability
The Big V 1) Validation Planning - Validation Reporting 2) User requirements - User Acceptance Testing 3) System requirements - System Testing 4) Technical Architecture - Installation Qualification 5) Detailed Design - Unit&Integration Testing 6) Config,dev
Testing documents 1) Specification of invariants, pre-, and postconditions. 2) Specification of tests to run (perform). 3) Specification of the coverage of the tests. 4) Specification of expected output of the tests.
How to encapsulate 1) Only use public where nescesary according to contract. 2) Use Facade objects. 3) Use Data Transfer Objects and tokens. 4) Be as abstract as possible 5) Don’t promise more than required
Created by: timeakiss