Brainscape's Knowledge GenomeTM

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


See full index

SWE 6653 > Midterm Prep - Concepts > Flashcards

Midterm Prep - Concepts Flashcards

1
Q
  1. Conceptual Integrity
  2. A basis for reuse of knowledge, experience, design, and code
  3. Effective project communication
  4. Management of “families” of systems
A

Results of Attention to Architecture

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

Architecture must be considered the “heart” of developing a software system, more so than:

A
  1. Processes and methodologies
  2. Programming
  3. Requirements Analysis
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

?-satisfaction of customer needs

  • specialization of labor
  • multiple perspectives of the final product
  • intermediate points where plans and progress are reviewed
A

Similarities to regular architecture

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

?-Software is much newer, so we know much less about it

  • Software does not a have a (physical) “medium” for building and thus is much less “visible” (tangible); this makes it more difficult to measure and analyze than a physical structure
  • Software is more malleable than a physical building; thus changes are more frequently requested because they are (technically) possible, though the later a change occurs the bigger the magnitude of disruption
A

Differences from regular architecture

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

Pipe and FIlter Architecture

A
  • Design/Architecture: components (filters) and relations (pipes)
  • Style: constraint on architecture (flow is “sequential”)
  • Used in shell programming/command line
  • Pipe is a channel that supports the flow of data
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Three “Fundamental” Understandings About Architecture

A
  1. Every software application has an architecture
  2. Software applications can have more than one architect/architecture (these could conflict!)
  3. Software architecture is NOT contained in a phase within the development cycle
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Advantages of Product Family?

A
  • Reuse and cost sharing is the big advantage of common components in Product Family.
  • think: reused interfaces, assets, architectural style, etc.
  • these reused components have already been tested and validated (probably)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

We can have multiple sets of architecture at different times. What are some reasons for different versions?

A
  • Based on modifications as we change our minds
    • Based on modifications as we make corrections
    • Based on modifications as we know more
    • Based on expansion as we evolve an grow, etc
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

-Non-functional requirements are usually done by the solution providers

A

True

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

-The architecture should START at the requirements stage

A

True

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

Connectors may be classified semi-hierarchically by these four attributes: C-T-D-V

A
  • Category : primary service the connector fulfills
  • Type : how the service category is realized
  • Dimensionality : further details of types
  • Values : values the dimensionality can take
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Four categories of connector services? C-C-C-F

A

Communication Services:
• Supports transmission of information among components
Coordination Services:
• Supports transfers of control among components
Conversion Services:
• Transforms the “interactions of control and/or data” required by one
component to that provided by another
Facilitation Services:
• Mediate and streamline (e.g. performance) the component interactions

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

8 connector types? PE SAD LAD

A
  1. Procedure Call
  2. Event
  3. Data Access
  4. Linkage
  5. Stream
  6. Arbitrator
  7. Adaptor
  8. Distributor
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Services provided by procedure call connectors? (3)

A

Coordination Service: flow of control among components (via invocation techniques)
• Communications Service: Transfer of data among interacting components (via
parameters and return values)
• Facilitation Service: Facilitate remote procedure call as a “composite” connector

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

Services provided by Event Connectors? 2

A

• Coordination services: Regulate the flow of control among
components (an event precipitates the flow of control to a component)
• Communication services: transfers data about the event to those
components who are interested or application data

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

Services provided by Data Access Connectors? 2

A

• Communication services: connections to data stores, including
preparation for connection and clean up after access.
• Conversion services: performs any conversion of data formats
and facilitates any access and query mechanisms.

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

Service provided by linkage connector?

A

• Facilitation services: provides the “duct or channel ” to facilitate
communications and coordination of information and enforces the
interaction semantics

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

Service provided by stream connector?

A

• Communication services: provide the transfer of large amounts of
information (data) ; this service combined with data connector can
form a composite connector of database and file storage access.

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

Services provided by arbitrator connector? 2

A

• Facilitation services: resolves any conflict among components and
thus assist and mediate the services among components
• Coordination services: directing and redirecting the control flow
among components

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

Service provided by adaptor connector?

A

• Conversion services: provide facilities to support interactions among
components which were not initially designed to interoperate (e.g.
different operating environment, different languages, etc.).

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

Service provided by distributor connector?

A

• Facilitation services: identifies interaction paths and routing of
communications and coordination information among the
components.

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

“specialized” software components that facilitate

the interactions among “application” software components

A

Software Connectors

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

Composing a software system from “pre-fabricated, heterogeneous”
components may engage in:

A

Complex interactions to Produce complex functionalities

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

Two conceptual building blocks of component interactions?

A
  1. Flow of Control

2. Flow of Information

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

There must a _____, ______, or _____that is used to link the interacting
components; and through this channel flows the control and data
information.

A

channel or duct or medium

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q
  • distinctive role and character in project
  • very broad training
  • leverages extensive experience
  • a keen sense of aesthetics
  • deep understanding of the domain
    • properties of structures, materials, and environments
  • needs of customers
A

Good Architect

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q
  • intellectual control
    • conceptual integrity
    • effective basis for knowledge reuse
    • realizing experience, designs, and code
    • effective project communication
    • management of a set of variant systems
A

-Giving preeminence to architecture offers potential for:

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

How to describe arch effectively?

A
  • Use Models

- Describe RULES

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q
  • Architecture is critical for _________
  • The variable components provide, for each product within the_________, the differentiator features by cost, by time, etc.
  • Reuse and cost sharing is the big advantage of common components in _________.
  • think: reused interfaces, assets, architectural style, etc.
  • these reused components have already been tested and validated (probably)
A

Product Family.

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

When?

A
  • Traditionally: after requirements and during design phase
  • In MODERN Practice: Throughout the development activities and not limited only to the “design” phase
  • The truth is that software architecture:
    a) sometimes starts during the requirements analysis
    b) is given main emphasis during design phase
    c) continues into implementation
    d) is considered during test case analysis and testing
    e) is considered during support maintenance and next release
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Who?

A

-Mainly architects and designers, but may include multiple stakeholders (customer influence?)

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

How?

A

-Using various techniques and past experiences

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

Arch during requirements, new vs old view?

A
  • Traditional View: Understand requirements thoroughly before embarking on a solution
  • Newer View: During requirements analysis, the solution/previous solutions to similar problems are often considered (mentally modeled, prototyped) …does this limit innovation?
    • The architecture should START at the requirements stage
    • Beware not all past solutions are applicable
    • Need to know what IS and ISNT reusable (does it fit application?)
    • Trying out a brand new architecture often causes several “false” starts
34
Q

-Key concept is class/object
1) an abstraction of a main component (with its functionalities and states)
2) the interaction of these classes
-Advantages: mechanisms for reuse (inheritance, polymorphism, etc.)
-Disadvantages: does not model some important concepts, no concurrency, no security and
trust guidance, limited notion of connector, interface, cache, etc.

A

OO Design

35
Q

-Key concept is capturing the best solution and approaches used successfully in the past within
the same application domain.
-Advantages: re-use, especially useful for product family where the next release or other
components are all within the same application domain
-Disadvantages: there is very little guidance with new industry and/or new application domains
where there is no past experience.
-contains a substantial amount of information based on past experiences within the specific application domain.
-it is a combination of:
1. a reference architecture for a specific domain
2. a library of software components containing reusable chunks of domain expertise
3. a method of choosing and configuring components to work within an instance of the
reference architecture

A

Domain Specific Architectural Design

36
Q

Identifying, Describing, Constructing, and Considering

What does this describe?

A

Four most common design decisions

  1. Identification of main components (generally from abstracting requirements)
  2. Describing these main components
  3. Constructing a system configuration
    - Identifying the relationship among components
    - Identifying the dynamic “flow” of control/data
  4. Considering the constraints that need to be placed on the system structure/configuration and possible modifying the system structure/configuration
37
Q

impl techique: _________ directly from a design/architecture tool (may be easiest/best/most faithful way of ensuring architectural accuracy, but limited to special domains)
-Parser Generators

A

-Code generation

38
Q

software that acts as a bridge between the architectural style and a set of implementation technologies. Provides some major architectural/design elements in code and rest requires hand coding.

A

Implementation framework

39
Q

tools that support implementation (mostly limited to communications and networking code such as cross-language remote object call)

A

Middleware

40
Q

the “worst” option, requires most work and has the highest risk of not being faithful

A

Manual hand coding from scratch

41
Q

need to ensure it fits the design/architecture

A

Reuse of existing code

42
Q

Two major testing techniques?

A
  • inspection and review (non-executable)

- running test cases (executables)

43
Q

-Using these testing techniques, we must ensure: (2 things)

A

-architectural consistency and correctness, architectural satisfaction of requirements, especially
that non-functional requirements architecture (connectors and platforms) is supported by the
actual code.
-architectural model derived from the source code matches the original architecture. (This is
almost never done in reality unless there is a maintenance problem.)

44
Q

During maintenance, the motivation is to fix the problem

A

as quickly as possible in the easiest fashion
-Very little or no attention is paid to the original design or architectural consistency, eventually
eroding the overall system to non-maintainability.

45
Q

During evolution, of the software in a product family, the architecture and design should be, but are often not,

A

consulted first to maintain architectural integrity and consistency

- The design document should be modified first and then the code.
- Product evolution should follow an orderly process with consistent architecture
46
Q

Perry & Wolf Definition of Architecture

A
  • Software Architecture = {elements, form, rationale}
  • Elements: the key components that may be a processing, data, or connecting element
  • Form: describes how the elements are composed or organized
  • Rationale: describes the designers’ intent, assumptions, etc.
47
Q
  • Two main types
  • Architectural Drift and Architectural Erosion
  • Product Line and Product Family is a fertile ground for __________
A

architectural degredation

48
Q
  • Processing and States
  • Often derived from functional requirements
  • It can be seen from the outside only through its interface
  • explicitly defined execution context
    • other required components
    • resources such as data files and directories needed
    • required system resources, programming language, etc
    • required hardware configuration
  • often related to some application domain or considered application specific
  • some are common utilities that may be utilized across different application domains
A

components

49
Q
  • Come in many different forms
  • Some simple examples:
    • Procedure call (sync or async and distributed)
    • Shared data access (database or a “global” variable)
    • Adaptor (connect pre-existing components)
A

Connectors

50
Q

Pattern vs Style

-3 key differences

A
  • Scope: style applies to development context while pattern addresses a specific, concrete problem
  • Abstraction: style helps in constraining the decisions but in an abstract way while patterns are parameterized, concrete design decisions
  • Relationship: a pattern may be parameterized and used in multiple styles and a style may use multiple patterns
51
Q

Four stages of design? FPDP

A
  • Feasibility: identifying potential design concepts
  • Preliminary design: selecting and developing the “best” design concept
  • Detail design: Further defining and refining the design concept (providing technical description of the concept)
  • Planning: evaluating and altering (or tuning) the design concept to fit the requirements of software development, production, consumption, and retirement
  • Just like everything else in software architecture, this is not sequential, but most likely iterative
52
Q

identifying potential design concepts

A

Feasibility:

53
Q

selecting and developing the “best” design concept

A

Preliminary design

54
Q

evaluating and altering (or tuning) the design concept to fit the requirements of software development, production, consumption, and retirement

A

Planning:

55
Q

Further defining and refining the design concept (providing technical description of the concept)

A

-Detail design

56
Q
  • Start-up problem: identifying potential concepts could be a problem, and even the key stumbling block
  • People problem: disagreements are more likely as project complexity necessitates multiple architects
  • Complexity problem: for a system that is composed of many heterogeneous components or parts, the complexity of finding an overall system becomes very large and sometimes prohibitive
A

Design Process Concerns

57
Q
  1. looking at the key requirements
  2. mapping functional requirements to major components
  3. relating the components to produce the overall system
  4. analyze the relationships in terms of non-functional required properties (performance, security, reliability, etc)
A

standard design model

58
Q

Cyclical, Parallel, Adaptive, Incremental

A

Four Modes of Design

59
Q
  • often matching some problem component to some abstract model/solution
  • there are different levels of abstraction to consider.
  • Ignoring the details irrelevant to a given perspective
A

Abstraction

60
Q
  • subdividing or decomposing problem into “independent” parts
    - ie functional components and sub-components
    - ie connectors that “interconnect” components
A

Separation of Concern

61
Q

-breaking things down and grouping things up

A

Decomposition/Composition

62
Q

3 Fundamental Architectural Patterns

A
  • State-Logic-Display (3-tier architecture)
  • Model-View-Controller (web application)
  • Sense-Compute-Control (sensor-control-actuator / real time)
63
Q

Architectural Pattern:

  • resembles the 3-tier but focuses more on management of user-interaction
    • model which manages the storage of data
    • view which accepts and displays information to the user
  • controller which aids in the control and modification of the way information is managed between the view and the model
  • some times, esp. in web apps, business logic is placed in the controller
  • e.g. web pages
A

Model-View-Controller MVC

64
Q

Architectural Pattern:

  • Familiar architecture in which:
  • users access business functionalities through a user “display”
  • the business functionalities are provided through the “logic” part
  • the data store keeps all the persistent data or “states,” usually in a database
  • e.g. business apps, multiplayer games, web-based apps
  • the software components may be distributed across hardware
  • in some ways this is the precursor to MVC
A

State-Logic Display

65
Q

Architectural Pattern:
-composed of:
-sensors which send information from various sources
-compute component which receives the information from sensors and performs all the
necessary numerical and logical computations and sends the result as signals to the control
-control which receives the results of the computation from the compute component and
decides how to control the various devices
-e.g. embedded systems

A

Sense-Compute-Control

66
Q
  • Simple
    • Traditional programming language influenced style
    • Layered
    • Dataflow
    • Shared Memory (Shared State)
    • Interpreter
    • Implicit Invocation
    • Peer-Peer
  • More Complex
    • C2 (component and connectors)
    • Distributed Object
A

Architectural Styles

67
Q

Architectural Style:
-based on a “main component” that calls upon functional “sub-components”
-traditional programing paradigm:
-software decomposed into 1) main program and 2) subroutines
-main program calls the subroutine which may in turn call other subroutines
-this gave us the traditional hierarchical style of main and (decomposed) subcomponents
-OO programming paradigm
-software decomposed into objects, one of which may be assumed to play the “main” program
role
-the methods in the objects are invoked much like a procedure call
-the objects are meant to represent the entities in the requirements/application world

A

Traditional Language-Influenced Style

68
Q

Architectural Style:

  • software is decomposed into layers where:
    • each layer may request service of the layer below it, usually immediately below
    • each layer provides the service for the layer immediately above it
  • e.g. OS, virtual machines, client-server (atm)
A

Layered

69
Q

Architectural Style:

  • separate, independent components or programs are executed in some sequential order as data is passed through them to be processed
    • batch sequential processing
      • e.g. old banking systems
    • pipe and filter
      • e.g. Unix shell
A

Dataflow

70
Q

Architectural Style:

  • independent components or programs interact through shared “global” data, often to solve complex problems
    • backboard: applied in AI, determines order of execution of components
    • rule based/expert system: the knowledge base contains facts and rules
  • used in many commercial systems that have a “centralized” database
A

Shared State

71
Q

Architectural Style:
-parse, generate code, execute each command
-dynamic on-the-fly execution of commands maintains the state of the execution
-Basic interpreter: similar to rule-based style, inference engine uses knowledge repository for
parsing the input . e.g. excel formulas, basic interpreter, java interpreter
-Mobile code: transmitting code to remote host for execution
-code on demand
-remote evaluation
-mobile agent (initiator has code and information but lacks resources)

A

Interpreter

72
Q

Architectural Style:

  • Components are invoked indirectly and implicitly as response to some event or notification, (similar to sense-compute-control pattern)
    • publish-subscribe: there is a producer and consumer of information.
  • popular with internet “special news” such as “paid” financial information by industry sector for investors who subscribe to it
  • e.g. online job posting services
  • think, only push
    • event-based: a general case of publish-subscribe
  • independent components communicate solely via sending “events” via an event-bus connector with no designated publisher or subscriber
    - components may react to the receipt of an event or just ignore it
    - events may be processed via push or pull
A

Implicit Invocation

73
Q

Architectural Style:

  • a network of loosely-coupled autonomous components, each may act as a server and a client
  • decentralizes both information and control, unlike client-server
  • issue: resource discovery, bandwidth limitation
  • this ideal situation is usually modified with some amount of centralized control or a directory
    • originally used for sharing files
    • instant message or chat is closest to p2p style
    • other examples: b2b commerce, sensor network
A

Peer-Peer

74
Q

Architectural Style:

  • This style allows various components to be developed independently, but still communicate, interact, and produce the desired results with the help of “connectors” and has the following set of rules:
    • Topological connection rules
      • each component and each connector has a defined top and bottom
      • a component may be attached to only one connector (up/down)
      • arbitrary number of components and connectors may be attached to a connector
      • the top of a component may be attached to the bottom of a connector.
      • the bottom of a component may be attached to the top of a connector.
      • same two rules apply for attaching a set of connectors
    • Message based communication rules
      • all communications between components are via “messages”
      • a message is classified as
        a) a request for performing a service
        b) a notification of information (e.g. returning information)
    • Message flow and Substrate Independence rules
      • all request must flow “upward” in topology
      • all notifications must flow “downward”
    • Interfaces rules
      • each component’s top domain specifies
        a) the set of requests that it may send upward
        b) the set of notifications to which is may react
    • each component’s bottom domain specifies
      a) the notifications it can emit downward
      b) the set of requests to which it responds
A

C2 (Components and Connectors)

75
Q

Architectural Style:

  • an evolution from the C2 style, where components are objects and the connector is much more functionally powerful
    • the objects may run on different hosts
    • the objects may be programmed in different languages
    • the objects provide services through well-defined interfaces
  • the connector acts as the registry/repository of services and facilitates the connections among the objects
A

Distributed Object

76
Q

as problems or infeasible approaches are identified in stages 2-4, the process reverts to an earlier stage

A

cyclical mode:

77
Q

after stage 1, independent alternatives are explored in parallel; at suitable times selection is made between the identified viable alternatives

A

-parallel mode:

78
Q

the next design activity is decided at the end of each given stage, based upon insights gained during that stage

A

adaptive mode:

79
Q

design at each stage of development is treated incrementally

A

-incremental mode:

80
Q

4 widely used distribution connectors

A
  • Event-based
  • Grid-based
  • Client server based
  • Peer-to-peer based

SWE 6653 (2 decks)

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