eecs 348: final exam
microservices/web services: WSDL (web service description langauge)
- XML based definition language - used to describe functionality of a web service
robust BV testing
- beyond extreme values (for robustness) - n variables - 6n + 1 test cases
writing programs: data structures
- carefully design data structures - all programs manipulate data (read, process, store, display) - data structures choices influence a program at every level > improve ability to solve problems abstractly > execution speed > memory requirements > maintenance (debugging, extending, etc.) > improve your ability to analyze your algorithms - goal: simple, elegant code (gauge and improve time complexity)
business issues in cloud platform choice
- cost - developer experience - target customers - service level agreements - portability and cloud migration
design patterns classification
- creational: class -> factory method - structural: class -> adapter - behavioral: class -> interpreter, template method
design concepts: decomposability
- decompose complex systems into subsystems - division of labor
after we have the requirements then what is the next step
- design - bridge from requirements (what we are wanting to do) to code (how) - have to describe what kind of architecture we want
hypervisor, host machine, guest machine
- hypervisor: type of computer software, firmware or hardware that creates and runs virtual machines - host machine: computer on which a hypervisor runs one or more virtual machines is called a host machine - guest machine: each virtual machine is called a guest machine
SaaS design issues: information leakage
- if you have multiple users from multiple organizations, a security risk is that information leaks from one organization to another - there are a number of different ways that this can happen, so you need to be very careful in designing your security system to avoid this
why do we decompose components into smaller components and subsystems
- management (partition effort, clear assignment of requirements to modules) - modification (decouple parts so that changes to one don't affect others) - understanding (allow understanding system one chunk at a time)
microservices/web services: eXtensible markup langauge (XML)
- markup language like html - used for structuring arbitrary data
monolith vs microservices
- microservices architecture solution > API gateway > app need not know what service protocol to use - monolith architecture solution > slow > frequent updates are not practical > when demands increase then hole system has to be scaled > need larger servers
3 aspects in choosing an architecture: architectural styles
- named set of architectural design decisions (that introduce useful qualities in each resulting system) - ex: layered (virtual machines, client server), shared memory, data flow styles (pipe and filters), etc.
normal EC testing but no single fault
- no longer assume single-fault (AKA strong normal EC) - identify equivalence classes of valid values - test cases from cartesian product of valid values - detects faults due to interactions with valid values of any number of variables - have to consider all possible valid cases
normal bv vs robust bv testing
- normal: concerned only with valid value of the input variables - robust: considers invalid and valid variable values
regular expressions
- not as powerful as BNF (e.g., no recursion) - sequence of characters that specifies a match pattern in text - the grammar defined by regular expressions is known as regular grammar - a regular expression is a pattern that can be recognized by a FSM > regular expressions and FSMs are equivalent concepts > semantically the same; one is textual (metal language), one is graphical > anything represented in FSM can be represented in regular expressions - ex: starts with a and ends with a, middle can be a b or c, look at other example in notes
test-to-pass vs test-to-fail
- objective of test-to-pass (constructive testing) > software works minimally > apply straightforward test cases for correct behavior > capabilities are not pushed > the right way of initial testing - objective of test-to-fail (destructive testing) > aggressive testing > testing a feature in every conceivable way possible > break the software (find faults)
cloud computing
- on demand availability and delivery of computing services - components: servers, storage, databases, networking, software, analytics
OO design concepts
- oo methodologies are the most popular and sophisticated design methodologies - a design is object-oriented if it decomposes a system into a collection of runtime components called objects that encapsulate data and functionality - objects are uniquely identifiable runtime entities - objects can be composed (objects within objects through attributes and functions) - objects are reusable - polymorphism
white box testing: condition coverage
- reports the true or false outcome of each Boolean sub-expression, separated by logical-and (&&) and logical-or (||) if they occur - similar to decision coverage but has better sensitivity to the control flow - test each part of compound statement individually - however, full condition coverage does not guarantee full decision coverage (branch coverage)
design concepts: reusability
- reusability: design for reusability to use parts of the design and implementation in other applications - type of reuse > object code (or equivalent) >> ex: sharing dll's between word processor and spreadsheet > classes in source code form >> ex: Customer class used by several applications > assemblies of related classes (or pattern of classes)
when to stop testing
- run out of time - continued testing causes no new failures and reveals no new faults - cannot think of any new test cases - reach a point of diminishing return - mandated coverage has been attained (determine how many statement, branch, condition, or path, tests are required)
characteristics of microservices: highly cohesive
- similar to the concept of cohesive modules during the design - cohesive with respect to a business service - do one thing: a business service
overall activities for quality software
- software testing > static > dynamic - formal specification and verification - technical reviews - software configuration management - software project tracking and control - metrics and measurement
white box testing: decision coverage
- test cases ensure Boolean expressions tested in control structures evaluated to both true and false (also exercises different cases of a "switch" statement) - entire boolean expression is considered one true-or- false predicate regardless of whether it contains logical- and or logical-or operators - does not consider the combination true and false paths, either all true or all false - also known as branch or edge coverage, decision- decision-path
various things as a service
- the idea of a service that is rented rather than owned is fundamental to cloud computing - infrastructure as a service (IaaS) - Platform as a service (PaaS) - Software as a service (SaaS)
design concepts: what are some ways that modules can be dependent on one another (coupling)
- the references made from one module to another - the amount of data passed from one module to another - the amount of control that one module has over the other - coupling can be measured along a spectrum of dependence
design concepts: interfaces
- the specification of a software unit's interface describes the externally visible properties of the software unit - an interface specification should communicate to other system developers everything that they need to know to use our software unit correctly > purpose > preconditions (assumptions) > protocols > postconditions (visible effects) > quality attributes
API
- the way for two programs to communicate - an interface specification - based on some standards: SOAP, RPC, REST - functions will not be public but functionality is
various things as a service: Platform as a service (PaaS)
- this is an intermediate level where you use libraries and frameworks provided by the cloud provider to implement your software - these provide access to a range of functions, including SQL and NoSQL databases - dont have to worry about hardware or operating system but software is yours
implementing a virtual server as a VM
- virtualization technology allows us to install many different types of operating systems
design concepts: separation of concerns
- "concern": a feature specified by the requirement model - lead to software modularity, functional independence, refinement, and aspects
things as a service: examples
- SaaS: photo editing, logistics management - PaaS: cloud management monitoring, database software development - IaaS: storage network, computation virtualization
OO design terminology
- a class is a software module that partially or totally implements an abstract data type - if a class is missing implementations for some of its methods, we say that it is an abstract class - the class definition includes constructor methods that spawn new object instances - building new classes by combining component classes, much as children build structures from building blocks is done by object composition - inheritance - polymorphism
software defects: fault vs failure
- a fault occurs when a human makes a mistake, called an error, in performing some software activities - a failure is a departure from the system's required behavior, occurs when the code corresponding to a fault executes
types of polymorphism: template (generic) classes in c++
- a template class in C++ is a class that allows the programmer to operate with generic data types - also have this in UML
cloud software characteristics: elasticity
- adapt the server configuration to changing demands - related to scalability but also allows for scaling down as well as scaling up - you can monitor the demand on your application and add or remove servers dynamically as the number of users changes - to match the resources allocated with the actual number of resources needed at any given point in time
advantages and disadvantages of SaaS for customers
- advantages: > mobile, laptop, and desktop access > no upfront costs > immediate software updates > reduced software management costs - disadvantages: > privacy regulation conformance (trust they will respect privacy) > network constraints, security concerns > loss of control over updates > service lock in, data exchange
what three facts led to widespread adoption of alternative approach DevOps to traditional handling of software development/release/support
- agile reduced the development time for software, but the traditional release process introduced a bottleneck between development and deployment - amazon re-engineered their software around services and introduced an approach in which a service was developed and supported by the same team - became possible to release software as a service, running on a public or private cloud; software products did not have to be released to users on physical media or downloads
cohesion: functional (ideal degree)
- all elements essential to a single function are contained in one module, and all of the elements are essential to the performance of the function - an adaption of functional cohesion to data abstraction and object-based design - data, actions, or objects are placed together
equivalence class partitioning rationale
- all four variations of boundary value testing are vulnerable to: gaps of untested functionality and redundancy (that results in extra testing effort) - the mathematical notion of an equivalence class can potentially help this because members of a class should be "treated the same" by a program and equiv classes form a partition of the input space - partition deals explicitly with redundancy (elements of a partition are disjoint) and gaps (the union of all partition elements is the full input space) - provides a strategy to resolve the above
types of polymorphism: pure polymorphism
- all the other types are handled at compile time - pure is binding at compile time > dynamic binding > subtyping relationship > if S is a subtype of T, the subtyping relation means that any object of type S can safely be used in any context where an object of type T is expected
microservices architecture
- an API gateway is an API management tool that sits between a client and a collection of services - all components use API to communicate - client (user/software) doesnt need to know that there are separate services -> use API
service-oriented architecture (SOA)
- an architectural style that focuses on discrete services instead of a monolithic design - each service in an SOA embodies the code and data required to execute a complete > ex: checking a customer's credit - SOA architecture is based on other styles
design concepts: coupling
- an indication of the relative interdependence among modules - two modules are tightly coupled when they depend a great deal on each other - loosely coupled modules have some dependence, but their interconnections are weak - uncoupled modules have no interconnections at all; they are completely unrelated
observer design pattern
- an object, named the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods - keep building whenever you need a new observer
container based software
- an operating system virtualization technology that allows independent servers to share a single operating system - way of virtualizing the operating system and run anywhere - in traditional software deployment each new software app will have its own dependencies and some of these will introduce conflicts, container tries to avoid this - libraries and dependencies are included in the container (come as a package) so you can easily move from one machine to another - container can be moved across virtual environments without worrying about the underlying dependencies - new app will come in a container and include all of its dependencies - minimize difficulty with build, ship, deploy, scale - useful for providing isolated application services where each user sees their own version of an application - ex: docker
database ACID
- atomicity, consistency, isolation, and durability - lots of users working on same tables - either all updates are completed or none of them are - database is always consistent - why important? Lost update problem occurs if an otherwise successful update of a data item by a transaction is overwritten by another transaction that wasn't "aware" of the first
how big should a microservice be
- avoid line of code size (lines of code in SQL is not the same as c++) - amazon two rule
writing programs: algorithms
- balance: efficiency vs maintainability - efficiency may have hidden costs > cost to write the code faster > cost to test the code > cost to understand the code > cost to modify the code
main spec-based testing techniques
- boundary value testing - equivalence partitioning - decision table-based testing - special value, random (fuzz) testing
branch coverage vs condition coverage
- branch: cover both true and false possibilities - condition: for every condition, we consider test cases that consider the true and false value independently for each condition, may not necessarily achieve branch coverage > every one of the combinations of true and false for a, b and c has to be considered
design concepts: composability
- build software elements so that they may be freely combined with others to produce new software
cloud software characteristics: resilience
- can design your software architecture to tolerate server failures - can make several copies of your software concurrently available - If one of these fails, the others continue to provide a service - if a given server goes down then the system is ready to switch to another
benefits of SaaS for software product providers
- cash flow: customers either pay a regular subscription or pay as they use the software so you have a regular cash flow - update management: you are in control of updates to your product and all customers receive the update at the same time, avoid several versions being used and maintained at same time, reduces costs and makes it easier to maintain consistent software code base - continuous deployment: can deploy new versions of your software as soon as changes have been made and tested, fix bugs quickly so reliable - payment flexibility: can have several different payment options so that you can attract a wider range of customers - try before you buy: can make early free or low-cost versions of the software available quickly with the aim of getting customer feedback on bugs and how the product could be approved - data collection: can easily collect data on how the product is used and so identify areas for improvement
develop software architecture
- choose architecture style (i.e. a layered architecture) - identify components (subsystems) - identify connectors (how the components will communicate)
design concepts: refactoring
- cleaning the code - reorganization technique > simplifies without changing function > improves internal structure - examine an existing design for redundancy, unused design elements, unnecessary algorithms, etc.
cloud based software
- cloud is a very large number of remote servers that are offered for rent by companies that own these servers - can rent as many servers as you need, run your software on these servers, and make them available to your customers - customers can access these servers from their own computers or other networked devices - may rent a server and install your own software - may pay for access to software products that are available on the cloud
cloud platforms
- cloud platforms include general-purpose clouds such as Amazon Web Services or lesser-known platforms oriented around a specific application, such as the SAP Cloud Platform - there is no 'best' platform and you should choose a cloud provider based on your background and experience, the type of product that you are developing, and the expectations of your customers - you need to consider both technical issues and business issues when choosing a cloud platform for your product
various things as a service: infrastructure as a service (IaaS)
- cloud providers off different kinds of infrastructure service such as a compute service, a network service, and a storage service that you can use to implement virtual servers - you dont have to worry about the hardware
characteristics of microservices: self-contained
- code can be updated without knowing anything about internals of other microservices
code management fundamentals
- code transfer: developers take code into their personal file store to work on it then return it to the shared code management system - version storage and retrieval: files may be stored in several different versions and specific versions of these files can be retrieved - merging and branching: parallel development branches may be created for concurrent working, changes made by developers in different branches may be merged - version information: information about the different versions maintained in the system may be stored and retrieved - git is very helpful with these, branching and merging
code review
- code walkthrough > present code and documentation to review team > team comments on correctness > focus is on the code not the coder > no influence on developer performance - code inspection > check code and documentation against list of concerns > review correctness and efficiency of algorithms > check comments for completeness > formalized process
white box testing
- code-based (structural) testing, glass box, etc. look at all the names - two main types: > control coverage >> statement testing >> branch/decision testing >> condition testing >> MC/DC (Modified Condition/Decision Coverage) testing >> path testing > dataflow coverage
design concepts: achieving functional independence
- cohesion: interdependence of elements of one module - coupling: interdependence between different modules - goal: high cohesion and low coupling -> easier to understand and test
what is a subsystem (component)
- collection of closely interrelated classes - in UML: package and or component design, package for grouping and components for showing a service
robust and multiple-fault assumption
- combination of worst-case and robustness BV testing (AKA worst-case robust BV testing - all combinations of 7 values for all variables - test cases: 7^n - most comprehensive - ex: ranges for 3 variables is 1-200
what aspects should a component suggest/represent
- composability - reusability - evolvability
white box testing: why MC/DC
- compound (multiple, combinatoric) condition testing generates many test cases (2^n), huge number of test cases - instead we have n+1 test cases, n = number of expressions/conditions - happy medium between decision (branch) coverage and compound (multiple) condition coverage
fog computing benefits
- compute layer between the edge and cloud - receives data from the edge before it reaches the cloud Benefits > enables low-latency networking connections between devices > minimizes bandwidth requirements compared to if that data had to be transferred back to a data center or cloud for analysis
debugging
- consequence of successful testing - while testing is planned and systematic, debugging is more of an art > maps symptoms to cause > investigate suspected causes
robust EC testing no single fault
- consider invalid input; do not assume single fault (AKA strong robust EC testing) - identify equivalence classes of valid and invalid values - test cases from cartesian product of all classes - detects faults due to interactions with any values of any number of variables - most rigorous form of EC testing - multiple values and can be invalid values
white box testing: condition coverage concern
- consider the following (fails branch coverage) = if (a && b) S1 else S2; - a==true and b==false and a==false and b==true - both result n exercising S2 (and not S1) - however, if one exercises this code with a and b having all possible combinations of values, (known as compound or multi- condition coverage), condition coverage reports full coverage
docker: containers
- containers are executing images - an image is loaded into a container and the application-defined by the image starts execution - containers may be moved from server to server without modification and replicated across many servers - you can make changes to a Docker container (e.g. by modifying files) but you then must commit these changes to create a new image and restart the container
name 5 external quality factors
- correctness - efficiency - reusability - extendability - portability
why cloud computing?
- cost: avoid the initial capital costs of hardware procurement - startup time: dont have to wait for hardware to be delivered, with cloud you can start in a few min - server choice: if servers are not powerful enough the you can upgrade to more powerful ones - distributed development: if you have a team working from different locations then all members have the same environment and can share information
white box testing terminology
- coverage criteria - subsumption
white box testing: subsumption
- criteria subsumption: A test criterion C1 subsumes C2 if and only if every set of test cases that satisfies criterion C1 also satisfies C2 - must be true for every set of test cases - ex: If a test case set has covered every branch in a program (satisfied the branch criterion), then the test set is guaranteed to also have covered every statement
how to write self-describing programs (modules)
- descriptive identifiers (variables, functions, constants, ...) - prelude comments > precisely but concisely describe what a unit does > include pre- and post-conditions as comments or assertions - clearly describe the expected parameters - appropriate and consistent indentation, line alignment, and use of blank lines to show the relationship between blocks of code > control structures (if-then-else, loops) are especially important
adapter design pattern (structural)
- design pattern that allows the interface of an existing class to be used as another interface - It is often used to make existing classes work with others without modifying their source code - solution in the middle that resolves the differences between two modules - ex: methodA will call methodB
steps in choosing test cases
- determining test objectives > coverage criteria - selecting test cases > inputs that demonstrate the behavior of the code - defining a test > detailing execution instructions
unit testing
- develop test cases and give then to module to see if it handles them correctly - testing individual units
DevOps
- development and operations - speed up the release and support processes - responsibilities are shared - essential to avoid changes made by different developers interfering with each other
traditionally what were the three teams that were responsible for software development, software release and software support
- development team: passed over a final version of the software to release team - release team: built a release version, tested this and prepared release documentation - maintenance/support team: providing customer with support - problem: miscommunication, delays and overheads, etc.
once we have identified the major components and architecture
- divide and conquer - model new system as a set of subsystems
3 aspects in choosing an architecture: reference architecture
- documents that provides recommended structures of products to form a solution - ex: the ISO OSI model is an excellent reference architecture for internet applications
problems with quality control
- does not reduce the number of defects - does not improve the process - does not result in better products - does not motivate improvement - results in adversarial relationships
3 aspects in choosing an architecture
- domain-specific software architectures - reference architecture - architectural styles
characteristics of microservices: autonomous
- each component service in a microservices architecture can be developed, deployed, operated, and scaled without affecting the functioning of other services - any communication between individual components happens via well-defined APIs - microservices architectures make applications easier to scale and faster to develop, enabling innovation and accelerating time-to- market for new features
design concepts: functional independence
- each module addresses a specific subset of requirements - each module has a simple interface
characteristics of microservices: specialized
- each service is designed for a set of capabilities and focuses on solving a specific problem - if developers contribute more code to a service over time and the service becomes complex, it can be broken into smaller services
factors to consider in which design is best
- easy to change algorithm, data representation, and function - good performance - easy to reuse - modularity, testability, security, easy to use, ease of integration, etc. - all of these depend on architecture of the system
edge computing
- edge is about processing data closer to where it's being generated, enabling processing at greater speeds and volumes, leading to greater action-led results in real-time - collect and process data, share timely insights and can take appropriate action - transforming how data generated by billions of IoT and other devices is stored, processed, analyzed, and transported (before/instead of moving to the cloud, running fewer processes in the cloud) - practice of moving computing power physically closer to where data is generated, usually an IoT device or sensor - ex: IoT devices, smart utility grid analysis, IoMT: internet of medical things -> monitor glucose levels, blood pressure levels, etc.
what aspects does a component embody
- encapsulation - modularity - abstraction
flowcharts and flowgraphs
- every program can be representing with a flowgraph - look in notes for more examples with code
DevOps principles
- everyone is responsible for everything - everything that can be automated should be automated, minimal manual involvement in deploying software - measure first change later, collect data about system and use to inform decisions about changing devops processes and tools
technical issues in cloud platform choice
- expected load and load predictability - resilience - supported cloud services - privacy and data protection
external vs internal quality factors
- external quality factors: > determined by factors whose presence or absence may be observed by the users of the software > affect users > used as the ultimate criterion to judge the quality of a system - internal quality: > factors invisible to the end users > help achieve the external quality
fan in and fan out
- fan-in: refers to the number of units that use a particular software unit - fan-out: refers to the number of units used by particular software unit - A: A is highly coupled with a number of other programs
microservices relationship with containers
- faster deployment - flexible scaling - lesser resources
how many more bugs
- fault seeding > intentionally inserts a known number of faults > improved by basing the number of seeds on historical data > improved by using two independent test groups * comparing results
objective of testing
- find faults in a program - test is successful only when a fault is discovered - fault identification is the process of determining what fault(s) caused the failure - fault correction is the process of making changes to the system so that the faults are removed
path testing
- from the top to the end we consider all possible paths - num paths = # edges - # nodes + 2 - number of paths is the number of test cases you would need (test case for each path) - look at other example flow graphs in notes
design patterns
- general repeatable solution to a commonly occurring problem in software design - template to solve similar problems > creational patterns, structural patterns, behavioral patterns - objectives: > high readability and maintainability > high testability > high reusability
microservices: data distribution and sharing
- general rule of microservice development: each microservice should manage its own data - complete data independence is impossible > minimize data sharing > limit to read-only > if data is replicated in database, keep them consistent - database transaction ACID rule apply
quality control
- goal: keep quality at an acceptable level by rejecting unacceptable products - preventing unacceptable products from being released to the customer - emphasis is on finding defects and fixing them after the fact - regulatory process through which we measure actual quality performance, compare with standards, and act on differences
anatomy of a microservice
- has a well defined public API (interface so that one can connect and use, POST and GET)
test case
- has an identity and is associated with a program behavior - also has a set of inputs and expected outputs - good test case can reveal a failure
design concepts: modularity
- helps development, increments and changes, testing and debugging, long-term maintenance - increase cohesion, decrease coupling - favored by architectural techniques tending to ensure decentralization of modules
basics of EC testing
- identify valid and invalid values of all variables - test one invalid variable at a time ** note this makes the single fault assumption
container based virtualization and the cloud
- if you are running a cloud-based system with many instances of applications or services, these all use the same operating system, you can use a simpler virtualization technology called 'containers' - containers accelerates the process of deploying virtual servers on the cloud - containers are usually megabytes in size whereas VMs are gigabytes - containers can be started and shut down in a few seconds rather than the few minutes required for a VM
SaaS design issues: authentication
- if you set up your own authentication system, users have to remember another set of authentication credentials - many systems allow authentication using the user's Google, Facebook or LinkedIn credentials - for business products, you may need to set up a federated authentication system (SSO), which delegates authentication to the business where the user works
functional testing: BV testing (boundary value)
- impossible to check all input/output combinations: need to choose some - rationale: most errors occur at near their extremes (instead of < used <=, counters off by one) - two considerations apply to boundary value testing > are invalid values an issue > can we make the "single fault assumption" of reliability theory - if x has values at the boundary then they are properly handled how many test cases? - assume variable x (a<= x <= b) - extreme values only (fixe test cases - four boundary values and one middle) - if there are n variables then 4n+1 test cases
SaaS design issues: multi-tenant and multi-instance systems
- in a multi-tenant system, all customers are served by a single instance of the system and a multitenant database. - in a multi-instance system, a separate copy of the system and database is made available for each user
fog computing
- individual devices serving as points of contact between users and data sources - they are the nodes between data centers (cloud) and devices (edge)
debugging process
- information collection - fault isolation - fault confirmation - fault correction - fault and correction - regression testing - documentation
database security
- information from all customers is stored in the same database in a multi-multi-tenant system - key security issues are multilevel access control and encryption > multilevel access control means that access to data must be controlled at the organizational level and the individual level > you need to have organizational-level access control to ensure that any database operations only act on that organization's data > encryption of data in a multitenant database reassures corporate users that their data cannot be viewed by people from other companies if some kind of system failure occurs
design concepts: information hiding
- information hiding principle: the designer of every module must select a subset of the module's properties as the official information about the module, to be made available to authors of client modules - information hiding: every module should be known to the outside world through an official, "public" interface - the rest of the module's properties comprises its "secrets" - it should be impossible to access the secrets from the outside
management responsibilities for things as a service
- infrastructure: blue (hardware) - platform: pink - software: green, software already deployed
writing programs: documentation
- internal: programmers put comments in their program's code to help themselves and others understand the code later - external: describe the program (module) and data, catalog keywords for future reuse - documentation should continue after the code has been completed
white box testing: coverage criteria
- involves the execution of all the statements at least once in the source code
standards or coding conventions
- is essential for developer, testers, maintainers - documentation - matching design with implementation (low coupling, high cohesion, well defined interfaces)
microservices/web services: JSON (javascript object notation)
- lightweight format for storing and transporting data - open standard - common format for electronic data interchange
SaaS design issues
- local/remote processing - authentication - information leakage - Multi-tenant and multi-instance systems
3 aspects in choosing an architecture: domain-specific software architectures
- look at other/existing architectures - reference arch for an application domain - represent most valuable type of experience useful in identifying a set of alternative arrangements for a design - ex: looking at other houses for house development, not the same colors, carpet, etc. but same structural elements: floor plan, etc.
cloud software characteristics: scalability
- maintain performance as load increases - reflects the ability of your software to cope with increasing numbers of users - as the load on your software increases, your software automatically adapts so that the system performance and response time are maintained - can be vertical or horizontal (or scaling up or scaling out)
microservices and API
- microservices only rely on each other's public API - avoid component coupling (not through API) - API interfaces may evolve but must remain compatible - microservice cannot access internal functions of another
white box testing: MC/DC
- modified condition/decision coverage - only consider conditions that independently impact of the outcome of a decision - every decision in the program has taken all possible outcomes at least once - for each condition, find two rows in the decision table where the condition changes and outcome changes while other conditions remain the same - it will achieve branch and condition coverage but will not necessarily achieve multiple condition (mcdc subsumes branch and condition coverages) - mcdc weaker than multiple condition
name 5 internal quality factors
- modularity > high cohesion > low coupling - information hiding - abstraction - low complexity - well-defined interfaces
observer design pattern consequences
- modularity: subject and observers may vary independently - extensibility: can define and add any number of observers - customizability: different observers offer different views of subject - unexpected updates: observers dont know about each other
multi instance databases
- multi-instance systems are SaaS systems where each customer has its own system that is adapted to its needs, including its own database and security controls - multi-instance, cloud-based systems are conceptually simpler than multi-tenant systems and avoid security concerns such as data leakage from one organization to another - two types: vm-based or container-based
multi-tenant systems
- multi-tenant database is partitioned so that customer companies have their own space and can store and access their own data - there is a single database schema, defined by the SaaS provider, that is shared by all the system's users - Items in the database are tagged with a tenant identifier, representing a company that has stored data in the system - the database access software uses this tenant identifier to provide 'logical isolation', which means that users seem to be working with their own database
elements of design pattern
- name: describes the pattern, adds to common terminology for facilitating - problem: describes when to apply the pattern - solution: describes elements, relationships, responsibilities, and collaborations which make up the design - consequences: results of applying the pattern, benefits and costs
different types of coupling
- no direct coupling - data coupling (better): communicate by passing data - stamp coupling: modules share the same data structure - control coupling: one module passes control data to dictate the execution of another module - common coupling: sharing global data, bad bc not clear and any one of those models can make changes to those - content coupling (worse): one module modifies content of another module
do you have to decide how an architectural element or component is implemented when designing software architecture
- no rather you design the component interface and leave the implementation of that interface to a later stage of the development process
forms of EC
- normal: classes of valid values of inputs - robust: classes of valid and invalid values of inputs - single fault assumption: one from each class - multiple fault assumption: one from each class in Cartesian product - we compare these for a function of two variables, F(x1, x2) - extension to problems with 3 or more variables should be obvious
BNF (backus-naur-form)
- notation - describe programming langauge - a formal meta language used in defining context-free grammars (i.e. in compiler design) - examples: <terminal> defined as: ::= alternative: | optional: [] combining: () maybe: ? repeated: (..)* also some suggest {..} one or more: (..)+ recursion: <integer> ::= <digit> | <integer><digit> ** some symbols are just for convenience - examples: a fractional part is defined as a period followed by numerical sequence
white box testing: MC/DC example with condition (A && B) || C
- num test cases: > 2^3 = 8 for compound > 3+1 = 4 for mcdc - of this 8 which are the 4 that we need - algorithm: consider one of the expressions A and which row shows that the value of A has changed and the outcome has changed but B and C has not changed -> A causes independently outcome to change, in row 2 and 6 the value of A has changed between the two (B and C has stayed the same) and the outcome has changed as well, this would be two test cases, do this for others as well
how to find how many paths in a flowgraph
- number edges - numbers nodes + 2 - each path has some new edge in it - test cases will force one path to be executed
OO design terminology: polymorphism
- occurs when code is written in terms of interactions with an interface, but code behavior depends on the object associated with the interface at runtime and on the implementations of that object's method - types in c++ > operator and function overloading > template classes > more advanced pure polymorphism (runtime binding)
architecture-centric approach to design
- once you define your requirements then spend some time defining architecture and then you can decide which step to do next - once we have the components we can decide how we are going to get these - example of next options: make, buy, mine, commission (outsource to other company to build)
docker
- open-source project provided a standard means of container management that is fast and easy to use - docker is a container management system that allows users to define the software to be included in a container as a docker image - includes a run-time system that can create and manage containers using these docker images
types of polymorphism: operator and overloading
- operator: can overload +, -, etc. to add objects of the same type together - type compatibility is essential - function: depends on parameters and they determine which function is called
software architecture
- overall organization, how the software is decomposed into components, the server organization, the technologies that you use to build the software - architecture affects its performance, usability, security, reliability and maintainability ex: if you are designed a house, there could be a bunch of different designs which makes some or better than others depending on the problem
writing programs: interpreters
- performing the operations described by the source program
spell checker architecture example
- prep: prepares file, outputs one word per line - sort: sorts output of prep - uniq: eliminates the duplicate words from the output of sort - comm: compares two files, outputs differences, compare output of uniq with personal-dict, output words not in personal-dict, compare output of comm with system dictionary, output misspelled
design concepts: abstraction
- present a problem and solution at appropriate levels of abstraction - procedural abstraction: a sequence of instructions of a specific and limited function, with details of the function suppressed - data abstraction: a collection of data that describes a data object
monolith software development lifecycle
- rectangles are different services
benefits of devops
- reduced communications - faster deployment - reduced risk, releases are smaller so there are less problems to fix - faster repair, work together to repair - more productive teams
design concepts: cohesion
- refers to the dependence within and among a module's internal elements (e.g., data, functions, internal modules) - types of cohesion: > functional (better) > sequential > communication > procedural > temporal > logical > coincidental (worse)
docker: docker hub
- registry of images that has been created - may be reused to setup containers or as a starting point for defining new images
data storage and management issues for SaaS
- regulation > some countries have strict laws on storage of personal information > can be incompatible with laws and regulations of country where SaaS provider is based > If a SaaS provider cannot guarantee that their storage locations conform to the laws of the customer's country, businesses may be reluctant to use their product - data transfer: > If software use involves a lot of data transfer, the software response time may be limited by the network speed > This is a problem for individuals and smaller companies who can't afford to pay for very high-speed network connections - data security: > companies dealing with sensitive information may be unwilling to hand over control of their data to an external software provider > as we have seen from a number of high-profile cases, even large cloud providers have had security breaches > you can't assume that they always provide better security than the customer's own servers - data exchange: > if you need to exchange data between a cloud service and other services or local software applications, this can be difficult unless the cloud service provides an API that is accessible for external use
virtual cloud servers
- runs on an underlying physical computer and is made up of an operating system plus a set of software packages that provide the server functionality required - stand-alone system that can run on any hardware in the cloud, "run anywhere" characteristic possible bc virtual server has no external dependencies - virtual machines VMs, running on physical server hardware, can be used to implement virtual servers > hypervisor provides hardware emulation that simulates the operation of the underlying hardware - if you use a virtual machine to implement virtual servers, you have exactly the same hardware platform as a physical server
cloud software characteristics
- scalability - elasticity - resilience
scalability vs elasticity
- scalability > increasing capacity > available resources exceed to meet future demands > adapts only to workload increase in incremental manner > enables corporate to meet expected demands for services with long term needs - elasticity > increasing or reducing capacity > available resources match current demands > adopts both workload increase and decrease in automatic manner > enables corporate to meet unexpected demands for services with short term needs
characteristics of microservices: loosely coupled
- self-contained: code can be updated independently without knowing anything about internals of other microservices - updating one service doesn't require changing other services
what is a software architecture
- set of principal design decisions made about a system to be developed (blueprint for the system construction and evolution) - software architecture is represented in terms of software components, software connectors, configuration (topology) -> how they are going to be put together, a rationale for the decomposition -> why are we using this arch, identification, or definition of the above - ex: yellow boxes are components, the fact that we have four components was an architectural decision
code management
- set of software-supported practices that is used to manage an evolving codebase - during the development of a software product, the development team will probably create tens of thousands of lines of code and automated tests - lots more files than just code - need code management to ensure that changes made by different developers do not interfere with each other, and to create different product versions
why microservices
- small and independent services that work together - decentralized - deploy independently - modeled around a business domain- Isolate failure - hide internal details (reduce coupling) - instead of building a large complex software product that is expensive and takes time we create microservices
design concepts: small interfaces principle vs explicit interfaces principle
- small interfaces principle: If two modules communicate, they exchange as little information as possible - explicit interfaces principle: Whenever two modules A and B communicate, this is obvious from the text of A or B or both
software services
- software component that can be accessed from remote computers over the Internet - given an input, a service produces a corresponding output, without side effects - the service is accessed through its published interface and all details of the service implementation are hidden - services do not maintain any internal state > state information is either stored in a database or is maintained by the service requestor - do not maintain internal state - when a service request is made, the state information may be included as part of the request, and the updated state information is returned as part of the service result - as there is no local state, services can be dynamically reallocated from one virtual server to another and replicated across several servers
microservices
- software is composed of loosely-coupled small independent services that communicate over well-defined APIs - combined to create applications - make applications easier to scale and faster to develop - UI is divided into many independent pieces - completely independent with their own database and UI management code
SaaS design issues: local/remote processing
- software product may be designed so that some features are executed locally in the user's browser or mobile app and some on a remote server - local execution reduces network traffic and so increases user response speed; this is useful when users have a slow network connection - local processing increases the electrical power needed to run the system
white box testing: compound or multiple condition coverage
- solves issue for concern with condition coverage - test cases for all the possible combinations of outcomes of conditions in a decision (therefore the complete decision table) to be tested (exercised) at least once > as with condition coverage, the sub-expressions are separated by logical-and and logical-or, when present > test cases required for full multiple condition coverage of a condition are given by the logical operator truth table for the condition - some test cases may be unnecessary - 2^n test cases so ok for low number - disadvantage: tedious to determine the minimum set of test cases required, especially for very complex Boolean expressions
specification-based vs code-based testing
- specification-based testing > black-box testing > functional testing > mostly to establish confidence - code-based testing > white-box (clear-box, glass-box) testing > structural testing > mostly to seek faults
test case generation techniques (2 main approaches to testing techniques)
- specification-based, black-box, closed-box, functional testing > functionality of the test objects > no view of code or data structure - input and output only - code-based, white-box, clear box, glass box, structural testing > structure of the test objects is explored > internal view of code and data structures
software component
- subset of the system's functionality and/or data - clear set of functionality/features and interface - can be considered as a collection of one or more services that may be used by other components
what is included in a good test case
- test case identifier (usually a short name for test management purposes) - name - purpose (e.g., a business rule) - pre-conditions (if any) - inputs - expected outputs - observed outputs - pass/fail?
challenges with monolithic software
- too much component coupling - difficult to scale - long build and test cycles - architecture is hard to maintain and evolve - lack of agility and innovation, etc.
writing programs: compiler
- translation of a program written in a source language into a semantically equivalent program written in a target language - has many parts: preprocesser, scanner, parser, etc.
design concepts: generality
- trying to make the code generalized so we can reuse it in the future - a design principle that makes a software unit as universally applicable as possible, to increase the chance that it will be useful in some future system - we make a unit more general by increasing the number of contexts in which it can be used > parameterizing context-specific information - ex: the four procedure interfaces are listed in order of increasing generality
black box vs white box testing
- two different ways to generate test cases so we can test a program - black box: functional testing, only considers the external behavior of the system; the internal workings of the software is not taken into account (equivalence partitioning, boundary value analysis, decision table testing), spec based - white box: testing that takes into consideration its internal functioning, code based testing (statement coverage, branch coverage, condition coverage, path coverage, dataflow testing)
hypervisor type 1 and type 2
- type 1 hypervisor (bare-metal): runs directly on the physical hardware of the host machine (e.g., MS Hyper-V), immediate access to hardware - type 2 hypervisor (hosted): installed on an OS (e.g., MS Virtual PC), intermediate access
design concepts: uniform access
- uniform access principle: a module's facilities are accessible to its clients in the same way whether implemented by computation or storage - use the same notation, etc. - not uniform: a.balance, balance(a), a.balance() - uniform: a.balance - it shouldn't matter to the client whether you look up or compute
common testing organization
- unit testing: testing individual modules and make sure they work - integration testing: modules work fine and then gradually joined together one at a time - function testing: whole system works - performance testing - acceptance testing - installation testing
verification vs validation
- verification: are we building the product right (reviews, walkthroughs, unit test, integration test) - validation: are we building the right product (reviews, system test, acceptance test)
regular expression in unix . ^ $ * \ () ?
- very similar concept, slightly different notation - extremely powerful for pattern matching (vim, grep, sed, ...) - common Unix symbols . replaces any character ^ matches start of string $ matches end of string * matches up zero or more times the preceding character \ represent special characters () groups regular expressions ? matches up exactly one character - look at examples in notes
remote servers
- virtual (implemented in software, not hardware) - many virtual servers can run simultaneously on each cloud hardware node - very powerful hardware to run multiple virtual servers > performance not affected - cloud management software makes it easy to acquire and release servers on demand > if you need resources for only a short time you simply pay for the time that you need
white box testing: statement coverage
- weak coverage, better than nothing - insensitive to some control structures - test cases ensure that each statement in a program P is executed at least once - other names: line coverage, basic block coverage - ex: all statements are executed at least once when taken the ACE path
multiple fault bv testing ? maybe no single-fault
- worst case bv testing - interesting in what happens when more than one variable has an extreme value - for each variable: start with five-element set (min, min+, middle, max-1, max), consider all combinations of 5 values for all variables - 5^n test cases
formal proof techniques
- write assertions to describe input/output conditions - generate theorems to be proven - locate loops and if-then statements and develop assertions for each - identify all paths from A1 to An - cover each path so that each input assertion implies an output assertion - prove that the program terminates
is quality assurance more effective than quality control
- yes - because the emphasis moves to the development process - you attempt to fix problems before and during the development process - you improve the process and therefore reduce the number of defects in a lasting manner
various things as a service: Software as a service (SaaS)
- your software product runs on the cloud and is accessed by users through a web browser or mobile app - hardware and software is taken care of - software products are being delivered as a service, rather than installed on the buyer's computers - If you deliver your software product as a service, you run the software on your servers, which you may rent from a cloud provider - customers don't have to install software and they access the remote system through a web browser or dedicated mobile app - the payment model for software as a service is usually a subscription model (user many monthly fee)
building quality in
-assuring product quality: "building quality in" - a system of methods and procedures used to assure that the software product meets its requirements - software assurance - a planned and systematic pattern of all actions necessary to provide adequate confidence that the product conforms to established technical requirements
IEEE definition of software architecture
fundamental organization of a software system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution
microservices and cloud based software products
if you need to create cloud-based software products that are adaptable, scalable, and resilient then use a microservices architecture
microservices/web services: SOAP (simple object access protocol)
message protocol that enables the distributed elements of an application to communicate
cohesion: communication
module elements operate on the same data set (data structures)
cohesion: temporal
module's data and functions related because they are used at the same time in an execution
cohesion: logical
parts are related only by the logic structure of code
cohesion: coincidental
parts are unrelated to one another
cohesion: sequential
parts of a module are grouped because the output from one part is the input to another (get data from a database, prepare result, return results)
cohesion: procedural
similar to temporal, and functions pertain to some related action or purpose
API gateway
single point of contact and translates service requests from the app into calls to the microservices
if a program does not have any loops, if you do mcdc testing, does that cover multiple condition testing?
yes
