Brainscape's Knowledge GenomeTM

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


See full index

CIA > lesson 2 > Flashcards

lesson 2 Flashcards

1
Q

typically refers to the bigger structures of a software
system, and it deals with how multiple software processes cooperate to carry out
their tasks.

A

Software Architecture

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

provides a design plan that describes the elements of a system, how
they fit, and work together to fulfill the requirements of the system.

A

Software design

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

It comes before the detailed design, coding, integration, and testing and after the
domain analysis, requirements analysis, and risk analysis.

A

Software design

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

Components of software architecture (5)

A
  1. Design
  2. Business Strategy
  3. Quality Attributes
  4. IT Environment
  5. Human Dynamics
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

provides a solution that the technical team can create
and design for the entire application.

A

Software Architect

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

A software architect should have expertise in the following areas

A

• Design Expertise
• Domain Expertise
• Technology Expertise
• Methodological Expertise

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

is a measure of excellence or the state of being free
from deficiencies or defects.

A

Quality

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

are the system properties that are separate
from the functionality of the system.

A

Quality attributes

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

Reflect the structure of a system and organization, directly related to
architecture, design, and source code.

A

Static Quality Attributes

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

Reflect the behavior of the system during its execution. They are directly
related to the system’s architecture, design, source code, configuration,
deployment parameters, environment, and platform.

A

Dynamic Quality Attributes

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

specify how to prevent a fault from becoming a failure.

A

Quality scenarios

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

Parts of Quality Scenarios (6)

A

• Source
• Stimulus
• Environment
• Artifact
• Response
• Response measure

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

Defines the consistency and
coherence of the overall design. This
includes the way components or
modules are designed.

A

Category:
Design Qualities
Quality Attribute: Conceptual Integrity

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

Ability of the system to undergo
changes with a degree of ease.

A

Category: Design Qualities
Quality Attribute: Maintainability

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

Defines the capability for
components and subsystems to be
suitable for use in other applications.

A

Category: Design Qualities
Quality Attribute: Reusability

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

Ability of a system or different systems to operate
successfully by communicating and exchanging
information with other external systems written and run by
external parties.

A

Category: Run-time Qualities
Quality Attribute: Interoperability

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

Defines how easy it is for system administrators to manage
the application.

A

Category: Run-time Qualities
Quality Attribute: Manageability

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

Ability of a system to remain operational over time.

A

Category: Run-time Qualities
Quality Attribute: Reliability

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

Ability of a system to either handle the load increase
without impacting the performance of the system or the
ability to be readily enlarged.

A

Category: Run-time Qualities
Quality Attribute: Scalability

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

Capability of a system to prevent malicious or accidental
actions outside of the designed usages.

A

Category: Run-time Qualities
Quality Attribute: Security

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

Indication of the responsiveness of a system to execute
any action within a given time interval.

A

Category: Run-time Qualities
Quality Attribute: Performance

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

Defines the proportion of time that the system is
functional and working. It can be measured as a
percentage of the total system downtime over a
predefined period.

A

Category: Run-time Qualities
Quality Attribute: Availability

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

Ability of the system to provide
information helpful for identifying and
resolving issues when it fails to work
correctly.

A

Category: System Qualities
Quality Attribute: Supportability

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

Measure of how easy it is to create test
criteria for the system and its
components.

A

Category: System Qualities
Quality Attribute: Testability

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

Defines how well the application meets
the requirements of the user and
consumer by being intuitive.

A

Category: User Qualities
Quality Attribute: Usability

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

Accountability for satisfying all the
requirements of the system.

A

Category: Architecture
Quality
Quality Attribute: Correctness

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

Ability of the system to run under
different computing environment.

A

Category: Non-runtime Quality
Quality Attribute: Portability

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

Ability to make separately developed
components of the system work correctly
together.

A

Category: Non-runtime Quality
Quality Attribute: Integrality

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

Ease with which each software system can accommodate changes to its software.

A

Category: Non-runtime Quality
Quality Attribute: Modifiability

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

Cost of the system with respect to time to
market, expected project lifetime & utilization
of legacy.

A

Category: Business quality
attributes
Quality Attribute: Cost and schedule

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

Use of systems with respect to market
competition.

A

Category: Business quality attributes
Quality Attribute: Marketability

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

also called an architectural pattern, is a set of principles which
shapes an application. It defines an abstract framework for a family of systems in terms
of the pattern of structural organization.

A

Architectural Style

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

Prescribes use of a software system that can receive and send messages using one or more communication channels.

A

Category: Communication
Architectural Design: Message Bus

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

Defines the applications that expose and consume functionality as a service using contracts and messages.

A

Category: Communication
Architectural Design : Service-Oriented Architecture (SOA)

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

Separate the system into two applications, where the client makes requests to the server.

A

Category: Deployment
Architectural Design: Client/Server

36
Q

Separates the functionality into separate segments with each segment being a tier located on a physically separate computer.

A

Category: Deployment
Architectural Design: 3-tier or N-tier

37
Q

Focused on modeling a business domain and defining business objects based on entities within the business domain.

A

Category: Domain
Architectural Design: Domain Driven Design

38
Q

Breakdown the application design into reusable functional or logical components that expose well-defined communication interfaces.

A

Category: Structure
Architectural Design: Component Based

39
Q

Divide the concerns of the application into stacked groups (layers).

A

Category: Structure
Architectural Design: Layered

40
Q

Based on the division of responsibilities of an application or system into objects, each containing the data and the behavior relevant to the object.

A

Category: Structural
Architectural Design: Object Oriented

41
Q

Types of Architecture (4)

A

•Application (software) architecture
•Business architecture
•Information architecture
•Information technology (IT) architecture

42
Q

Defines the strategy of business, governance, organization,
and key business processes within an enterprise and focuses on the analysis and design
of business processes

A

Business architecture

43
Q

Serves as the blueprint for individual application
systems, their interactions, and their relationships to the business processes of the
organization.

A

Application (software) architecture

44
Q

Defines the logical and physical data assets and data
management resources

A

Information architecture

45
Q

Defines the hardware and software
building blocks that make up the overall information system of the organization.

A

Information technology (IT) architecture

46
Q

Architecture Design Process (4)

A

• Understand the Problem
• Identify Design Elements and their Relationships
• Evaluate the Architecture Design
• Transform the Architecture Design

47
Q

Consider how the application may need
to change over time to address new requirements and challenges, and build in the
flexibility to support this

A

Build to Change Instead of Building to Last

48
Q

Use design tools, visualizations, modeling
systems such as UML to capture requirements and design decisions.

A

Reduce Risk and Model to Analyze

49
Q

Efficient
communication of the design, the decisions, and ongoing changes to the design is
critical to good architecture.

A

Use Models and Visualizations as a Communication and Collaboration Tool

50
Q

Start with baseline architecture and then
evolve candidate architectures by iterative testing to improve the architecture.
Iteratively add details to the design over multiple passes to get the big or right
picture and then focus on the details.

A

Use an Incremental and Iterative Approach

51
Q

Key Architecture Principles (4)

A

• Build to Change Instead of Building to Last
• Reduce Risk and Model to Analyze
• Use Models and Visualizations as a Communication and Collaboration Tool
• Use an Incremental and Iterative Approach -

52
Q

Divide the components of system into specific features so
that there is no overlapping among the components functionality.

A

Separation of Concerns

53
Q

Each and every module of a system should have one
specific responsibility, which helps the user to clearly understand the system.

A

Single Responsibility Principle

54
Q

Any component or object should not have the
knowledge about internal details of other components.

A

Principle of Least Knowledge

55
Q

Minimize large design upfront if the requirements of
an application are unclear. If there is a possibility of modifying requirements, then
avoid making a large design for whole system.

A

Minimize Large Design Upfront

56
Q

Do not repeat functionality specifies that
functionality of components should not to be repeated and hence a piece of code
should be implemented in one component only.

A

Do not Repeat the Functionality

57
Q

Inheritance
creates dependency between children and parent classes and hence it blocks the free
use of the child classes.

A

Prefer Composition over Inheritance while Reusing the Functionality

58
Q

Identity components and the
area of concern that are needed in system to satisfy the requirements. Then group
these related components in a logical layer, which will help the user to understand the
structure of the system at a high level.

A

Identify Components and Group them in Logical Layers

59
Q

Understand how components
will communicate with each other which requires a complete knowledge of
deployment scenarios and the production environment.

A

Define the Communication Protocol between Layers

60
Q

Various components will interact with each other
through data format.

A

Define Data Format for a Layer

61
Q

Code related to security,
communications, or system services like logging, profiling, and configuration should be
abstracted in the separate components.

A

System Service Components should be Abstract

62
Q

Defining exceptions in
advance, helps the components to manage errors or unwanted situation in an elegant
manner.

A

Design Exceptions and Exception Handling Mechanism

63
Q

Naming conventions should be defined in advance. They provide
a consistent model that helps the users to understand the system easily.

A

Naming Conventions

64
Q

Key Design Principles

A

• Separation of Concerns
• Single Responsibility Principle
• Principle of Least Knowledge
• Minimize Large Design Upfront
• Do not Repeat the Functionality
• Prefer Composition over Inheritance while Reusing the Functionality
• Identify Components and Group them in Logical Layers
• Define the Communication Protocol between Layers
• Define Data Format for a Layer
• System Service Components should be Abstract
• Design Exceptions and Exception Handling Mechanism
• Naming Conventions

65
Q

A software architecture design must conform to the major functionality and
performance requirements of the system, as well as satisfy the non-functional
requirements such as reliability, scalability, portability, and availability.

A

Architecture Models

66
Q

UML is one of object-oriented solutions used in
software modeling and design.

A

UML (Unified Modeling Language)

67
Q

Architecture view model represents
the functional and non-functional requirements of software application.

A

Architecture View Model (4+1 view model)

68
Q

ADL defines the software architecture
formally and semantically.

A

ADL (Architecture Description Language)

69
Q

It is a pictorial language used to make
software blueprints.

A

UML (Unified Modeling Language)

70
Q

UML stands for

A

Unified Modeling Language

71
Q

was created by Object Management Group (OMG).

A

UML (Unified Modeling Language)

72
Q

The UML 1.0 specification draft was proposed to the OMG in

A

January 1997.

73
Q

It serves as a standard for software requirement analysis and design documents which
are the basis for developing a software.

A

UML (Unified Modeling Language)

74
Q

can be described as a general purpose visual modeling language to visualize,
specify, construct, and document a software system.

A

UML Unified Modeling Language

75
Q

is generally used to model software system, it is not limited within this
boundary.
It is also used to model non software systems such as process flows in a manufacturing
unit.

A

UML Unified Modeling Language

76
Q

represent the static aspects of a system. These static aspects
represent those parts of a diagram which forms the main structure and is therefore
stable.

A

Structural Diagrams

77
Q

parts of a Structural diagram (6)

A

• Class diagram
• Object diagram
• Component diagram
• Deployment diagram
• Package diagram
• Composite structure

78
Q

capture the dynamic aspect of a system. Dynamic aspects
are basically the changing/moving parts of a system.

A

Behavioral diagrams

79
Q

parts of a Behavioral diagram (7)

A

• Use case diagram
• Sequence diagram
• Communication diagram
• State chart diagram
• Activity diagram
• Interaction overview
• Time sequence diagram

80
Q

was designed by Philippe Kruchten to describe the architecture of a
software–intensive system based on the use of multiple and concurrent views.

A

4+1 View Model or Architecture View Model

81
Q

It standardizes the software design documents and makes the design easy to understand
by all stakeholders.

A

4+1 View Model or Architecture View Model

82
Q

It is a __ view model that addresses different features and concerns of the system.

A

multiple view

83
Q

The 4+1 View Model was designed by __ to describe the architecture of a
software–intensive system based on the use of multiple and concurrent views.

A

Philippe Kruchten

84
Q

4+1 View Model provides four essential views

A

• The logical view or conceptual view
• The process view
• The physical view
• The development view

85
Q

is a language that provides syntax and semantics for defining a software
architecture. It is a notation specification which provides features for modeling a
software system’s conceptual architecture, distinguished from the system’s
implementation.

A

Architecture Description Language (ADL)

86
Q

must support the architecture components, their connections, interfaces, and
configurations which are the building block of architecture description.

A

Architecture Description Languages (ADLs)

87
Q

It is a form of
expression for use in architecture descriptions and provides the ability to decompose
components, combine the components, and define the interfaces of components.

A

Architecture Description Languages (ADLs)

CIA (2 decks)

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