Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

Software Design > SW - Oral Exam > Flashcards

SW - Oral Exam Flashcards

(96 cards)

Start Studying
1
Q

3 rules of composition

A
  • the whole can’t exist without the parts
  • each part may only be in one composite at any one time
  • composition generally heteromeric (i.e., mixed types)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Aggregation - 3 attributes

A
  • Aggregate (child) may exist without constituent objects (even though this may seem weird)
  • At any time, objects may be constituents of two or more aggregates
  • Aggregation tends to be homeomeric - i.e., of uniform type
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

0, 1, or infinity principle

A

Multiplicity
Always indicate multiplicity
Avoid “” as a multiplicity - use 0..””, 1..”*” , etc. as appropriate

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

Behavior diagrams?

2 types?

A

Show operations represented with states, transitions, and guards

State diagrams
o Shows the operation of a single sequential process

Activity diagrams
o Designed for concurrent processes

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

What are 3 Views used to depict the structure of the architecture?

A
  • Module views show how the system is structured as a set of code units.
  • Component-and-connector (C&C) views show how the system is structured as a set of elements with runtime behaviors and interactions.
  • Allocation views show how the system relates to non-software structures in its environment.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Deployment Views

A

The deployment view shows how the software elements of a system are deployed to the hardware elements.

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

RPC vs REST

A

RPC - directs requests to procedures/ APIs

  • more about the actions
  • used to communicate across the different modules to serve user requests

REST (Representational State Transfer) - directs requests to resources

  • works with the resources
  • it is a simple way to organize interactions between independent systems
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Tiered computing

A

Multilayer client-server, where intermediate layers preprocess client requests and/or postprocess server responses: e.g.,

  • preprocessing of requests: client authentication; translation of client request from a format the client uses to a format that the server requires
  • postprocessing of responses: translation of server response from a format the server uses to a format that the clent requires
  • both: using cached responses at intermediate hosts along client-server communication path to reduce request latency
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Broker

A
  • Allows for dynamic bending between client and server provider
  • Less overhead and more performance than Proxy

A form of tiered computing where an intermediate host, the broker, intercepts the initial request, then puts a client in direct contact with a server

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

Proxy

A
  • Shields server(s) from dynamic binding
  • More secure than Broker

Allows an object to substitute for another object, fielding requests on the second object’s behalf

A form of tiered computing where an intermediate host, the proxy, handles all communication between client and server

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

MVC

A

A form of tiered computing where the intermediate layer, the controller, resides on the server and handles all communication between UIs (views) and a back-end dataset (model)

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

MVP

A

like MVC, except that the controller, now referred to as a presenter, resides on the client

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

Tiered computing?

Examples?

A
  • Generalization of client-server computing
  • uses intermediate layers or levels of logic to address specialized concerns, typically pertaining to business rules or implementation
  • servers provide services by acting as clients to lower-level services

Classic example: middleware
• User application calls middleware service:
e.g., ASP.NET, PHP, CORBA
• Middleware service authenticates user, calls underlying database – whatever

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

Classic client-server vs. broker, proxy

A

simplicity: more straightforward than broker or proxy
performance: requires no initial or intermediate communication with front-end request manager

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

Broker vs. client-server

A

Flexibility, scalability: allows service provider to route all requests to any server at the start of a dialogue

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

Broker vs proxy

A

Performance: less overhead for multi-message dialogues
Proxy is more security: hides server(s) from client throughout dialogue

Same
o Both are forms of tiered computing

Different
o Broker is an internal host which intercepts the initial request that puts clients in direct contact with the server
o Proxy handles all communication between the server and the client

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

Proxy vs client-server

A

Flexibility, scalability: allows service provider to route any requests to any server AT ANY POINT in a dialogue

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

Proxy vs broker

A

security: hides server(s) from client throughout dialogue

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

Shared data viewtypes

A

Commonality: support many-to-many communication via a common store

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

C&C types (3)

A

Request-response-based viewtypes
• What they have in common
all provide (asymmetric) service from a responder to a requestor: i.e.,
• Requestor sends request in form of message
• Some back-end service provider responds to the request
• How they differ
How the message is communicated to the service provider
Basic principle: adding intermediaries for managing communications adds flexibility, at a cost of additional overhead
• Classic client-server
• Tiered computing
• Broker
• Proxy

Shared data viewtypes
•	Commonality: support many-to-many communication via a common store
•	Differences involve
	How participating entities obtain content from the store: i.e.,
•	Via pull / polling  (repository)
•	Via push (blackboard)
	How content in the store is named
	How content in the store persists:  i.e., whether it's automatically removed after being communicated to participating entities
•	Repository
•	Tuple space
•	Blackboard
•	Model-View-Controller 
•	Publish-subscribe
•	Distribution tree

Other
Pipe and filter
Peer-to-peer

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

Module viewtypes

A

module: code unit that covers set of responsibilities
e. g.: collection (package) of classes, class, layer, function

depicts static system composition

Types
•	Layered
•	Decomposition
•	Use
•	Generalization
•	Aspects
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Allocation viewtype

A

mapping of software units to environment where software resides:
e.g., hardware, development team, file system.

Types
• Deployment style: where modules will be physically deployed
• Work assignment style: what modules will do what work
less detailed than work breakdown structures
• Implementation style: where module codes will be stored

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

MVC

A

Model
o The app’s content
o Repository and resides on a server. “What it is.”

View
o The app’s appearance.
o Shows repository context and resides on the client. “What it looks like.”

Controller
o The app’s functionality
o Resides on server. “What it is.”

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

MVC vs MVP

A

Same
o Controllers reside on servers. Presentation resides on clients
o Both have models and views to display output

Differ in leveling
o Passive MVP is layered
o MVP uses a presenter instead of a controller which instead resides on the client.
o MVC is leveled (the model communicates changes to views directly)
o With MVC, the interm layer is the controller which resides on a server and handles all communication between the views and models
o The strategy is to determine if it’s more feasible for the brain to be on the client or the server

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Repository vs Publish-Subscribe
Same o Both share communication Different o Publish-subscribe supports a 1-way flow of message for publishers to subscribers o Shares multiple ways
26
Publish-Subscribe vs Distribution Tree
Same o Both support messages from publisher to subscriber Different o Distribution tree has a tiered backend distribution service that eliminates potential bottleneck at server due to massive number of clients
27
Blackboard vs Repository
Similar o Both support communication by multiple processes Different o Repository: the processes are through a shared persistent store which is passive o Blackboard: the store is active and changes to the blackboard trigger events in process
28
Code-first development
* Involves modeling the application entities using code, or an ORM * Preferred when developers are not interested in the database or the database is expected to have a short lifetime
29
Data-first development
* The classic strategy for implementing a database * The data models are developed first * Suggested if the developers have experience in database design
30
REST's Put vs Post
* Put – used for creating a new response | * Post – used for updating an existing source
31
Constantine's | Functional cohesion hierarchy
• Functional - 1 well-defined task, strongest type of cohesion • Sequential - 1 sequence of subtasks for 1 well-defined task o sequence of tasks to get to a single outcome. Add A+B then add B+C • Communicational - 1 set of subtasks for 1 well-defined task • Procedural - 1 sequence of subtasks across 2 or more tasks • Temporal – 1 set of concurrent subtasks across 2 or more tasks o tasks that are loosely related within a routing and are together due to timing • Logical - multiple, superficially related tasks o tasks within a routine that make logical sense, but don’t make functional sense • Coincidental - multiple, unrelated tasks o tasks that are not related at all and are within the same function for no reason
32
Constantine's | Coupling hierarchy
``` From loosest (best) to tightest (worst) First four cases: function interface characterizes all sharing ``` * Null – where routines don’t share data – loosest coupling * Data – only a single data is being passed between routines * Stamp – an entire structure is shared, including data that’s not needed * Control – sharing of parameters that direct behavior * External – sharing of external storage such as a database. It’s best not to create a copy, but instead should pass data * Common – data shared between the namespace. This can affect other functions if the data is changed. * Global – sharing via global variables * Content coupling – where routines are aware of each other’s implementation – strongest coupling
33
Relationship between tiered computing and the client-server architecture style
Client server - may have one or multiple distributed servers. o The architecture assumes the client either knows types, locations of servers, or can discover these before initiating servers. o Has emphasis on request-response based processing with backend service providers Tiered computing – a generalization of client-server o Uses intermediate logic/levels of logic to address specialized concerns. Example is middleware o Uses a multilayer client-server where intermediate layers preprocess client requests and/or postprocess server responses
34
Krutchen | 4+1 computer architecture
* Logical – models end user viewpoint (functional, UML class) * Development – programmer’s static viewpoint (implementation, UML package) * Process – programmer’s dynamic viewpoint (dynamic behavior, UML activity) * Physical – system engineers (typology of components, UML deployment)
35
Wirfs-Brock, McKean 2 components of Responsibility-Driven Design
* Actors = candidates | * Responsibilities = what they do
36
Wirfs-Brock, McKean What are the 6 actors and responsibilities?
* Information holder - object that primarily knows facts * Structurer - pools, collects, manages other objects, presenting coherent views of groupings * Service provider - provides special skills or computation * Controller - makes decisions, directs others' actions * Coordinator - manages actions of groups of workers, relaying information and calling on others to act * Interfacer - bridges naturally disjoint components
37
5 essential characteristics of an object
* Identity * Behavior * Lifetime * Interface * State
38
Model inheritance
* Reflects is-a relations between abstractions in a model | * May be the only valid reason for employing inheritance
39
Variation inheritance
* Describing a class in terms of differentiating with another class * Can be useful for defining a new version of a package in terms of an existing version
40
Software inheritance
* Expresses relations in a software system, with no obvious counterpart in a “real-world” model * This form of inheritance typically involves a private base class
41
Encapsulation
* aggregates related logic and data in a single syntactic entity * limits to a single entity
42
Common Use Principle
If one method is used in a class, all methods should be used for classes  a class's methods should be used together.  If you use one of a class's methods, you should use all. for components  a component’s modules should be used together.  If you use one of a component’s modules, you should use all.
43
Common Closure Principle
All classes should each be closed independent of other classes ``` for classes  a class's methods should be closed w.r.t. common changes.  a change to a class should affect all its methods and no other classes ``` for components  a component’s modules should be closed w.r.t. common changes.  a change to a component should affect all its modules and no other components
44
Bridge
* Structural pattern | * Allows different implementations to handle the choices of a database and notification mechanism
45
Builder
* Creational pattern * Breaks the construction of an object into parts, and decouples the construction of a part from the logic that makes it * Creates a complex object from a set of part types to make up a (virtual) environment
46
Prototype
• Uses an existing object as a basis for instantiating an object
47
Decorator
* Has just one object attached at each level of hierarchy | * Active
48
Composite
* Has 0…* object(s) attached at each level of hierarchy | * Passive
49
Flyweight
* Allows sharing of state within groups of related objects, such as individuals sharing a battle scene * Reduces memory demands for large pools of objects
50
Adapter
Acts as a wrapper allow it to be used by various operating systems
51
Builder vs Composite
Similar o Both are creational objects Different o Builder composes static objects o Composite composes dynamically varying objects
52
Adapter vs Façade
Similar o Both are known as isolation layers Different o Adapter represents an underlying API o Façade deliberately simplifies it
53
Factory vs Abstract factory
Different o Factory generates multiples of one thing o Abstract factory generates a collection of related objects
54
Page-Jones COTS
Commercial off-the-shelf (COTS) components
55
Page-Jones Expiration of COTS?
* Average half-life of COTS expertise – 6 months | * Max shelf life – 2 years
56
Page-Jones What drives availability for Component-Level software design?
Marketplace
57
What are the 4 types of COTS components – in order of increasing availability?
* Application-specific components – lowest * Business components – low * Architecture components – high * Foundation components – most common, highest
58
What's the criteria to determine whether to create components in-house?
* Key principle - #3 or more reuses” principle * Determine if the cost of creating is cheaper since the cost of COTS Is 1/100th of creating software from scratch * Determine if the increased development time is a factor since the integration will be lower if built in-house
59
FRs
specify outputs as function of inputs
60
NFRs
specify how system is to run o may not be directly observable o may not be tied to any given input or output o may  define overall system attributes  constrain implementation  specify resources or timing o are difficult to  elicit - average users don't know what to say  specify - "X transactions/sec." for X = ??  prioritize - e.g., balancing response, throughput
61
Ideally, NFRs should be, or become...
``` SMART: i.e.,  Specific, non-ambiguous  Measurable  Achievable: i.e., technically feasible  Realistic with respect to resources  Traceable ```
62
What is Barrett's Big 3 | to Categorizing NFRs?
Performance, Cost, Security ```  performance (in time and space) • hardware: mean performance, response time, throughput … • software: mean performance, response time, throughput … ```  cost (w.r.t deployment) • before: development, domain analysis, planning, tracking… • thereafter: operation, maintenance, reengineering, retirement…  security • malicious outsiders • flawed modules
63
SOLID
SOLID is an acronym coined by Robert ‘Uncle Bob’ Martin. It represents the first five principles of object-oriented design and it relates specifically to class design. SRP  The Single Responsibility Principle – A class should have one, and only one, reason to change. OCP  The Open Closed Principle – You should be able to extend a class’ behavior, without modifying it. LSP  The Liskov Substitution Principle – Derived classes must be substitutable for their base classes. ISP  The Interface Segregation Principle – Make fine grained interfaces that are client specific. DIP  The Dependency Inversion Principle – Depend on abstractions, not on concretions.
64
What are 6 Design goals?
* Correct * Complete * Non-ambiguous * Testable * Can be evaluated * Maintainable
65
Meyer Single choice? What is this principle concerned with?
Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. ``` This principle is concerned with • reducing content coupling (via shared expectations for repeated code) • assuring flexibility • assuring concision ```
66
DRY principle
Don’t repeat yourself – the design should be clear and void of repetition
67
What assertions are involved in assuring completeness?
Precondition o What must be true before executes Invariant o What must be true as a code executes
68
Serialization
The exporting of an object’s state that allows an object with an identical state to be constructed
69
Information Hiding
limits access to internal object state to object’s logic
70
Encapsulation
* aggregates related logic and data in a single syntactic entity * limits to a single entity
71
Introspection
the ability of object to query its state and possibly its environment
72
Hybrid Coupling
* Pulling data into multiple sources into a single value * An example is a school class number which limits the amount of available numbers * Another might be a phone number if the area code is glued to the rest of the number
73
Mixed domain cohesion
Grouping of functions in a single class or component that apply to different domains • Examples o A stock market class - a class with functions for  automating retrieval of data from finance.yahoo.com  computing yields  tracking assets' short- and long-term bases … o A real number utility class - a class with operations on  dollars  arctangents  temperatures … * Analogous to coincidental cohesion. * Avoid.
74
Mixed instance cohesion
* When the functions don’t apply to all cases * Instead, should be broken out into subtasks and the specific one called * Example: getCommission is called, but an employee doesn’t get commission
75
Mixed role cohesion
* There are too many roles that make up the class, so all the roles won’t be used * Example: a man can have 0 or many dogs, but why dog and why stop there? Why not cat, elephant, frog, camel…
76
Name 3 types of cohesion
Mixed role Mixed domain Mixed Instance
77
Fan-out
* When one module shares with many sources | * Low fan-out may not pose a problem since it may indicate high cohesion
78
"Tramp data"
* Refers to vertical fan-out * Refers to the bouncing around from function to function * A sign of high dependence inheritance * Addressed by adding an information module between the start and end
79
ANSI/IEEE 1471-2000 definitions Viewpoint? View?
Viewpoint o Set of related concerns (functional/logical, development/structural, user action/feedback) View o Application of viewpoint to system
80
4 types of NFRs
Usability Maintainability Security Reliability
81
When is a request Idempotent?
A request is idempotent where executing a response once has the same effect as executing N times
82
Dependency injection
* The idea is to design a family of objects with common methods to invoke * Invoke method independent of inquiring about types * Parameterize a modules dependencies on other modules
83
RTTI and dependency injection attempt to address a common problem
* Classic alternative to dependency inversion – checks on object’s type at runtime to determine action/choice * Helps ensure the correct type is passed through
84
RTTI vs dependency injection
• RTTI is less maintainable – if, else if, ugly. Should modify to extend a contract set of supported types
85
RTTI
RTTI (Run-time type information) is a mechanism that exposes information about an object’s data type at runtime and is available only for the classes which have at least one virtual function. It allows the type of an object to be determined during program execution
86
Layering vs Leveling Same? Different?
Same both important for testability and clarity Different Layering • A code may ONLY access code at its own level or immediately below Leveling • A code may access code in its own level or any level below it • Use when performance is a concern
87
Content coupling
``` • Coupling via explicit assumptions about how another module operates, rather than what it does • Examples o branching into a second function's code o referencing or changing a second function's local data o dynamically changing a second function's statements o sharing of literals (i.e., compile-time constants) a.k.a. "premature binding" (http://kkspot.110mb.com/Data/CS/sda/module%202.1%20.ppt#297,20) o duplicating logic across modules, under the assumption that the codes will continue to mirror one another ```
88
Laws of Demeter? 2 laws?
It is a bad idea for single functions to know the entire navigation structure of the system * Rationale is to reduce cross object coupling by avoiding designs that read through one object to another * Limit to referencing Laws o Strong law – limits use of inherited content to procedures o Weak law – allows inheritance of any superclass attributes
89
Diagram types?
Structural Behavioral State
90
Examples of Structural Diagrams
``` class object package compound composite structure ```
91
Examples of Behavioral Diagrams
use case, state, activity, sequence, communication
92
4 types of Patterns
Architecture Behavioral Creational Structural
93
Examples of Architecture Patterns
``` client/server component-based domain-driven layered architecture object-oriented (OO) Service-Oriented (SOA) ```
94
Examples of Behavioral Patterns
``` CoR Command Iterator Mediator Memento Observer State Strategy Visitor Template ```
95
Examples of Creational Patterns
Factory, Abstract Factory, Builder, Prototype, Singleton
96
Examples of Structural Patterns
Adapter, Bridge, Composite, Facade, Flyweight, Proxy, Decorator

Software Design (1 decks)

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