diff --git a/Final exam study guide/Study guide.txt b/Final exam study guide/Study guide.txt new file mode 100644 index 0000000..21849f3 --- /dev/null +++ b/Final exam study guide/Study guide.txt @@ -0,0 +1,114 @@ +Requirements gathering: + Main objectives: + 1) Understand the problem + 2) Understand how software is supposed to solve that problem + Asking questions to aim discussion and to build your understanding + Observe current process / workflows + Determine common usage scenarios / stories + Use active listening +Problem solving: + How to facilitate a brainstorming session + * Enumerate possible solutions (no critiquing or arguing in this stage) + * Jot down ideas for everyone to see, as they are generated. + * When things slow down, identify the good qualities of various ideas that were proposed + * Narrow it down to one or two possible plans of action +Requirements document (mainly consider the system as a black box in the context of the problem domain): + Entities and attributes + Relations, cardinalities, and entity-relation diagrams + Events and sequence + Queries and notifications +System specification: + What the system will look like + How it will behave in response to input (users / sensors / other software) + Operating procedures +Prototyping +User interface design: + * Consistency (within the application and with similar applications) + * Provide easy navigation (logical hierarchy: navigating menus or tools for more options; multiple ways to carry out an action where it's natural to do so) + * Provide informative feedback (e.g. password strength) + * Design workflows to yield closure (e.g. "purchase complete", "file saved") + * Prevent user errors (e.g. "are you sure you want to exit without saving?") + * Allow users ways to reverse their actions easily (e.g. undo, redo, cancel, and exit) + * Avoid surprises and changes in behavior + * Minimize the user's memory load (avoid having to remember things in order to perform a task, e.g. "I forgot that I already bought that book.") + * Aim for clarity (quickly and easily understand what something does) + * Use visual hierarchy (size, color, font, white space, and negative space) to illustrate what is important and what groups together + * Design for flexibility: Accommodate different user skill levels (e.g. mouse vs keyboard shortcuts, advanced features, filters) and disabilities (color contrast, screen reader, easy tab key navigation, for web: different devices) + * Lead the user to formulate a good mental model of what happens internally +Software development life cycle models: + Types: Waterfall / incremental / iterative / spiral / agile / evolutionary / code & fix + Considerations: requirement stability, schedule constraints, team skills, human factors, visibility, parallelizablity +Language selection: + Familiarity vs suitabilitiy for the task at hand +System-level design: + Technology selection + Feasibility + File formats + Database management system selection and design + Performance + Scalability + Security + Error processing & fault tolerance +Databases: + SQL: + Properties (ACID): + Atomic - either all of the transaction takes affect, or none of it (including under power failures and crashes) + Consistent - database invariants are maintained (constraints, triggers, referential integrity, etc.) + Isolated - transactions are executed as if they were sequential + Durable - committed transactions are never forgotten (i.e. they stored to non-volatile memory) + Basic operations (CRUD) and their associated SQL statements: + Create (INSERT) + Retrieve (SELECT) + Update (UPDATE) + Delete (DELETE) + NoSQL: + Useful when you need high-performance at a huge scale, with little or no relation between tables +Class-level design: + Main focus (managing complexity): + Limit the amount of complexity we deal with at a time + Limit the effects when a change is made to the code + Abstraction (a class should represent one coherent abstraction or concept) + Information hiding / encapsulation (outside a class, you should not have to understand the internal implementation) + Loose coupling + High cohesion + Guide to design: "How will this class be used?" + Code reuse opportunities + Other tips: + * Every constructor and public method should leave the instance variables in a consistent and correct state for the next public method call + * Generally avoid going over 7 (plus or minus 2) instance variables in a class. + * Do not repeat data unless truly necessary. + * Do not give variables more scope than they require. + Immutable objects + Benefits: + Thread-safe + Can freely share pointers to objects; no hidden side effects if something changes + Drawback: + If there are lots of changes then immutability may result in memory burn and slowdowns +Method-level design: + * Naming + * Give descriptive names that say exactly what the routine does (usually verb-noun) + * The name should include or imply the return type + * Size + * Functions over a couple hundred lines of code tend to be more error-prone + * Otherwise, no hard constraints on method length - whatever is natural for the situation + * Parameters + * Use parameter order consistently among different functions + * Document assumptions on parameters + * Document units + * Document zero-based-counting vs one-based-counting if not obvious + * Error handling + * Check values of input parameters + * Use assertions to check for bugs. Use error handling to check for bad input. + * Techniques for error handling: + * Return null or neutral value + * Print or log the error and continue execution + * Throw an exception/error + * Terminate the program +Control structures: + When should you use break or continue in a loop? + * When it makes your code easier to read/maintain/understand as opposed to working it into the boolean condition for the loop. + * The danger of using break or continue in a large loop is that it becomes 'hidden' and people might not realize that something inside the loop affects its control flow. + What are the advantages/disadvantages of switch...case? + + The expression is only checked once in one place, and would only need to changed in one place + + You can exploit the fall-through behavior. + - You have to keep putting 'break;' at the end of each case if you don't want the case to "fall through". If you forget, it still compiles.