Software Architecture and Design Concepts

Interfaces

The specification of a software unit's interface describes the externally visible properties of the software unit

What is the Objective of Testing?

(A) To show that a program works (B) To improve the reliability of a program (C) To find defects in the code (D) to protect the end-user (E) To protect the developing community ANSWER: C

Refactoring

"Improves the internal structure of a design (or source code) without changing its external functionality or behavior"

Pure Polymorphism

- Achieved via inheritance and subtyping (derived classes) - Subtyping allows derived classes to be treated as instances of the base class - Pure polymorphism the ability to treat objects of different derived classes as objects of their base class - Dynamic binding: during runtime, the correct method is invoked based on the actual type of the object Polymorphism

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 andobject-based design - Data, actions, or objects are placed together

Specification-based or black-box or closed-box or functional testing

- Functionality of the test objects - No view of code or data structure - input and output only

Design Concepts: Modularity

- Helps development, increments and changes, testing anddebugging, long-term maintenance - Increase cohesion, decrease coupling - Favored by architectural techniques tending to ensure decentralization of modulesSoftware design 41

Code-based or white-box or clear box or glass box or structural testing

- Structure of the test objects is explored -Internal view of code and data structures

Supertype in place of a subtype

- You can substitute a base class object, reference, or pointer inplace of a derived class object when calling functions ormethods

Objected of Test-to-fail (constructive testing)

-Aggressive testing -Testing a feature in every conceivable way possible -Break the software (find faults)

Developing software architecture

-Choose architecture style (e.g., a layered architecture) -Identify components (subsystems) -Identify connectors (how the components willcommunication)

What is a software architecure represented in terms of

-Components -Connectors -Configuration (topology) -Rationale for decomposition, identification, definition

Where do software architectures come from?

-Domain-specific software architectures• -Reference architectures• -Architectural styles -Design Patterns

Software Architecture subtopics

-Organization -how software is decomposed into components -Server organization -technologies that you use to build software

Objected of Test-to-pass (constructive testing)

-Software works minimally -Apply straightforward test cases for correct behavior -Capabiliteis are not pushed -The right way of itnital testing

A test is successful when

A fault is discovered

Normal VB

4n+1 test cases min min+ nominal max- max

NO single-fault assumption

5^n test cases Interested in what happens when more than one variable has an extreme value Also known as Multiple-Fault BV Testing

Robust BV

6n+1 test cases min- min min+ max- max max+

ISO/OSI model

7 Layer organization

Abstract Class

A class with defined methods, but no implementationthat act as a template i.e. shape class where square, circle, rectangle all inherit from it i.e. methods: area

Design Pattern

A design pattern is a general repeatablesolution to a commonly occurringproblem in software design

Robust EC Testing

A few within bounds and someoutside

Fundamental Concepts in Module Design

A function A method A class

Combination of Robust and Multiple-fault assumption

All combinations of 7 valeus for all variables 7^n test cases

Verification

Are we building the product right?

Validation

Are we building the right product?

Functional Testing Ex

BV Testing

When do you fix problems?

Before and druing the development process to IMPROVE the process

Specification based testing

Black Box Testing Functional Testing Mostly to establish confidence

Composability

Build software elements so that they maybe freely combined with others to produce new software

Debugging

Consequence of successful testing

Use of DBMS

Contain information about a particular enterprise Database systems are used to manage collections of data that are lareve, and accessed at the same time

Database Langugaes

Data Defenition Language (DDL) Data Manipulation Language (DML)

Domain-specific software architectures

DSSAs represent the most valuable type of experience useful in identifying a set of alternative arrangements for a design

Comprehensive language

Data definition, schema definition, data manipulation, transaction control, indexing, securityspecification active databases, ..

Decomposability

Decompose complex systems into subsystems

Failure

Departue from teh system's required behavior

Functional Independence

Design concepts: Functional independence• Functional independence Each module has a simple interface

Steps in Choosing Test Cases

Determing Test Cases Selecting Test Cases Defining a Test

EC

Equivalence Class

Blackbox Testing

Equivalence partitioning, boundary value analysis, decision table testing

Information hiding

Every module should be known tothe outside world through an official, "public" interface

Templates in C++

Example stack, slide 7 12b slides

Whitebox testing

Following examples

BV Testing

Impossible to check all input/output combinations: need to choose some

Good Test Case

Identifier Name Purpose Pre-Conditions Inputs Expected Output Observed Outputs Pass/fail

Test Case

Identity and is associated with a program behavior; it also has a set of inptus and expected outputs.

Dijkstra's view on testing

In other words, a program can be proven incorrect by a test, but it cannot be proven correct.

Fault Identification

Is the process of determining what fault(s)caused the failure

What is a software component

It encapsulates a subset of the systems functionality and/or data -Composability, reusability, evolvability

Quality Control

Keep quality at an acceptable level by rejecting unacceptable product

Why we dcompose

Management, modification, understanding

One spec

Many Designs

Relational Model

Mathematical concept based on the ideas of sets

Error

Mistake

Design Pattern Consequences

Modularity Extensibility Customizability Unexpected updates

Temporal

Module's data and functions related because they are used at the same time in an execution

Types of testing

Module, compoennt, or unit

Elements of Design Pattern

Name Problem Solution Consequences

Fault

Occurs when a human makes a mistake

Types of Polymorphism

Overloading, Template functions

Coincidental

Parts are unrelated to one another

Quality Assurance

Process and Design Standards -> Requirements -> Development -> QC Inspection

The HAVING and ORDER clauses; very useful in DS queries

SELECT Major, AVERAGE(GPA)FROM STUDENTWHERE ExpGraduateYr = "2024"GROUP BY MajorHAVING AVERAGE(GPA) >=3.0ORDER BY Major;

SQL command sequence

SELECT, FROM, WHERE

Find the defect by guessing

Scatter debugging throughout the program

DBMS

Set of programs

DBMS Interfaces

Standalone query languages (SQL), Programming interfaces (CLI), user-friendly interfaces.

Whitebox testing

Statement coverage, branch coverage, condition coverage, path coverage, path coverage, dataflow testing

Software Testing is

Static, Dynamic

SQL

Structured Query Language

Objective of testing

TO find faults in teh program

Normal EC testing but no single-fault

Tests within all partitions inside the bounds.

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

Levels of testing

Unit Testing Integration Testing System Testing Acceptance Testing

Code based testing

White/clear/glass box testing structural testing mostly to seek faults

When are two members tightly couples

When they depened a great deal on each other

Formal Proof Techniques

Write assertions and theorems from A1 to An that proves the program works

Generality

a design principle that makes a software unitas universally applicable as possible, to increase thechance that it will be useful in some future system

Separation of concerns

a feature specified by the requirement model

Goal

high cohesion and low coupling

Uniformity acces principle

all code in the same form i.e. a.balance(), balance(a) all instances would be a.balance()

Strong Robust EC Testing

all partitions inside and outside of the ranges

Example of test cases

c1. 1 ≤ a ≤ 200 c4. a < b + c c2. 1 ≤ b ≤ 200 c5. b < a + c c3. 1 ≤ c ≤ 200 c6. c < a + b This defines min and maxes

Polymophism

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

SQL Language

considered one of the major reasons for the commercial success of relational databases

CREATE TABLE

creates table CREATE TABLE table_name ( column1 datatype, column2 datatype, column3 datatype, ....);

Reusability

design for reusability to use parts of the design and implementation in other applications

INSERT

inserts a tuple (row) in a relation (table) Must be in the same order

Coupling

interdependence between different modules low coupling is good

Cohesion

interdependence of elements of one module

pure polymorphism

is a technique used to define the same method with the same arguments but different implementations

Abstraction

present a problem and solution at appropriate levels of abstraction

Fault Correction

process of making changes to the system so that the faults are removed

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

Adapter Pattern

the adapter pattern is a softwaredesign pattern that allows the interface of an existingclass to be used as another interface. It is often used tomake existing classes work with others withoutmodifying their source code."Software design 79

Software Architecture is

the set of principal design decisions made about a system to be developed

When to stop testing

• When you run out of time • When continued testing causes no new failures • When continued testing reveals no new faults • When you cannot think of any new test cases • When you reach a point of diminishing returns • When mandated coverage has been attained