Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Software Design > Exam > Flashcards

Exam Flashcards

1
Q

AOP

A

Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to deal with cross cutting concerns

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Cross-cutting concerns

A

Concerns which “cross-cut” the class structure, lowering cohesion and increasing coupling.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

CCC Consequences

A

> Code Tangling

> Code Scattering

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Code Tangling

A

1) Code for CC is mixed with the business logic.

2) Reduces cohesion

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Code Scattering

A

1) Code is duplicated because it is needed in multiple places
2) Reduces coupling

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Lock handling Problem

A

1) Business logic code (put and get) is mixed with concurrency control code resulting in code tangling and poor cohesion
2) Have to add locking code correctly to every business logic code resulting in code scattering
3) Failure to do so would lead to hard to find bugs
4) Need a single, global lock resulting in extra coupling

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Lock handling Pros

A

1) Avoids code scattering and tangling
2) Lock is localised as a private instance variable
3) Reusable simply by writing a new concrete aspect

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

AOP and Design Patterns Pros

A

1) Greater modularisation of concerns
2) Avoid code tangling and scattering
3) Easier software evolution
4) Greater code reuse
5) Easier management (easier to split tasks)
6) Cheaper implementation of new features

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

AOP and Design Patterns Cons

A

1) Program flow is hard to follow
2) Tendency to use CCC everywhere, leading to poor designs
3) Everybody on the team needs to be up to speed with AOP
4) Tools limited to those which support AOP language in use

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

AspectJ

A

1) Java AOP framework
2) Classes and aspects are written separately
3) “woven” together at bytecode generation time
4) Nothing in class code referes to the aspects

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

AspectJ advice kinds

A

> before - code to be executed before the join point
after - code to be executed after join point
around - replaces the code
pointcut - shows where the CC should be applied

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

AOP and Design Patterns

A

1) Observer and Singleton are the only ones who have any benefits
2) Pure fabrications have no sensible inheritance relationships outside the pattern
3) Combing patters will make AOP solutions more problematic

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Advice

A

Additional code that you want to apply to your existing model

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Join point

A

Place where CCC crosscuts the code

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Point cut

A

Point of execution in the application at which cross-cutting concern needs to be applied

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Aspect

A

The combination of the point-cut and the advice

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Iterative process

A

> Assumes you can’t get all requirements right at the start.
Progresses in a set of timeboxed iterations
Phases
Disciplines
Artifacts

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Timeboxed Iteration

A

Means if you don’t get it done you don’t extend the iteration, you change the plan

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Agile UP Phases

A
  1. Inception
  2. Elaboration
  3. Construction
  4. Transition
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

UP Phases [Inception]

A

Initial feasibility study and project go-ahead

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

UP Phases [Elaboration]

A

More detailed study, production of high-risk parts of the system. Iterative except for very small projects.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

UP Phases [Construction]

A

The bulk of the work. Iterative.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

UP Phases [Transition]

A

Acceptance testing, “maintenance” etc.; moving on to the next project.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Disciplines

A

Done through process, not phases

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Disciplines Examples

A

> Requirements
Domain Modeling
Class Design
Coding

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Artifacts

A

> The things you make as part of the process

> The amount of “ceremony” in a project should be appropriate to the scale and nature of the project.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Artifacts Agile approach

A

> Don’t produce more artifacts than you need to

> Don’t make them look pretty unless you have to.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Ceremony

A

Artifacts other than code

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

Use Cases

A

A description of a set of interactions between a system and and one or more actors

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

Use Cases Formats

A

> Brief
Casual
Fully dressed

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Use Case [Brief]

A

A short paragraph describing the MSS.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

Use Case [Casual]

A

The MSS plus short descriptions of the main alternatives

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

Use Case [Fully dressed]

A

Everything spelt out in full detail

34
Q

MSS

A

Main success scenario

35
Q

Agile Principles

A
  1. Minimum ceremony – concentrate on producing working code
  2. Embrace change (especially in requirements)
  3. Constant contact with the customer
  4. Self-organising teams rather than hierarchical management
  5. Physicality, e.g. use physical cards to record requirements
  6. Honesty between developers
36
Q

Agile Manifesto

A
  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan
37
Q

Agile Practices

A
  1. Iterative development
  2. User stories to capture users’ business needs.
  3. Test-driven development
  4. Short code-commit-build cycle
  5. Programming in pairs
  6. Short stand-up meetings
  7. Frequent review of team performance
38
Q

User Stories

A

A short description of something that your customer will do when use software, focused on the value or result they get from doing this thing

  1. Written on physical cards, notes on the reverse
  2. Customer and developers agree on priorities
  3. Broken up into “story points” to generate development tasks (described in developers’ language)
39
Q

GRASP

A

General Responsibility Assignment Software Patterns

> Basic guidelines/principles for assigning responsibilities to classes – the basic skill of OOD

40
Q

GRASP Patterns

A

> (Information) Expert

> Creator

41
Q

GRASP Patterns [Expert]

A

Assign a responsibility to the class that has the information necessary to fulfil the responsibility

42
Q

GRASP Patterns [Creator]

A

Lists likely candidate classes for creating instances of other classes. (special case of expert)

43
Q

High Cohesion

A

A class should represent one well-defined entity

44
Q

Low Coupling

A

A class should not be directly associated with many other classes (but some coupling is necessary).

45
Q

Indirection

A

> Provides means for a class to use another class indirectly
Ability to reference something using a name, reference, or container instead of the value itself
Used to improve coupling and cohesion (occurs in many GoF patterns).

46
Q

Pure Fabrication

A

A class which has no counterpart in the domain
> Database connectors
> Controllers
> Underlying data structures

47
Q

Protected variation

A

Abstract something, so when it varies, it doesn’t affect everything else in a bad way

48
Q

Polymorphism

A

Ability to process objects differently depending on their data type or class

49
Q

Controller

A

A pure fabrication placed between the GUI and the internal logic of the system to decouple them

50
Q

Use Case Controller

A

Controls the actions required in a single use case

51
Q

Façade controller

A

Represents the whole system, e.g. a hardware device.

52
Q

Singleton

A 
> Ensure that only one instance of a class is created
> Provide a global access point to the object
53
Q

Factory

A

> Simplified version of Factory Method
Creates objects without exposing the instantiation logic to the client
Refers to the newly created object through a common interface.
Pure Fabrication

54
Q

Factory Method

A 
> Defines an interface for creating objects, but lets subclasses decide which class to instantiate
> Refers to the newly created object through a common interface
55
Q

Abstract Factory

A

Offers the interface for creating a family of related objects, without explicitly specifying their classes

56
Q

Builder

A 
> Defines an instance for creating an object but letting subclasses decide which class to instantiate
> Allows a finer control over the construction process
57
Q

Prototype

A

Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype

58
Q

Object Pool

A

Reuses and shares objects that are expensive to create..

59
Q

Chain of Responsibility

A

> It avoids attaching the sender of a request to its receiver, giving this way other objects the possibility of handling the request too.
The objects become parts of a chain and the request is sent from one object to another across the chain until one of the objects will handle it.

60
Q

Command

A

> Encapsulate a request in an object
Allows the parameterization of clients with different requests
Allows saving the requests in a queue.

61
Q

Interpreter

A

> Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language
Map a domain to a language, the language to a grammar, and the grammar to a hierarchical object-oriented design

62
Q

Iterator

A

Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation

63
Q

Mediator

A

> Define an object that encapsulates how a set of objects interact.
Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently

64
Q

Observer

A

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

65
Q

Strategy

A

> Define a family of algorithms, encapsulate each one, and make them interchangeable.
Strategy lets the algorithm vary independently from clients that use it

66
Q

Template Method

A

> Define the skeleton of an algorithm in an operation, deferring some steps to subclasses
Lets subclasses redefine certain steps of an algorithm without letting them change the algorithm’s structure

67
Q

Visitor

A

> Represents an operation to be performed on the elements of an object structure
Lets you define a new operation without changing the classes of the elements on which it operates

68
Q

Null Object

A

> Provide an object as a surrogate for the lack of an object of a given type.
Provides intelligent do nothing behavior, hiding the details from its collaborators

69
Q

Adapter

A 
> Convert the interface of a class into another interface clients expect. 
> Lets classes work together, that could not otherwise because of incompatible interfaces
70
Q

Bridge

A

> Decouple an abstraction from its implementation so that the two can vary independently
Publish interface in an inheritance hierarchy, and bury implementation in its own inheritance hierarchy.

71
Q

Composite

A

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

72
Q

Decorator

A

Add additional responsibilities dynamically to an object.

73
Q

Flyweight

A

Use sharing to support a large number of objects that have part of their internal state in common where the other part of state can vary.

74
Q

Memento

A

Capture the internal state of an object without violating encapsulation and thus providing a mean for restoring the object into initial state when needed.

75
Q

Proxy

A

> Provide a surrogate or placeholder for another object to control access to it

76
Q

Coupling Types

A

> Internal coupling

> External coupling

77
Q

Internal Coupling

A

Coupling within a subsystem - the amount of relationships between classes in the system

78
Q

External coupling

A

Coupling between subsystems

79
Q

Design Pattern

A

Template best practice solution for a particular situation

80
Q

Why design patterns are important?

A

1) Encourages best practice
2) Learning tool for new software developers
3) Communication tool between developers, making developing faster and easier

81
Q

Unified Process

A

An approach to developing business application software using agile techniques and concepts yet still being linear and having somewhat waterfall model timeline.

Software Design (2 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions