Help
Options
Didn't know it?
click below
click below
Knew it?
click below
click below
Don't Know
Remaining cards (0)
Know
retry
shuffle
restart
0:00
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
Normal Size Small Size show me how
Software design
| Term | Definition |
|---|---|
| Software design | Process of abstracting data and computations and organizing these abstractions into a working software application. |
| Common cause of system failure | 1. Unarticulated/unrealistic project goals 2. Poor communication 3. Sloppy development practices 4. Poor reporting of project status 5. Badly defined requirements |
| Waterfall process | analysis —> requirements specification —> design —> implementation —> testing and integration —> deployment and operation |
| Waterfall info | - Structure is unrealistic, but great for documentation - Good approach for singular, stable releases |
| V-Model | analysis -> deployment and operation req. spec. -> integration and acceptance testing design -> system testing implementation -> unit testing |
| V-Model info | - Widely used - Focused on testing and validation |
| V-Model/Waterfall + | - Simple - Specifications and deliverables are fully defined beforehand |
| V-Model/Waterfall - | - Need to assume frozen requirements - Whole system needs to be delivered at once, no room for feedback - Fixed linear process, hard to test - Extensive documentation |
| Prototyping model | cycle starting with: req. spec. entering the cycle of: analysis -> design -> implementation -> testing and integration -> customer evaluation and on customer evaluation either deployment and operation OR restart of the cycle starting from analysis. |
| Prototyping + | - Fast problem identification - Fast customer feedback - Gather information about the software as it is developed |
| Prototyping - | - Potentially excessive testing of prototypes - Mismatch and change of customer requirements (costs) - Budgeting becomes more challenging |
| Spiral model | It’s a cycle which consists of the same processes as Waterfall and V-Model, but with some extra axis-descriptors: costs (top), prototype (right), development and test (bottom right), plan next operation (bottom left), review (left) |
| Spiral + | - Integrates risk management - Emphasises communication, customer feedback and flexibility - Considers changes to requirements explicitly |
| Spiral - | - Complex (and not very clear) - Expensive/Resource intensive - Challenging risk and time management |
| Standard SDLC + | - Structured methodology - Proven successful in the past - Clearly defined requirements - Extensive quality control |
| Standard SDLC - | - Slow and inflexible - Typically expensive - Limited customer involvement |
| Agile Manifesto | Individuals and Interactions over Tools and Processes. Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan |
| Agile model | The agile software development process is the Waterfall transformed into a cycle, that’s about it |
| Agile + | - Flexible - Maximises customer involvement - Guarantees continuous delivery - Encourages collaboration - Early/frequent testing |
| Agile - | - Can be unpredictable - Abandonds documentation - Can result in a lack of planning - Time/Resource-demanding |
| Scrum model | Product Goal: long-term objective Product Backlog: Ordered list of product improvements Sprint, Sprint Planning, Daily Scrum Print Review, Sprint Retrospective |
| Scrum + | - Structure for dividing tasks - Fast forwards moving - Continuous meetings and clear roles - Customer involvement - Working prototypes |
| Scrum - | - Scope creep (no feeling of when it’s going to end) - Requires experience to implement (how to handle each role) - Keeping time management and motivation (what’s a waste of time? what’s needed?) |
| High-level types of requirements | Functional: functionality/behaviour that a system offers. Quality/non-functional: qualities of the system. Constraint: limits that cannot be influenced. |
| MoSCoW template | Must have - if one of these requirements is missing, the project fails Should have - important, not mandatory Could have - desirable and can be done if resources allow Won’t have - agreed on as uncritical, maybe for the future |
| Why do bugs happen | - programmer causes a defect - defect causes an infection - infection propagates - infection causes failure |
| Robustness | - ability of system to cope with errors and erroneous input. R |
| White box testing | tests exist as internal logic tests, where only the code is considered, without specification - we test only the internal state of the system, |
| Black box testing | tests that exist to validate intended functionality; whereas the validity of white-box tests might be determined by expected return values, the validity of these is based solely on the specification requirements |
| Version Control | - Can store different versions of a file in order. - Can be used to revert a file to a previous version - Allows for multi-user collaboration. - Assists with merging file versions. - Git, Apache |
| git branch | duplicate of the files in a repo that can be developed independently, to develop features, fix bugs, or prep a release. |
| git fork | duplicate of the files in the repo but independent of the repo |
| git clone | creates a local copy of the files on the repo (remote) |
| git pull | get changes from the remote |
| git checkout | get specific version of the remote |
| git push | send changes to the remote repo |
| git head | most recent commit to the repo |
| git version | state of the system after each commit |
| Design principle - Separation of concerns | structure the software into abstractions via divide & conquer; separate the software into units of minimal overlap by splitting it up and solving smaller, independent problems |
| Encapsulation | putting a defined abstraction into a unit/capsule |
| coupling | degree of interaction between units |
| cohesen | degree to which a single unit fulfills one purpose |
| maximize cohesion | it’s not good to have multiple sub-units within a single class not interact with each other: creates confusion, and violates the principle of “human design” |
| minimize coupling | information hiding for security and error-proneness reasons. |
| types of abstraction | - abstracting behaviour, in order to solve a problem via multiple smaller parts —> procedural abstraction - encapsulation and information hiding, in order to abstract properties from implementation —> data abstraction |
| Types of types | - primitive - variables that store actual values (byte, short, int, flong, float, double, boolean, char) - reference - store references to an object T - arrays, classes, String, interfaces… |
| ADT | Abstract Data Types - define a new abstract type to specify abstract data and operations. |
| Interface difference from ADT | - cant be instantiated as object, both specify behaviour and data - interface is a collection of behaviour by an object of that type - methods are defined but empty - class can implement multiple interfaces |
| ADT difference from interface | - AND an abstract class is abstracted behaviour of a collection of classes - methods can be abstract (no implementation) or concrete (with implementation) - should be a part of an inheritance structure. |
| Enumeration | a set of fixed values/constants (listed names). |
| Record | designed to store fixed values - intended for simple data structures without behaviour - points, tuples, coordinates, etc. |
| Solid principles | -Single responsibility -Open/closed -Liskov substituion -Interface Segregation -Dependency inversion |
| Open/closed principle | units should be open for extensions, but closed for modifications; adding new functionalities should be possible, without changing existing implementations |
| Liskov substituion | methods that use references to classes must be able to use objects of derived classes without knowing it. Any method referring to a superclass must also work when using a subclass |
| Interface segregation | no code should be required to rely on methods it is not using. Split up large interfaces. Give clients only the methods they use |
| Dependency inversion | higher level units should not depends on lower-level units, and both should depend on abstraction |
| Design Pattern families | -Creational - making object creation more flexible to match some use case -Structural - structuring units and their relationships -Behavioural - implementing communication between units. |
| GoF1 Singleton | Simple pattern for restricting the instantiation of a class to a single instance. - Ensure that only a single instance exists. - Define access to that instance. - Control the instantiation of the instance. |
| Singleton used for | - Storing and managing variables - Implementing other design patterns - Logging, configuring, file system, window manager - things that require a single instance, and would cause issues if multiple were present. |
| GoF2 Factory | Defines interface to create an object, but defers instantiation to subclasses - decouple object creation from concrete class - enables instantiation of objects whose types are unknown - allows subclasses to specify/decide what objects to create |
| Factory used for | - Creating user-interface or game-engine elements - Creating loggers with different configurations - Loading plug-ins dynamically |
| Arithmetic Exception | thrown when exception occurs in arithmetic operation |
| ArrayIndexOutOfBondsException | thrown to indicate illegal index |
| ClassNotFoundException | raised when a class is accessed whose definition is not found |
| FileNotFoundException | raised when a file is not accessible or doesn’t exist |
| IOException | thrown when an input-output operation fails |
| InterruptedException | thrown when a thread that is doing something is interrupted |
| NoSuchFieldException | thrown when a class does not contain the field specified |
| NoSuchMethodException | thrown when a method is accessed that cannot be found |
| NullPointerException | referring to members of a null object. Something parsed into a method is null |
| RuntimeException | exception occurring during runtime |
| StringIndexOutOfBoundsException | thrown by String class methods to indicate that an index representing a position in a String is either negative or greater than size of String. |
| IllegalArgumentException | throw an error argument is of incorrect type etc. |
| IllegalStateException | throw an error or error message when the method is not accessed for the particular operation. |
| Why use concurrency? | - Main thread drives the GUI - Event handlers must respond quickly otherwise they will “hang” the GUI - In Java, screen cannot be updated while event handler runs in the same thread |
| GoF3 Command | pattern used to encapsulate a request with all information needed to execute later - decoupling of call data and call moment, defines: - What method to call - In what object - Using what arguments - And what to do with the return value |
| GoF4 Decorator | pattern used for customising an object at runtime used to attach additional functionality to a single object, not a class, nor all objects, and thus allows to adhere to separation of concerns/single responsibility principle and the open/closed principle. |
| GoF5 Facade | pattern used for providing a unified interface for a larger unit. It hides the implementation of a larger unit behind one interface, and defines a single access point. Used for further decoupling of a system. |
| GoF6 Observer | - ensures loose coupling - when one subject changes, many update automatically - notifies multiple dependent objects |
| GoF7 Strategy | encapsulates different algorithms and allows for exchanging of problem-solving strategies at running time. Provides an extension point for adding more strategies to resolve a problem. Interface, since it enables for calling an algorithm independently |
| GoF8 Iterator | a design pattern that defines access to elements in an aggregate object, without exposing underlying design , and allows for iterating through elements in a defined order. used instead of a loop over an array, could be a different data structure |
| GoF9 Template | design pattern which allows for implementation of extensible skeleton for an algorithm, with subclasses serving as literal “extensions”, adding additional/varying functionality depending on the context. |
| GoF10 State | separates state-dependent behaviour into own, referenced units with a fixed number of states, of which only one can be active at a time —> a set of triggers causes specific state changes. Used for game development and state machines. |
Created by:
mlevi17
Popular Engineering sets