software_engineering.lyx

#LyX 2.1 created this file. For more info see http://www.lyx.org/
\lyxformat 474
\begin_document
\begin_header
\textclass article
\use_default_options true
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman default
\font_sans default
\font_typewriter default
\font_math auto
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\spacing single
\use_hyperref true
\pdf_bookmarks true
\pdf_bookmarksnumbered false
\pdf_bookmarksopen false
\pdf_bookmarksopenlevel 1
\pdf_breaklinks true
\pdf_pdfborder true
\pdf_colorlinks false
\pdf_backref false
\pdf_pdfusetitle true
\papersize default
\use_geometry true
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 0
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 0
\index Index
\shortcut idx
\color #008000
\end_index
\leftmargin 1in
\topmargin 1in
\rightmargin 1in
\bottommargin 1in
\secnumdepth 3
\tocdepth 1
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout Title
Software Engineering
\begin_inset Foot
status collapsed

\begin_layout Plain Layout

\series bold
Disclaimer
\series default
: These notes have been prepared with the 
\series bold
only
\series default
 purpose to help me pass the Computer Science qualifiying exam at the University
 of Illinois at Chicago.
 They are distributed as they are (including errors, typos, omissions, etc.)
 to help other students pass this exam (and possibly relieving them from
 part of the pain associated with such a process).
 I take 
\series bold
no responsibility
\series default
 for the material contained in these notes (which means that you can't sue
 me if you don't pass the qual!) Moreover, this pdf version is distributed
 together with the original LaTeX (and LyX) sources hoping that someone
 else will improve and correct them.
 I mean in absolute no way to violate copyrights and/or take credit stealing
 the work of others.
 The ideas contained in these pages are 
\series bold
not mine
\series default
 but I've just aggregated information scattered all over the internet.
 This work is licensed under a Creative Commons Attribution-NonCommercial-ShareA
like 3.0 Unported License.
\end_layout

\end_inset


\end_layout

\begin_layout Standard
\begin_inset CommandInset toc
LatexCommand tableofcontents

\end_inset


\end_layout

\begin_layout Section
Software lifecycles (academic)
\end_layout

\begin_layout Subsection
Software release lifecycle
\end_layout

\begin_layout Standard
The software release life cycle is composed of discrete phases that describe
 the software's maturity as it advances from planning and development to
 release and support phases.
\end_layout

\begin_layout Description
Pre-alpha: refers to all activities performed during the software project
 prior to system testing.
 These activities can include requirements analysis, software design, software
 development and unit testing.There are several types of pre-alpha versions:
 development releases, nightly builds, milestones, etc.
 
\end_layout

\begin_layout Description
Alpha: in this phase, developers generally test the software using white
 box techniques.
 Additional validation is then performed using black box or gray box techniques,
 by another testing team.
 Moving to black box testing inside the organization is known as alpha release.
 Alpha software can be unstable and could cause crashes or data loss.
 The alpha phase usually ends with a 
\emph on
feature freeze
\emph default
, indicating that no more features will be added to the software.
 At this time, the software is said to be feature complete.
\end_layout

\begin_layout Description
Beta: in this phase, pilot testing is performed by a limited number of end
 users in the target environment.
 The users of a beta version are called beta testers.
 They are usually customers or prospective customers of the organization
 that develops the software, willing to test the software for free or for
 a reduced price.
 
\end_layout

\begin_layout Description
Release
\begin_inset space ~
\end_inset

Candidate: The term release candidate (RC) refers to a version with potential
 to be a final product, ready to release unless fatal bugs emerge.
 In this stage of product stabilization, all product features have been
 designed, coded and tested through one or more beta cycles with no known
 showstopper-class bug.
\end_layout

\begin_layout Description
RTM: The term "release to manufacturing" or "release to marketing" (both
 abbreviated RTM), also known as "gold", is a term used to indicate that
 the software has reached a point that it is ready to or has been delivered
 or provided to the customer.
 RTM happens prior to general availability (GA) when the product is released
 to the public.
\end_layout

\begin_layout Description
GA: General Availability or General Acceptance (both abbreviated GA) is
 the point where all necessary commercialization activities have been completed
 and the software has been made available to the general market
\end_layout

\begin_layout Subsection
Development lifecycles
\end_layout

\begin_layout Itemize
Waterfall model: it's an activity-centered life cycle that prescribes sequential
 executions of subsets of the development processes and management processes
\end_layout

\begin_layout Itemize
v-Model: it's a modification of the waterfall model that makes explicit
 the dependency between development activities and verification activities.
\end_layout

\begin_layout Itemize
Spiral model: is an activity-centered life cycle model that was devised
 to address the source of weaknesses in the waterfall model, in particular
 to accommodate infrequent change during the software development.
 This model focuses on addressing risks incrementally, in order of priority.
\end_layout

\begin_layout Itemize
Unified Software Development Process: distinguishes important time ranges
 in software development called cycles.
 (birth, childhood, adulthood, retirement, death) Each cycle has four phases:
 Inception, Elaboration, Construction, Transition.
\end_layout

\begin_layout Itemize
Issue-based model: based on solving issues that are generated progressively.
 
\end_layout

\begin_layout Itemize
Agile software development: it is a group of software development methodologies
 based on iterative and incremental development, where requirements and
 solutions evolve through collaboration between self-organizing, cross-functiona
l teams.
 e.g.
 Scrum
\end_layout

\begin_layout Section
Requirements elicitation
\end_layout

\begin_layout Subsection
Functional Requirements
\end_layout

\begin_layout Standard
Functional requirements describe the behavior and the interactions of the
 system with its environment independently of its implementation.
 The environment includes the user and any other external system with which
 the system interacts.
 
\end_layout

\begin_layout Subsection
Nonfunctional Requirements
\end_layout

\begin_layout Standard
Nonfictional requirements describe aspects of the system that are not directly
 related to the functional behavior.
 Nonfictional requirements include a broad variety of requirements that
 apply to many different aspects of the system.
 Some nonfunctional requirements categories are: usability, reliability,
 performance, supportability, constraints (implementation requirements,
 legal categories,...).
\end_layout

\begin_layout Subsection
Analysis
\end_layout

\begin_layout Standard
Once the requirement elicitation activity is over the development team focuses
 on the analysis phase.
 Analysis focuses on producing a model of the system, called 
\emph on
analysis model
\emph default
, that is correct, complete, consistent and verifiable.
 The two are different since during this phase the developers focus on structuri
ng and formalizing the requirements elicited from users.
 Doing so leads to new insight and the discovery of errors in the requirements.
 
\end_layout

\begin_layout Standard
The analysis model is composed of three parts: the 
\emph on
functional model
\emph default
, represented by use cases and scenarios, the 
\emph on
analysis object model
\emph default
, represented by class and object diagrams, and the 
\emph on
dynamic model
\emph default
, represented by state machine and sequence diagrams.
 
\end_layout

\begin_layout Subsection
RAD
\end_layout

\begin_layout Standard
The 
\emph on
Requirement Analysis Document
\emph default
 (
\emph on
RAD
\emph default
) is the result of the requirements elicitation (and analysis) activities.
 This document completely describes the system in terms of functional and
 nonfunctional requirements.
 The first part of the document is written during the requirement elicitation
 phase while the second part is completed during the analysis phase.
\end_layout

\begin_layout Section
Design
\end_layout

\begin_layout Subsection
Design principles
\end_layout

\begin_layout Itemize

\emph on
Coupling
\emph default
 is the number of dependencies between two subsystems.
 If two subsystems are loosely coupled, they are relatively independent,
 so modifications to one will have little impact on the other.
 If two subsystems are strongly coupled, modifications to one subsystem
 is likely to have impact on the other.
 
\end_layout

\begin_layout Itemize

\emph on
Cohesion
\emph default
 is the number of dependencies within a subsystem.
 If a subsystem contains many objects that are related to each other and
 perform similar task, its cohesion is high.
 If a subsystem contains a number of unrelated objects, its cohesion is
 low.
 
\end_layout

\begin_layout Standard
When designing a system a good property is that subsystems are as loosely
 coupled as possible (
\emph on
minimize coupling
\emph default
) and as highly cohese as possible (
\emph on
maximize cohesion
\emph default
).
\end_layout

\begin_layout Itemize

\emph on
Layering
\emph default
 allows systems to be organized as a hierarchy of subsystems, each providing
 higher-level services to the subsystems above it by using lower-level services
 from subsystems below it.
\end_layout

\begin_layout Itemize

\emph on
Partitioning
\emph default
 organizes subsystems as peers that mutually provide different services
 to each other.
\end_layout

\begin_layout Subsubsection
Different purposed for classes and inheritance
\end_layout

\begin_layout Standard
Class hierarchies and polymorphism can be used to model both the application
 domain and the solution domain.
 
\end_layout

\begin_layout Itemize

\emph on
Application objects
\emph default
, also called 
\emph on
domain objects
\emph default
, represents concepts of the domain that are relevant to the system.
\end_layout

\begin_layout Itemize

\emph on
Solution objects
\emph default
 represent components that do not have a counterpart in the application
 domain, such as persistent data stores, user interface objects, or middleware.
\end_layout

\begin_layout Standard
In the same way inheritance can be used both to classify analysis object
 into taxonomies or to reduce redundancy and enhance extensibility of the
 software product.
\end_layout

\begin_layout Itemize

\emph on
Specification inheritance
\emph default
 consists of the classification of concepts into type hierarchies.
\end_layout

\begin_layout Itemize

\emph on
Implementation inheritance
\emph default
, instead, is the use of inheritance for the sole purpose of reusing code.
 Usually 
\emph on
delegation
\emph default
 (i.e.
 implementing an operation in a certain class by resending a message to
 another class) is a preferable mechanism to achieve reuse.
\end_layout

\begin_layout Subsubsection
Kent Beck's four rules of simple design
\end_layout

\begin_layout Itemize
Runs all the tests.
\end_layout

\begin_layout Itemize
Expresses every idea that we need to express.
 (intent)
\end_layout

\begin_layout Itemize
Says everything OnceAndOnlyOnce.
 (no duplication)
\end_layout

\begin_layout Itemize
Has no superfluous parts.
 (minimize classes/methods)
\end_layout

\begin_layout Subsection
Architectural styles
\end_layout

\begin_layout Description
Model-View-Controller: View renders data, observing Model, and you can have
 multiple.
 Controller receives user input and makes modifications to Model.
 
\end_layout

\begin_layout Description
Repository: Independent component interact only through the repository.
\end_layout

\begin_layout Description
Multi-tier
\begin_inset space ~
\end_inset

architecture: Each tier is dedicated to a purpose.
 Usually interface, application logic and storage.
\end_layout

\begin_layout Description
Pipes
\begin_inset space ~
\end_inset

and
\begin_inset space ~
\end_inset

filters: Subsystems process data received as inputs and send results to
 other subsystems via a set of outputs.
\end_layout

\begin_layout Description
Client-Server: the server provides services to a client which requires them.
\end_layout

\begin_layout Description
Peer-to-peer: generalization of client server where subsystems are both.
\end_layout

\begin_layout Subsection
Design patterns
\end_layout

\begin_layout Standard
In object-oriented development, 
\emph on
design patterns
\emph default
 are template solutions that developers have refined over time to solve
 a range of recurring problems.
\end_layout

\begin_layout Subsubsection
Creational patterns (5)
\end_layout

\begin_layout Standard
These patterns have to do with class instantiation.
 They can be further divided into class-creation patterns and object-creational
 patterns.
 While class-creation patterns use inheritance effectively in the instantiation
 process, object-creation patterns use delegation to get the job done.
\end_layout

\begin_layout Itemize

\emph on
Abstract Factory
\emph default
 groups object factories that have a common theme.
 
\end_layout

\begin_layout Itemize

\emph on
Builder
\emph default
 constructs complex objects by separating construction and representation.
 
\end_layout

\begin_layout Itemize

\series bold
\emph on
Factory
\series default
 method
\emph default
 creates objects without specifying the exact class to create.
 
\end_layout

\begin_layout Itemize

\emph on
Prototype
\emph default
 creates objects by cloning an existing object.
 
\end_layout

\begin_layout Itemize

\series bold
\emph on
Singleton
\series default
\emph default
 restricts object creation for a class to only one instance.
 
\end_layout

\begin_layout Subsubsection
Structural patterns (7)
\end_layout

\begin_layout Standard
These concern class and object composition.
 They use inheritance to compose interfaces and define ways to compose objects
 to obtain new functionality.
 
\end_layout

\begin_layout Itemize

\series bold
\emph on
Adapter
\series default
\emph default
 allows classes with incompatible interfaces to work together by wrapping
 its own interface around that of an already existing class.
 
\end_layout

\begin_layout Itemize

\emph on
Bridge
\emph default
 decouples an abstraction from its implementation so that the two can vary
 independently.
 
\end_layout

\begin_layout Itemize

\emph on
Composite
\emph default
 composes zero-or-more similar objects so that they can be manipulated as
 one object.
 
\end_layout

\begin_layout Itemize

\emph on
Decorator
\emph default
 dynamically adds/overrides behaviour in an existing method of an object.
 
\end_layout

\begin_layout Itemize

\series bold
\emph on
Facade
\series default
\emph default
 provides a simplified interface to a large body of code.
 
\end_layout

\begin_layout Itemize

\emph on
Flyweight
\emph default
 reduces the cost of creating and manipulating a large number of similar
 objects.
 
\end_layout

\begin_layout Itemize

\emph on
Proxy
\emph default
 provides a placeholder for another object to control access, reduce cost,
 and reduce complexity.
 
\end_layout

\begin_layout Subsubsection
Behavioral patterns (11)
\end_layout

\begin_layout Standard
Most of these design patterns are specifically concerned with communication
 between objects.
 
\end_layout

\begin_layout Itemize

\emph on
Chain of responsibility
\emph default
 delegates commands to a chain of processing objects.
 
\end_layout

\begin_layout Itemize

\series bold
\emph on
Command
\series default
\emph default
 creates objects which encapsulate actions and parameters.
 
\end_layout

\begin_layout Itemize

\emph on
Interpreter
\emph default
 implements a specialized language.
 
\end_layout

\begin_layout Itemize

\series bold
\emph on
Iterator
\series default
\emph default
 accesses the elements of an object sequentially without exposing its underlying
 representation.
 
\end_layout

\begin_layout Itemize

\emph on
Mediator
\emph default
 allows loose coupling between classes by being the only class that has
 detailed knowledge of their methods.
 
\end_layout

\begin_layout Itemize

\emph on
Memento
\emph default
 provides the ability to restore an object to its previous state (undo).
 
\end_layout

\begin_layout Itemize

\series bold
\emph on
Observer
\series default
\emph default
 is a publish/subscribe pattern which allows a number of observer objects
 to see an event.
 
\end_layout

\begin_layout Itemize

\emph on
State
\emph default
 allows an object to alter its behavior when its internal state changes.
 
\end_layout

\begin_layout Itemize

\emph on
Strategy
\emph default
 allows one of a family of algorithms to be selected on-the-fly at runtime.
 
\end_layout

\begin_layout Itemize

\emph on
Template method
\emph default
 defines the skeleton of an algorithm as an abstract class, allowing its
 subclasses to provide concrete behavior.
 
\end_layout

\begin_layout Itemize

\emph on
Visitor
\emph default
 separates an algorithm from an object structure by moving the hierarchy
 of methods into one object.
\end_layout

\begin_layout Section
Object Oriented Design
\end_layout

\begin_layout Itemize

\emph on
Aggregation
\emph default
 (vs 
\emph on
composition
\emph default
): 
\end_layout

\begin_deeper
\begin_layout Itemize
In aggregation, A uses B.
 B exists independelty of A.
 
\end_layout

\begin_layout Itemize
In composition A owns B.
 B has no meaninig without A (i.e.
 B is a component of A).
\end_layout

\end_deeper
\begin_layout Itemize

\emph on
Class (vs object)
\emph default
: A class is a written piece of code that defines the behavior of a given
 class.
 An object is an instance of a class obtained through a process of instantiation.
\end_layout

\begin_layout Itemize

\emph on
Class / static initializer
\emph default
: block of code that is used to initialize static members.
 Similar to a 
\begin_inset Quotes eld
\end_inset

constructor for class/static methods/attributes
\begin_inset Quotes erd
\end_inset

.
\end_layout

\begin_layout Itemize

\emph on
Class / static method
\emph default
/attribute: methods that don't belong to any object (i.e.
 instance) but to the class itself.
\end_layout

\begin_layout Itemize

\emph on
Constructor
\emph default
: block of code that is used to inizialize new objects (i.e.
 class instances).
 It's executed every time a new instance is created.
\end_layout

\begin_layout Itemize

\emph on
Delegation / forwarding
\emph default
: is a design pattern where an object, instead of performing one of its
 stated tasks, delegates that task to an associated helper object.
\end_layout

\begin_layout Itemize

\emph on
Dependency Injection (DI)
\emph default
: A desingn pattern that removes hard-coded dependencies (i.e.
 services) from dependent objects (i.e.
 clients).
 The service is made part of the client's state.
 Passing the service to the client, rather than allowing a client to build
 or find the service.
 There are three main ways of injecting dependencies:
\end_layout

\begin_deeper
\begin_layout Itemize
constructor injection: the dependencies are provided through a class constructor.
 
\end_layout

\begin_layout Itemize
setter injection: the client exposes a setter method that the injector uses
 to inject the dependency.
 
\end_layout

\begin_layout Itemize
interface injection: the dependency provides an injector method that will
 inject the dependency into any client passed to it.
 Clients must implement an interface that exposes a setter method that accepts
 the dependency.
\end_layout

\end_deeper
\begin_layout Itemize

\emph on
Dependency Inversion
\emph default
 
\emph on
Principle (DIP)
\emph default
: tells us how to achieve decoupling in software.
 The principle states:
\end_layout

\begin_deeper
\begin_layout Itemize
High-level modules (i.e.
 Client) should not depend on low-level modules (i.e.
 dependencies).
 Both should depend on abstractions.
 
\end_layout

\begin_layout Itemize
Abstractions should not depend on details.
 Details should depend on abstractions
\end_layout

\end_deeper
\begin_layout Itemize

\emph on
Destructor / finalizer
\emph default
: a block of code that is executed every time an object is destroyed / deallocat
ed.
\end_layout

\begin_layout Itemize

\emph on
Encapsulation
\emph default
: boundling data and the functions operating on such data for the purpose
 of restricting access to some data or code (data hiding)
\end_layout

\begin_layout Itemize

\emph on
Inheritance
\emph default
: A mechanism for code reuse to allow extension of the original software.
 Not to be confused with subtyping (Subtyping is described by Is-a relationship,
 while inheritance is pure code reuse).
\end_layout

\begin_layout Itemize

\emph on
Instantiation
\emph default
: The process of creating an object from a class.
\end_layout

\begin_layout Itemize

\emph on
Interface / protocol (vs abstract class)
\emph default
: both can't be instantiated but interfaces only specify which methods need
 to be implemented without any implementation while abstract classes provide
 some implementation and attributes.
\end_layout

\begin_layout Itemize

\emph on
Interface Segregation Principle
\emph default
: no client should be forced to depend on methods it does not use.
 Once this principle is applied interfaces which are very large are split
 into smaller and more specific ones so that clients will only have to know
 about the methods that are of interest to them.
\end_layout

\begin_layout Itemize

\emph on
Inversion of Control
\emph default
 
\emph on
(IoC)
\emph default
: An implementation of the dependency inversion principle.
 IoC achieves DIP by putting interfaces to low level modules inside high
 level modules.
 Low level code implements these interfaces.
 This 
\begin_inset Quotes eld
\end_inset

inverts
\begin_inset Quotes erd
\end_inset

 the traditional pyramid of OO where a dependency sits 
\begin_inset Quotes eld
\end_inset

inside
\begin_inset Quotes erd
\end_inset

 the client.
\end_layout

\begin_layout Itemize

\emph on
Is-a relationship
\emph default
 
\emph on
(vs has-a relationship)
\emph default
: is-a relationships are usually described by inheritance, has-a relationships
 are usually described by composition
\end_layout

\begin_layout Itemize

\emph on
Liskov Substitution Principle
\emph default
: if S is a subtype of T, then objects of type T may be replaced with objects
 of type S (i.e., objects of type S may substitute objects of type T) without
 altering any of the desirable properties of that program (correctness,
 task performed, etc.).
\end_layout

\begin_layout Itemize

\emph on
Method (vs function)
\emph default
: methods
\emph on
 
\emph default
have access to class attributes because the object is implicity passed to
 the method.
\end_layout

\begin_layout Itemize

\emph on
Multiple inheritance
\emph default
: whenever a class is allowed to inherit from more than one class.
 This can generate problems like diamond inheritance.
\end_layout

\begin_layout Itemize

\emph on
Open-Closed Principle
\emph default
: software entities (classes, modules, functions, etc.) should be open for
 extension, but closed for modification; that is, such an entity can allow
 its behavior to be modified without altering its source code.
\end_layout

\begin_layout Itemize

\emph on
Overloading (vs overriding)
\emph default
: 
\end_layout

\begin_deeper
\begin_layout Itemize
overloading is when you define two methods with the same name, in the same
 class, distinguished by their parameter list.
\end_layout

\begin_layout Itemize
overriding is when you re-implement a method of the superclass in the subclass.
\end_layout

\end_deeper
\begin_layout Itemize

\emph on
Polymorphism
\emph default
: providing a single interface to different types.
 Several ways of achieving it: 
\end_layout

\begin_deeper
\begin_layout Itemize
function overloading (or 
\emph on
adhoc
\emph default
 polymorphism)
\end_layout

\begin_layout Itemize
generics (or 
\emph on
parametric
\emph default
 polymorphism)
\end_layout

\begin_layout Itemize
subtyping (
\emph on
inclusion
\emph default
 polymorphism)
\end_layout

\begin_layout Itemize
duck typing (whenever the language is dynamically typed)
\end_layout

\end_deeper
\begin_layout Itemize

\emph on
Single Responsibility Principle
\emph default
: every context (class, function, variable, etc.) should have a single responsibi
lity, and that responsibility should be entirely encapsulated by the context.
\end_layout

\begin_layout Itemize

\emph on
SOLID principles
\emph default
: first five principles of OO Design: Single Responsibility Principle, Open-Clos
ed Principle, Liskov-Substitution Principle, Interface Segregation Principle,
 Dependency Inversion
\end_layout

\begin_layout Itemize

\emph on
Superclass or base class
\emph default
 
\emph on
(vs subclass or derived class)
\emph default
: a subclass inherits from a superclass
\end_layout

\begin_layout Itemize

\emph on
Virtual method
\emph default
 (pure virtual): a pure virtual function or pure virtual method is a virtual
 function that is required to be implemented by a derived class if that
 class is not abstract.
\end_layout

\begin_layout Section
Verification and Validation (V&V)
\end_layout

\begin_layout Description
Verification: (
\emph on
Are we building the product right?
\emph default
) The process of evaluating software to determine whether the products of
 a given development phase satisfy the conditions imposed at the start of
 that phase.
 Often an internal process, static (doesn't require the code to execute),
 involves humans checking the code, the documents, the files (code inspection).
\end_layout

\begin_layout Description
Validation: (
\emph on
Are we building the right product?
\emph default
) The process of evaluating software during or at the end of the development
 process to determine whether it satisfies specified requirements.
 Often a process that involves users (or automated tests), dynamic (requires
 the code to execute).
\end_layout

\begin_layout Subsection
Component inspection (Verification)
\end_layout

\begin_layout Standard
The purpose of component inspection is to find faults in a component by
 reviewing its source code in a formal meeting.
 It is very time consuming but generally more effective than testing in
 uncovering faults.
 It is used as a complement to testing in safety-critical projects.
 
\end_layout

\begin_layout Section
Testing
\end_layout

\begin_layout Itemize
A 
\emph on
fault
\emph default
 (also known as a 
\emph on
bug
\emph default
 or 
\emph on
defect
\emph default
) is a design or coding mistake that may cause abnormal component behavior.
\end_layout

\begin_layout Itemize
A 
\emph on
failure
\emph default
 is a deviation between the specification and the actual behavior.
 A failure is triggered by one or more erroneous states.
 Note that not all erroneous states trigger a failure!
\end_layout

\begin_layout Itemize
A 
\emph on
test
\emph default
 
\emph on
case
\emph default
 is a set of inputs and expected results that exercises a component with
 the purpose of causing failures and detecting faults.
\end_layout

\begin_layout Subsection
Types of testing
\end_layout

\begin_layout Itemize

\emph on
Black box testing
\emph default
: tests the functionality of the system without knowing the internal structure
 
\end_layout

\begin_layout Itemize

\emph on
White box testing
\emph default
: a complete knowledge of the internal structure of the system is used during
 the testing process
\end_layout

\begin_layout Itemize

\emph on
Gray box testing
\emph default
: some knowledge of the internal structure of the system is used to write
 better test cases but then the system is tested as a black box
\end_layout

\begin_layout Subsection
Types of testing examples (more specific)
\end_layout

\begin_layout Subsubsection
Unit testing
\end_layout

\begin_layout Standard
Unit testing focuses on the building blocks of the software system, that
 is, objects and subsystems.
 There are three motivations behind focusing on these building blocks: it
 reduces complexity of overall test activities, it makes easier to the pinpoint
 and correct faults and allows parallelism of testing activities.
\end_layout

\begin_layout Itemize

\emph on
Test case 
\emph default
is a set of conditions or variables under which a tester will determine
 whether an application, software system or one of its features is working
 as it was originally established for it to do.
\end_layout

\begin_layout Itemize

\emph on
Test suite
\emph default
 is a collection of test cases.
 
\end_layout

\begin_layout Itemize

\emph on
Test fixture
\emph default
 is a fixed state of the software under test used as a baseline for running
 tests (i.e.
 all the things that must be in place in order to run a test and expect
 a particular outcome).
\end_layout

\begin_layout Itemize

\emph on
Stub
\emph default
 is a piece of code used to stand in for some other programming functionality.
 A stub may simulate the behavior of existing code (such as a procedure
 on a remote machine) or be a temporary substitute for yet-to-be-developed
 code.
\end_layout

\begin_layout Itemize

\emph on
Mock objects
\emph default
 are simulated objects that mimic the behavior of real objects in controlled
 ways.
 A programmer typically creates a mock object to test the behavior of some
 other object, in much the same way that a car designer uses a crash test
 dummy to simulate the dynamic behavior of a human in vehicle impacts.
\end_layout

\begin_layout Subsubsection
Equivalence testing
\end_layout

\begin_layout Standard
This black-box technique minimizes the number of test cases.
 The possible inputs are partitioned in equivalence classes, and a test
 case is selected as a representative for each class.
 The assumption behind equivalence testing is that the system behaves in
 similar ways for all members of a class.
\end_layout

\begin_layout Subsubsection
Boundary testing
\end_layout

\begin_layout Standard
This special case of equivalence testing focuses on the conditions at the
 boundary of the equivalence classes.
 The assumption behind boundary testing is that developers often overlook
 special cases at the boundary of the equivalence classes.
\end_layout

\begin_layout Standard
A disadvantage of these techniques is that they do not explore combinations
 of input data.
\end_layout

\begin_layout Subsubsection
Path testing
\end_layout

\begin_layout Standard
This white box technique identifies faults in the implementation of a component.
 The assumption behind path testing is that, by exercising all possible
 paths through the code at least once, most fault will trigger failures.
 The identification of paths requires knowledge of the source code and data
 structures.
 
\end_layout

\begin_layout Itemize

\emph on
Statement Coverage criteria
\emph default
: all lines of code are executed.
\end_layout

\begin_layout Itemize

\emph on
Decision Coverage criteria
\emph default
: all branch statements must be executed (both conditions).
\end_layout

\begin_layout Itemize

\emph on
Condition Coverage criteria
\emph default
: all conditions (in branch statements, loops,...) must be executed.
\end_layout

\begin_layout Paragraph
Cyclomatic complexity
\end_layout

\begin_layout Standard
It can be shown that the minimum number of tests necessary to cover all
 edges (branches) is equal to the number of independent paths through the
 flow graph of a particular program.
 This is defined as the 
\emph on
cyclomatic complexity
\emph default
 (
\emph on
CC
\emph default
) of a graph.
\end_layout

\begin_layout Standard
\begin_inset Formula $CC=|E|−|V|+2P$
\end_inset

 where 
\begin_inset Formula $|E|$
\end_inset

 is the number of edges of the graph, 
\begin_inset Formula $|V|$
\end_inset

 is the number of nodes of the graph and 
\begin_inset Formula $P$
\end_inset

 is the number of connected components.
\end_layout

\begin_layout Subsubsection
State-based testing
\end_layout

\begin_layout Standard
State-based testing focuses on object-oriented systems and compares the
 resulting state of the system with the expected state.
 In the context of a class, state-based testing consists of deriving test
 cases from the UML state machine diagram for the class.
 
\end_layout

\begin_layout Subsection
Integration testing
\end_layout

\begin_layout Standard
Integration testing detects faults that have been not been detected during
 unit testing by focusing on small groups s of components.
 Two or more components are integrated and tested, and when no new faults
 are revealed, additional components are added to the group.
 This procedure allows the testing of increasingly more complex parts of
 the system while keeping the location of potential faults relatively small.
 
\end_layout

\begin_layout Subsubsection
Horizontal integration testing strategies
\end_layout

\begin_layout Standard
Integrates components according to layers.
 
\end_layout

\begin_layout Standard
The 
\emph on
big bang
\emph default
 strategy assumes that all components are first tested individually and
 then tested together as a single system.
 
\end_layout

\begin_layout Standard
The
\emph on
 bottom-up testing strategy 
\emph default
first tests each component of the bottom layer individually, and then integrates
 them with components of the next layer up.
 A major advantage of this technique is that no stubs are needed.
\end_layout

\begin_layout Standard
The 
\emph on
top-down testing strategy
\emph default
 unit tests components of the top layer first, and then integrates the component
s of the next layer down.
 The advantage of this technique is that interface faults can be more easily
 found.
\end_layout

\begin_layout Standard
The 
\emph on
sandwich testing strategy
\emph default
 combines the previous two.
\end_layout

\begin_layout Subsubsection
Vertical integration testing strategies
\end_layout

\begin_layout Standard
Integrates components according to functions.
 It focuses on early integration.
 For a given use case, the needed parts of each component, such the user
 interface, business logic, middleware and storage, are identified and developed
 in parallel and integration tested.
 This technique is used very often by agile methodologies.
\end_layout

\begin_layout Subsubsection
Regression testing
\end_layout

\begin_layout Standard
Object-oriented development is an iterative process.
 When modifying a component, developers design new unit tests exercising
 the new feature under consideration.
 However, they should not assume that the rest of the system will work with
 the modified component, since the modification could introduce side effects
 or reveal previously hidden faults in other components.
 Integration tests that are rerun on the system to detect such failures
 are called 
\emph on
regression tests
\emph default
.
 
\end_layout

\begin_layout Subsection
System testing
\end_layout

\begin_layout Standard
Once the components have been integrated, system testing ensures that the
 complete system complies with the functional and non functional requirements.
\end_layout

\begin_layout Itemize

\emph on
Functional testing
\emph default
 finds differences between the functional requirements and the system.
 It is a black-box technique since test cases are derived from the use case
 model.
\end_layout

\begin_layout Itemize

\emph on
Smoke testing
\emph default
 consists of preliminary testing to reveal simple failures severe enough
 to reject a prospective software release.
 A subset of test cases that cover the most important functionality of a
 component or system is selected and run, to ascertain if the most crucial
 functions of a program work correctly.
\end_layout

\begin_layout Itemize

\emph on
Performance testing
\emph default
 finds differences between the design goals selected during system design
 and the system.
 Because the design goals are derived from he nonfunctional requirements,
 the test cases can be derived from the RAD.
 The following tests are performed: stress testing, volume testing, security
 testing, timing testing, recovery testing.
\end_layout

\begin_layout Itemize
During 
\emph on
pilot testing
\emph default
 the system is installed and used by a selected group of users.
 Users exercise the system and if it had been permanently installed.
 
\end_layout

\begin_layout Itemize
In 
\emph on
acceptance testing
\emph default
 the customer performs usability, functional and performance tests in the
 target environment.
 After acceptance testing, the client reports to the project manager which
 requirements are not satisfied.
 
\end_layout

\end_body
\end_document