Brainscape's Knowledge GenomeTM

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


See full index

CS6310 Sofware Architecture > SWEBoK Design > Flashcards

SWEBoK Design Flashcards

1
Q

Software Design

A

activity in which requirements are analyzed in order to produce a description of the software’s internal structure that will serve as the basis for its construction

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

Two Main Activities of Design

A
  • Architectural Design

- Software Detailed Design

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

Wicked Problem

A

A problem with no definitive solution

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

General Design Concepts

A

Form of Problem Solving

Also includes goals, constraints, alternatives, representations, and solutions

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

Architectural Design

A

High-Level Design

describes how software is organized into components

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

Detailed Design

A

describes the desired behavior of architectural components

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

Design Principle

A

Key notations that provide the basis for many different design approaches and concepts.

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

Abstraction

design principle

A

a view of an object that focuses on information relevant to a specific purpose and ignores the remainder of information.

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

Coupling

design principle

A

a measure of the interdependence among modules in a computer program

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

Cohesion

design principle

A

a measure of the strength of association of the elements within a module

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

Decomposition and Modularization

design principle

A

means that large software systems are divided into a number of smaller named components having well-defined interfaces that describe component interaction.

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

Encapsulation and Information Hiding

design principle

A

means grouping and packaging the internal details of an abstraction and making those details inaccessible to external entities

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

Separation of Interface and Implementation

design principle

A

involves defining a component by specifying a public interface that is separate from the details of how the components is realized

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

Sufficiency, Completeness

design principle

A

means ensuring that a software component captures all the important characteristics of an abstraction and nothing more

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

Primitiveness

design principle

A

means the design should be based on patterns that are easy to implement

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

Separation of Concerns

design principle

A

“area of interest with respect to a software design”

an area of design that is relevant to one of more of its stakeholders.

Separating concerns by views allows interested stakeholders to focus on a few things at a time and offers a means of managing complexity

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

Key Issues in Design

A

Issues that must be dealt with in designing software

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

Concurrency

key issue

A

decomposing software into processes, tasks, and threads and dealing with related issues of efficiency, atomicity, sychronicity, and scheduling

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

Control

key issue

A

concerned with how to organize data add control flow

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

Handling Events

key issue

A

concerned with how to handle reactive and temporal events through various mechanisms such as implicit invocation and call-backs

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

Data Persistence

key issue

A

how to handle long-lived data

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

Distribution of Components

key issue

A

how to distribute the software across the hardware (including local and network), how the components communicate, and how middleware can be used to deal with heterogeneous software

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

Error and Exception Handling and Fault Tolerance

key issue

A

how to prevent, tolerate, and process errors and deal with exceptional conditions

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

Interaction and Presentation

key issue

A

how to structure and organize interactions with users as well as the presentation of information

(eg. separation of presentation and business logic using MVC)

NOTE: This does not specify user interface details

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

Security

key issue

A

how to prevent unauthorized disclosure, creation, change, deletion, or denial of access to information and other resources.

also how to tolerate sec-related attacks or violations by limiting damage, continuing service, speeding repair and recovery, and failing and recovering securely

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

Software Structure and Architecture

A

“the set of structures needed to reason about
the system, which comprise software elements,
relations among them, and properties of both”

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

Architectural Structures and Viewpoints

architecture

A

Different high-level facets of a software design
can be described and documented.

(Facet) View: “A view represents a partial
aspect of a software architecture that shows specific properties of a software system”
Views pertain to distinct issues associated with software
design.

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

Logical View

A

satisfying the functional requirements

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

physical view

A

distribution issues

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

development view

A

how the design is broken down into implementation units
with explicit representation of the dependencies
among the units

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

Architectural Styles

architecture

A

“a specialization of element and relation types, together with a set of
constraints on how they can be used”

provides the software’s high-level organization

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q 
General structures
(major architectural style)
A

How programs in software are structured to handle problems

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

Distributed systems

major architectural style

A

Software distributed over a series of interconnected hardware components whether locally or over a network

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

Interactive systems

major architectural style

A

Software designed around interactions with the user and how data is hidden or loaded (MVC)

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

Adaptable systems

major architectural style

A

Software designed to adapt to the environment it is in or one being migrated to or to changing requirements. Being agnostic.

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

Design Patterns

architecture

A

“a common

solution to a common problem in a given context”

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

3 Lower Level Design Patterns

A

• Creational patterns (for example, builder,
factory, prototype, singleton)

• Structural patterns (for example, adapter,
bridge, composite, decorator, façade, flyweight, proxy)

• Behavioral patterns (for example, command,
interpreter, iterator, mediator, memento,
observer, state, strategy, template, visitor).

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

Architecture Design Decisions

architecture

A

software designers make to make a number of fundamental decisions that
profoundly affect the software and the development process.

decision-based, software affecting

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

Families of Programs and Frameworks

architecture

A

-families of programs, also known as software product lines
-can be done by identifying the commonalities
among members of such families and by designing
reusable and customizable components to account
for the variability among family members.

40
Q

User Interface Design

A

ensuring that interaction between the human

and the machine provides for effective operation and control of the machine

41
Q

General User Interface Design Principles

ui design

A
  • Learnability
  • User familiarity
  • Consistency
  • Minimal surprise
  • Recoverability
  • User guidance
  • User diversity
42
Q

Learnability

ui design principle

A

The software should be easy to

learn so that the user can rapidly start working with the software.

43
Q

User familiarity

ui design principle

A

The interface should use

terms and concepts drawn from the experiences of the people who will use the software.

44
Q

Consistency

ui design principle

A

The interface should be consistent so that comparable operations are activated in the same way

45
Q

Minimal surprise

ui design principle

A

The behavior of software

should not surprise users

46
Q

Recoverability

ui design principle

A

The interface should provide
mechanisms allowing users to recover from
errors

47
Q

User guidance

ui design principle

A

The interface should give
meaningful feedback when errors occur and
provide context-related help to users

48
Q

User diversity

ui design principle

A 
The interface should provide appropriate interaction mechanisms
for diverse types of users and for users with
different capabilities (blind, poor eyesight,
deaf, colorblind, etc.).
49
Q

User Interface Design Issues

ui design

A

Answered by two questions:

• How should the user interact with the
software?
• How should information from the software
be presented to the user?

50
Q

The Design of User Interaction Modalities

ui design

A

User interaction styles can be classified and this category discusses how to approach them.

51
Q

Question-answer

ui interaction

A

The interaction is essentially restricted to a single
question-answer exchange between the user and the software. The user issues a question to the software, and the software returns the answer to the question

52
Q 
Direct manipulation
(ui interaction)
A

Users interact with objects on the computer screen. Direct manipulation often includes a pointing device (such as a mouse, trackball, or a finger on touch screens) that manipulates an object and invokes actions that specify what is to be done with that object.

53
Q 
Menu selection
(ui interaction)
A

The user selects a command from a menu list of commands.

54
Q

Form fill-in

ui interaction

A

The user fills in the fields of a form. Sometimes fields include menus, in which case the form has action buttons for the user to initiate action.

55
Q 
Command language
(ui interaction)
A

The user issues a command and provides related parameters to direct the software what to do.

56
Q 
Natural language
(ui interaction)
A

The user issues a command in natural language. That is, the natural language is a front end to a command language and is parsed and translated into software commands

57
Q

The Design of Information Presentation

ui design

A

Information presentation may be textual or graphical in nature. A good design keeps the information
presentation separate from the information itself

58
Q

Information Presentation Guidelines

ui design

A

• Limit the number of colors used.
• Use color change to show the change of software status.
• Use color-coding to support the user’s task.
• Use color-coding in a thoughtful and consistent way.
• Use colors to facilitate access for people
with color blindness or color deficiency
(e.g., use the change of color saturation and
color brightness, try to avoid blue and red
combinations).
• Don’t depend on color alone to convey
important information to users with different
capabilities (blindness, poor eyesight, colorblindness, etc.).

59
Q

User Interface Design Process

ui design

A

iterative process;
interface prototypes are often used to determine
the features, organization, and look of the software user interface

60
Q

3 Core Activities of User Interface Design

A

• User analysis. In this phase, the designer analyzes the users’ tasks, the working environment, other software, and how users interact
with other people.
• Software prototyping. Developing prototype
software help users to guide the evolution of
the interface.
• Interface evaluation. Designers can observe
users’ experiences with the evolving interface.

61
Q

Localization and Internationalization

ui design

A

means adapting software to the different languages, regional differences, and the technical requirements of a target market

62
Q

Metaphors and Conceptual Models

ui design

A

use metaphors and conceptual models to set up mappings between the software and some reference system known to the users in the real world, which can help the users to more readily learn and use the interface

63
Q

Software Design Quality Analysis and

Evaluation

A

Series of topics used for quality analysis of a software design.

64
Q

Quality Attributes

quality analysis

A

“-ilities”
(maintainability, portability, testability, usability)
and “-nesses”
(correctness, robustness) that contribute to the quality of SW Design

65
Q

Quality Analysis and Evaluation Techniques

quality analysis

A
  • Software design reviews
  • Static analysis
  • Simulation and prototyping
66
Q

Measures

quality analysis

A

used to assess or to quantitatively estimate various aspects of a software
design; for example, size, structure, or quality.

67
Q

2 Types of Quality Analysis Measures

A

• Function-based (structured) design measures: measures obtained by analyzing functional decomposition; generally represented
using a structure chart (sometimes called a
hierarchical diagram) on which various measures can be computed.

• Object-oriented design measures: the design
structure is typically represented as a class
diagram, on which various measures can be
computed. Measures on the properties of the
internal content of each class can also be
computed.

68
Q

Software Design Notations

A

notations that exist to represent software design
artifacts. Some are used to describe the structural
organization of a design, others to represent software behavior

69
Q 
Structural Descriptions (Static View)
(notations)
A

describe and represent the structural
aspects of a software design—that is, they are
used to describe the major components and how
they are interconnected (static view)

70
Q

Architecture description languages (ADLs)

structural notations

A

textual, often formal, languages used to
describe software architecture in terms of
components and connectors

71
Q

Class and object diagrams

structural notations

A

used to represent a set of classes (and objects) and their

interrelationships

72
Q 
Component diagrams
(structural notations)
A

used to represent a set of components (“physical and replaceable part[s] of a system that [conform] to and [provide] the realization of a set of interfaces” [18]) and their interrelationships

73
Q

Class responsibility collaborator cards
(CRCs)
(structural notations)

A

used to denote the names of components (class), their responsibilities, and their
collaborating components’ names.

74
Q 
Deployment diagrams
(structural notations)
A

used to represent a set of (physical) nodes and their interrelationships, and, thus, to model the physical aspects of software

75
Q

Entity-relationship diagrams (ERDs)

structural notations

A

used to represent conceptual models of data stored

in information repositories.

76
Q

Interface description languages (IDLs)

structural notations

A

programming-like languages used to define the interfaces (names and types of exported operations) of software components.

77
Q 
Structure charts
(structural notations)
A

used to describe the calling structure of programs (which modules call, and are called by, which other modules).

78
Q 
Behavioral Descriptions (Dynamic View)
(notations)
A

describe the dynamic behavior of software systems and
components. Many of these notations are useful mostly, but not exclusively, during detailed design. Moreover, behavioral descriptions can include a rationale for design decision such as how a design will meet security requirements.

79
Q

Activity diagrams

dynamic notations

A

used to show control flow from activity to activity. Can be used to represent concurrent activities

80
Q

Communication diagrams

dynamic notations

A

used to show the interactions that occur among a group

of objects; emphasis is on the objects, their links, and the messages they exchange on those links.

81
Q

Data flow diagrams (DFDs)

dynamic notations

A

used to show data flow among elements. A data flow diagram provides “a description based on modeling the flow of information around a network of operational elements, with each element making use of or modifying the information flowing into that element” [4*].

Data flows (and therefore data flow diagrams) can be used for security analysis, as they offer identification of possible paths for attack and disclosure of confidential information

82
Q

Decision tables and diagrams

dynamic notations

A

used to represent complex combinations of conditions

and actions.

83
Q

Flowcharts

dynamic notations

A

used to represent the flow of
control and the associated actions to be
performed.

84
Q

Sequence diagrams

dynamic notations

A

used to show the interactions among a group of objects, with emphasis on the time ordering of messages passed between objects

85
Q

State transition and state chart diagrams

dynamic notations

A

used to show the control flow from state to state and how the behavior of a component changes based on its current state in a state machine.

86
Q

Formal specification languages

dynamic notations

A

textual languages that use basic notions from mathematics (for example, logic, set, sequence) to rigorously and abstractly define software component interfaces and behavior, often in terms of pre- and postconditions.

87
Q

Pseudo code and program design languages
(PDLs)
(dynamic notations)

A

structured programming-like languages used to describe, generally at the detailed design stage, the behavior of a procedure or method

88
Q

Software Design Strategies

A

general strategies to help guide the design process

89
Q

Software Design Methods

A

generally provide a set of notations to be used, description of the process to be used, and a set of
guidelines

90
Q

General Strategies

design strategies

A

commonplace strategies followed such as divide-and-conquer and stepwise refinement

91
Q

Function-Oriented (Structured) Design

design strategies

A

decomposition centers on identifying the major software functions and then elaborating and refining them in a hierarchical topdown manner

92
Q

Object-Oriented Design

design strategies

A

inheritance and polymorphism play a key role, to the

field of component-based design

93
Q

 Data Structure-Centered Design

design strategies

A

starts from the data structures a program manipulates rather than from the function it performs

first describes the input and output data structures and then develops the program’s control structure based on these data structure diagrams

94
Q

Component-Based Design (CBD)

design strategies

A

addresses issues related to providing, developing, and
integrating components in order to improve reuse

( component is an independent unit, having well-defined interfaces and dependencies that can be composed and deployed independently)

95
Q

Software Design Tools

A

used to support the creation of the software design artifacts during the software development process

96
Q

What tasks do Software Design Tools support?

A

• to translate the requirements model into a
design representation;
• to provide support for representing functional components and their interface(s);
• to implement heuristics refinement and
partitioning;
• to provide guidelines for quality assessment.

CS6310 Sofware Architecture (7 decks)

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