Brainscape's Knowledge GenomeTM

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


See full index

CS6310 Sofware Architecture > Design > Flashcards

Design Flashcards

1
Q

Design

A

deliberate, purposeful planning

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

Engineering

A

Skillful or artful contrivance applying scientific and mathematical principles

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

Craft

A

skilled occupation

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

Art

A

use of skill, taste, and imagination in the production of aesthetic objects

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

What’s the difference between software design and programming

A

Scale - When you’re doing design, it’s typically because you have a Big problem that needs a Big solution

Emphasis on Non Functional Requirements - Programmers may be concerned with things like performance and other things that don’t play a big role.

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

Software Design

A

Building a program while satisfying a problem’s functional requirements and not violating its non-functional constraints

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

Two Phases of Software Design

A
  • Architectural Design

- Detail Design

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

Architectural Design

A

The process of identifying and assigning the responsibility for aspects of behavior to various modules or components of a software

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

Detail Design

A

The process of specifying the behavior of each of the system components that you’ve identified during architectural design

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

Psuedo Code

A

PDL (Program Design Language)

Keywords, free syntax of natural language, data declaration, subprogram definition and calling

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

Structured Programming

A

Sequence, condition, repetition; chunking

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

Flowcharts; call graphs

A

Directed graphs: node is computational unit; arc is flow of control

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

Decision tables

A

Rules, conditions, actions

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

Design Method

A

Systematic sequence of steps that a design team uses to solve a problem
Generally a design method suggests a particular way of viewing a problem (OO views problem from a set of cooperating objects)

Structure Design and Role based design are others.

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

Consequences of testing a design first once the project is done?

A

Not cost or time efficient.

The earlier you find problems, the less expensive they are to fix them.
Especially if you have a design problem and it goes unnoticed until right before release.

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

3 Common Aspects of Design Approaches

A
  1. Method
  2. Representation
  3. Validation
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Design Representation

A

Some kind of review, walkthru, or inspection by a team or tool to validate the design’s legality and legitimacy

18
Q

Independence of Validators

A

Have a team that did the work also do the review can lead to that team being blind from some issues

19
Q

Dependence of Design Validation on Design Method

A

Some methods (Structured Design) list important metrics and other resources that determine how legitimate a design is

20
Q

On-Going vs After-the-Fact

A

When do you do design validation?
On-Going: Do it as you go along, like on a daily or weekly basis review your work and make adjustments

After-the-Fact: Wait for major milestones, perform the review, and then make adjustments

21
Q

Functional Behavior vs Non Functional Constraints

A

Separating the differences between what the application does do vs how the application does it.

22
Q

Specification vs Design

A

Specification/What vs Design/How

Specification lays out What the software should do, the Design process begins to answer How it does that

23
Q

Application Specificity

A

What is it about your particular application that is going to affect the design process?
(Do you have existing resources you want to use to create the software? This affects)

24
Q

Traditional Design Documentation

A

Subcomponents

  • Processes/activities
  • Data / Data flows

Control Flow
- Control Regime

Performance

Resources/Consumption

25
Q

Leonardo Project

A

Project from the 80s that sought to determine what a suitable set of Design information looks like

26
Q

Leonardo Object Additions

A

Stakeholders: their views/interests; work procedures

Issue Base: logged issues as they come up along with their theoretical possible resolutions

Temporal Relations: Versioning, histories, schedules, transformations

Constraints: internal or external

Aggregates: Design or implementation artifacts like config files, packages, and components

27
Q

Design Rationale

A

The reasons one did what they did for a design.

Why someone makes their Design Decisions.

28
Q

Design Decisions

A

Explicit choices of how to trade off two non-functional aspects of a design
(speed vs size)

29
Q

Coupling

A

The extent to which two components depend on each other for successful execution.
(Low coupling is good)

30
Q

Cohesion

A

The extent to which a component has a single purpose or function.
(High cohesion is good)

31
Q

Do “Java packages” support high cohesion or low coupling?

A

Low coupling

32
Q

Does Java inheritance mechanism increase or decrease coupling between the parent and child?

A

Increase coupling

33
Q

Information Hiding

A

Implementing the nitty gritty details behind an Abstraction Interface that the implementer interface with. This allows for devs to change the implementation details more freely.

34
Q

Declarative Abstraction

A

Creating abstraction around what the problem is, and not how to solve it

35
Q

Aggregation Abstractions

A

Arrays, Structs, Objects that are containers pre-defined allowing a dev to avoid implementation themselves

36
Q

Generalization Abstractions

A

Creating objects or classes that allow you to create base functionality ignoring all the special cases

37
Q

Parameterization Abstract

A

Defining explicit parameters helps you abstract away all the possibilities that exist if they were undefined

38
Q

Non-determinism Abstraction

A

Leaving choices unspecified

39
Q

Descartes Design Philosophy

A

Analysis; use of models

40
Q

Marx Design Philosophy

A

Understanding the social context of design solutions; user-centered design

41
Q

Heidegger Design Philosophy

A

tools for accomplishing goals; CASE, IDE

42
Q

Wittgenstein Design Philosophy

A

language games, desktop metaphor

CS6310 Sofware Architecture (7 decks)

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