CSS 422 - Software Architecture Flashcards

1
Q

Software Architecture is

A

description of the subsystems or components of a software system and the relationships between them

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

A more formal description of Software Architecture is

A

Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution

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

What four common, recurring themes make up software architecture?

A

System
Structure
Environment
Stakeholder

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

System

A

A collection of componenets organized in specific ways to achieve specific functionality

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

Environment

A

A context or circumstance in which a software system is built and has a direct influence on its architecture

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

Structure

A

A set of elements that are grouped or organized together according to a guiding rule or principle

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

Stakeholder

A

A person or group of persons who has an interest or concern in a system and its success

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

An Architecture of a system is best represented as

A

structural details of the system.

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

Deployment architecture is strongly connect to the quality attributes of

A

scalabililty, performance, security, and interoperability

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

An architecture

A

Defines a structure
Picks a core set of elements
Caputures early design decisions
Manages stakeholder requiremenets
Influences the organizational structure
Is influenced by its environment
Documents the system
Conforms to a pattern

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

Architectural patterns

A

certain patterns and sets of styles for system architecture that have had success in practice

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

Examples of architectural patterns

A

client-server
pipes
filters
data-based architectures

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

Why create a formal Architecture

A

Every system already has an architecture, whether formal or not, so you can’t have a system without also having an architecture

documenting the architecture allows it to be shared

Makes changes and iterative development possible

Makes the system extensible and modifiable

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

Technical architect

A

Technical architect is concerned with the core technology used in an organization

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

Security architect

A

a Technical architect that tunes the security strategy used in applications to fit the organizations information security goals

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

Information architect

A

A technical architect that comes up with the architecture to make information available to/from applications in a way tha tfacilitates the organizations business goals

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

System architect

A

is worried about how the core system architecture maps to the software and hardware architecture and the various details of human interatctions with the components in the system

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

Enterprise architect

A

is concerned with how the different elements in an organization and their interplay is tuend twoards achieveing the goals of the organization in an efficient manner.

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

Software design

A

A blueprint of the details at the implementation level of the various subsystems and components that make up those subsystems

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

Modifiability

A

a software quality attribute

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

quality attribute

A

A measurable and testable property of a system which can be used to evaluate the performance of a system within its prescribed environment with respect to its nonfunctional aspects

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

nonfunctional requirements

A

global constraints that describe how a system should operate.

ex: things like speed, reliability, data integrity, etc.

The opposite of functional requirements like.

like: this needs to be able to access the database and pull back information on billing accounts

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

quality attributes

A

modifiability
testability
scalability
availability
security
deployability

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

modifiability

A

the ease with which changes can be made to a system and the flexibility with which the system adapts to such changes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
testability
how much a software system is amenable to demonstrating its faults through testing
26
scalability
a system's capacity to accommodate increasing workload on demand
27
performance
the amount of work accompmliished by a system using a given unit of computing resource. higher the work/unit ratio, the higher the performance
28
availability
the property of readiness of a software system to carry out its operations when the need arises
29
security
the degree of ability of a system to avoid damage to its data and logic from unauthenticated access
30
deployability
the degree of ease with which software can be taken from the development to the production environment
31
coupling
the degree of interdependence between software modules high coupling means that the modules are closely connected and changes in one module may affect other modules ------------ it can also be defined as the number of dependencies that modules share between them
32
cohesion
the degree to which elements within a module work teogether to fulfill a single, well-defined process the degree to which the elements belong together
33
the aspects of modifiability
readability modularity reusability maintainability
34
readability
the ease with which a program's logic can be followed and understood
35
modularity
the software is written in well-encapsulated modules which do very specific, well documented functions
36
reusability
the number of parts of a system (including tools, designs, code, and others) that can be reused in other parts of the system
37
maintainability
the ease and efficiency with which the system can be updated and kept working in a useful state by its stakeholders
38
aspects of readability
well written - uses simple syntax and well known features. logic is clear and concise. module and variable names are meaningful well documented - good comments (inline). also, represenets external documents for configuration or api usage well formatted - follows style guidelines
39
"Pythonic" =
keeping up with th eZen of Python
40
antipatterns
coding practices that contribute to unreadable code
41
list the antipatterns
code with little or no comments code that breaks best practices for the language programming antipatterns: -- spaghetti code -- big ball of mud -- copy-paste programming -- ego programming python antipatterns -- mixed indentation -- mixed string literal types --overuse of functional constructs (map(), reduce(), filter(), lambda(), etc)
42
Ways to document code
Inline documentation * comments * function documentation * module documentation Extermal documentation Readme, INSTALL, CHANGELOG User manuals * formal documents created bya adedicated person or team
43
Ways to document in Python
Inline comments Function docstring (with notes about the parameters): @params, @returns Class docstrong Module docstring
44
PEP 8
Python Enhancement Proposal A coding and style guide for Python
45
cohesion
how much the code within a module is aligned; i.e., a measure of how well the code is about the same thing
46
coupling
a measure of how much a module's code relies on code from another module
47
Interface
the modules functions classes or methods that provide a connection / interface to the module Can be thought of as the API of the module
48
python module variables that are not part of the module interface
If the variables are not meant to be accessed by an external program, they should be preceded by a double underscore: ___
49
abstraction
Abstraction is used to hide the internal functionality of the function from the users User is familiar with that "what function does" but they don't know "how it does." so the class Square(): can let you instantiate a square = Square() object without having to understand how to draw it, or without having to tell the computer how to draw it for each step. The square class does it for you. The square class has abstracted away the details
50
abstract common services
so if module B uses services from module A, then those services are abstracted services from module A Because Module B can't see how those modules are built -- it only knows how to use those services
51
Using inheritance techniques
another strategy for modifiability If there is code that is similar, it might be easier to user inheritance to pass along the common functions instead of keeping similar functions hard-coded into each successive class super() method in Python
52
Using Late Binding Techniques
another strategy for modifiability plugin mechanisms broker/registry lookup services notification services deployment time binding using creational patterns
53
Unit testing
the most fundamental type of testing performed by developers. A unit test applies the most asic unit of software code - typically, functions or class methods - by using executable assertions which check the output of ht eunit being tested against an expected outcome
54
python unit testing software
py.test - a full-featured, mature testing framework nose2 - a third party unit-testing module for python unittest - a unit testing module in the standard python library
55
unittest module provides these object
Test cases test fixtures test suites test runners test results
56
pytest
will automatically find tests with any function prefixed with the word "test_"
57
nose 2
a third-party unit-testing module available for python
58
code coverage
the degree to which the source code under test is covered by a specific test suite. ideally test suites should aim for higher code coverage, as this would expose a larger percentage of the source code to tests and help to uncover bugs
59
Lines of Code (LOC)
a percentage of the subroutines (functions) covered by a test suit
60
how are code coverage metrics reported?
by lines of code (LOC)
61
doctests
Inline tests in a function , class or module documentation which add a lot of value by combining code and tests in one place without having to develop or maintain separate test suites
62
silent testing
you can't see the details of the test, you only learn whether all of the tests passed - no output is produced
63
white box testing
testing that involves knowing the exact way something is coded. usually done by the develpers. i.e., they know exactly how something is coded - they have access to the source code, so they know what the code should do, and can find out immediately why it has broken
64
Examples of Code Documentation
Inline documentation External documentation user Manuals
65
Scale vertically or scale up
When the system scales by either adding or making better use of resources inside a computer node (such as CUP or RAM)
66
Scale horizontally or scale out
when a system scales by adding more compute nodes to it
67
Scalability
The degree to which a software system is able to scale when compute resources are added
68
Concurrency
The amount of work that ets done simultaneously in a system
69
Performance of a system
a function of its software and of its hardware capabilities
70
performance
the degree to which a system is able to meet its throughput and/or latency requirements in terms of the number of transactions per second is known
71
Software Performance Engineering
develops performance models early in the SDLC and uses results from those models to modify the software design and architecture to meet performance requirements in multiple iterations
72
Performance Engineering Lifecycle
performance is a non-functional requirement the PEL parallels the steps in the SDLC with every step the performance is improved
73
Stress testing tools
these tools are used to supply workload to the system under test - simulating peak worloads in and burst loads (of very high traffic)
74
Load generators
Stress testing tools
75
Stress testing tools examples
httpperf ApacheBench Loadrunner apache Jemeter Locust
76
Monitoring tools
these tools work with the application code to generate performance metrics such as the time and memory taken for functions to execute, number of functioncalls made per request-response loop and the average and peak times spent on each function
77
Instrumentation tools
trace metrics and track events such as exceptions track details as the line number where the exception occurred and the timestap, and environment fo the appplication
78
code or application profiling tools
these tools generate statistics about functions, frequency of duration of calls, time spent on each function call this allows the developer to find critical sections of code where the most time is spent and allowing them to optimize those sectionsP
79
Python standard library instrumentation and profiling modules
profile cProfile
80
Performance complexity of code
How a routine or function responds to input size typically in terms of the time spent in executing the code
81
Big O Notation AKA:
Backhmann-landau notation Asymptomatic notation
82
the letter O
the rate of growth of a function with respect to input size -- also called th eorder of the function
83
real time
the actual wall-clock time that elapsed for an operation
84
user
the amount of actual CPU time spent within the process in user mode
85
Sys
the amount of CPU time spent executing system calls within the kernel for the program
86
Total CPU time =
user + sys time
87
amortized analysis of algorithms
takes into account both the lower and upper end of the time taken for executing algorithms and gives the programmer a realistic estimate of the average time spent