Test your basic knowledge |

SWA - Software Architecture

Instructions:
  • Answer 50 questions in 15 minutes.
  • If you are not ready to take this test, you can study here.
  • Match each statement with the correct term.
  • Don't refresh. All questions and answers are randomly picked and ordered every time you load a test.

This is a study tool. The 3 wrong answers for each question are randomly chosen from answers to other questions. So, you might find at times the answers obvious, but you will see it re-enforces your understanding as you take the test each time.
1. Formatted code standards.






2. Adds files to the repository.






3. Undo changes made since your last commit.






4. Separating out a section of code into a reusable function or class.






5. Creates a spin-off of a repository for concurrent development.






6. Compose objects into tree structures to represent part-whole hierarchies. Lets clients treat individual objects and compositions of objects uniformly.






7. When we remove redundant or obsolete designs and replace them with a new.






8. Ensure a class only has one instance - and provide a global point of access to it






9. Developers should be integrated and releasing code into the code repository every few hours.






10. Weak relationship between two classes. Almost always results in a #include.






11. Uploads changes to your current branch.






12. Static in C++. Can span all instances of a class.






13. Functionality Tests.






14. Treating a derived class's data members like it's base class's.






15. Trying to access a location in memory that your computer cannot access.






16. Having power over inheritance with the flexibility of composition.






17. Stops when memory changes.






18. CONSTANT






19. A group of code. unnamed can only be accessed within that translation unit - name can be accessed anywhere






20. Will execute all code paths and boundary conditions.






21. STOP!!






22. Classes build off of each other.






23. Ability to accept different types of parameters to bind to different implementations at run-time.






24. A measure of logical dependency.






25. When a class is defined within another class.






26. Whats displayed to the screen






27. Variable doesn't exist.






28. (Door-----Spell) BI_DIRECTIONAL because both classes can reference each other. (Door--->Spell) DIRECTIONAL because only the door knows and can reference Spell.






29. Bad! Don't ever use these types of variables!






30. Do not optimize until the very end.






31. Helps to eliminate unnecessary "include chaining."






32. The default nickname for the remote repository.






33. Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.






34. When a conflict is fixed.






35. Meetings used to create a release plan - which will lay out the overall project.






36. Try to find the flaws in your code.






37. Symbols that can be invoked or used by other code in a different unit. All non inline class member functions and variables - non-static non-member functions and variables defined within a .cpp file






38. Copies all changes from one branch into another branch.






39. About the interface to an object. Data contained within.






40. No man's land. Guard bytes before the after allocated heap memory.






41. Views all previous changes.






42. Encapsulates a request as an object - thereby letting you parameterize clients with different requests - queue or log requests - and support undoable operations.






43. NULL memory.






44. Bookmark of a revised set with a title. For easy checkouts.






45. Uploads all changes staged in the index list into the repository database.






46. How many objects that a source object can legitimately reference.






47. Initialized stack memory.






48. Create a test and then create a function.






49. Taking code and moving it to a function that usually returns an object. They are always virtual functions.






50. Valid input that the program is designed to process.