Software Engineering Exam 2

^

conjunction (p and q)

weird sideways L

negation (not p)

Two use-case categories distinguished:

"first-" (use cases represent meaningful services provided by the system to an actor) vs. "second tier" (use cases represent elaborations or sub-services of the main services)

Condition coverage

(also known as predicate coverage) selects a test set such that every condition (Boolean statement) takes TRUE and FALSE outcomes at least once in some test case.

Type 3 responsibility

(communicating): Communicating with other objects, represented as message sending (method invocation)

Type 2 responsibility

(doing) : performing computations, such as data processing, control of physical devices, etc., represented as a method

Equivalence testing has two steps:

(i) partitioning the values of input parameters into equivalence groups and (ii) choosing the test input values.

Type 1 responsibilitiy

(knowing): memorizing data or references, such as data values, data collections, or references to other objects, represented as a property

Access designations that signify the visibility of class attributes and operations to other classes:

+ for public, global visibility; # for protected visibility within the class and its descendant classes, and - for private within-the-class-only visibility

Alternate scenarios or extensions in a use case can result from:

- Inappropriate data entry, such as the actor making a wrong menu-item choice (other than the one he/she originally intended), or the actor supplies an invalid identification - System's inability to respond as desired, which can be a temporary condition or the information necessary to formulate the response may never become available

We will consider three kinds of relations: states, truths, and roles:

- state is a relation among individual entities and values, which can change over time. -truth is a fixed relation among individuals that cannot possibly change over time. -role is a relation between an event and individual that participate in it in a particular way

Important design principles at the local, objects level include:

-Expert Doer principle: that who knows should do the task; helps shorten the communication chains between the objects -High Cohesion Principle: do not take on too many responsibilities of Type 2 (computation);; helps in balancing the workload across the objects and keeping them focused -Low Coupling principle: do not take on too many responsibilities of Type 3 (communications) ;; helps to reduce the number of associations among the objects

Good software designs are characterized with:

-Short communication chains between the objects -Balanced workload across the objects -Low degree of connectivity (associations) among the objects

One way to classify states is by what the object is doing in a given state:

-passive quality if the object is just waiting for an event to happen -active quality if the object is executing an activity

Equivalence classes defined for an input parameter must satisfy the following criteria

1. Coverage: Every possible input value belongs to an equivalence class. 2. Disjointedness: No input value belongs to more than one equivalence class. 3. Representation: If an operation is invoked with one element of an equivalence class as an input parameter and returns a particular result, then it must return the same result if any other element of the class is used as input.

Each testing method follows this cycle:

1. Create the thing to be tested (fixture), the test driver, and the test stub(s) 2. Have the test driver invoke an operation on the fixture 3. Evaluate that the results are as expected

unit test case comprises three steps performed by the test driver:

1. Setup objects: create an object to be tested and any objects it depends on, and set them up 2. Act on the tested object 3. Verify that the outcome is as expected

The two stereotypical - or cliche types of relationship are:

<<extend>> - optional extensions of the main case <<include>> - required subtasks of the main case

conditional statement

A conditional statement or, simply a conditional, is obtained by combining two propositions p and q to a compound proposition "if p, then q." It is also written as p->q and can be read as "p implies q."

macrostate

A group of microstates

subset

A set B is a subset of a set A if all of the members of B are members of A

Architecture vs Design

Architecture focuses on non-functional requirements("cross-cutting concerns") and decomposition of functional requirements and Design focuses on implementing the functional requirements

Deterministic vs. Stochastic Phenomena

Deterministic phenomena are the causal phenomena for which the occurrence or non- occurrence can be established with certainty. && Stochastic phenomena are the causal phenomena that are governed by a random distribution of probabilities.

categories of phenomena:

Structurally, individuals and relations among individuals; Logically, we can distinguish causal vs. symbolic phenomena; behavior, we can distinguish deterministic vs. stochastic phenomena

Controller

Takes user input and figures out what it means to the Model

integration testing

Testing the composition of the system components

acceptance testing

The customer performs acceptance testing of the whole system

mock objects

The driver and stub are also known as mock objects, because they pretend to be the objects they are simulating

ordered pair <x, y>

The ordered pair <x, y> is a pair of objects in which x is the first object and y is the second object.

proper subset

The set B is a proper subset of A if B is a subset of A and B not equal A, which is denoted as B subset no line A.

"big bang" integration

The simplest approach, tries linking all components at once and testing the combination

fixture

The thing to be tested

conditional

This is a statement that causes another statement to execute only if a particular condition is true

state

We can define state more precisely as a relation on a set of objects, which simply selects a subset of the set.

lexical domain

a physical representation of data—that is, of symbolic phenomena

Responsibility-driven design (RDD)

a popular approach to micro-level design. We know the types of responsibilities that objects can have:

postcondition

a predicate that must be true after an operation is executed. A postcondition also applies to a specific operation. Postconditions are frequently used to describe how the object's state was changed by an operation.

Software architecture

a set of high-level decisions made during the development and evolution of a software system. A decision is "architectural" if, given the current level of system scope, the decision must be made by considering the current scope level

Boundary testing

a special case of equivalence testing that focuses on the boundary values of input parameters

Use case

a usage scenario for an external entity, known as actor, and the system-to-be. A use case represents an activity that an actor can perform on the system and what they system does in response. It describes what happens when an actor disturbs out system from its "stationary state" as the system goes through its motions until it reaches a new stationary state;; are text stories that detail exactly what happens when an actor attempts to obtain a service from the system

Responsibilities

actors have their responsibilities and seek the system's assistance in managing those responsibilities

fault

also called "defect" or "bug" is an erroneous hardware or software element of a system that can cause the system to fail

Initiating actor

also called primary actor, or user: initiates the use case to realize a goal, which depends on the actor's responsibilities and the current context

Participating actor

also called secondary actor: participates in the use case but does not initiate it; there are two subcategories: supporting actor (helps the system-to-be to complete the use case-that is, our system-to-be initiates the supporting actor) and offstage actor (passively participates in the use case, i.e., neither initiates nor helps complete the use case, but maybe notified about some aspect of it)

Action

an action is the triggering of an interaction with the system-to-be

event

an individual happening, occurring at a particular point in time; Each event is indivisible and instantaneous, that is, the event itself has no internal structure and takes no time to happen

Sandwich integration

approach combines top-down and bottom-up by starting from both ends and incrementally using components of the middle level in both directions. The middle level is known as the target level. In sandwich testing, usually there is need to write stubs for testing the top components, because the actual components from the target level can be used

Contracts

are constraints on a class that enable the users of the class, implementers, and extenders to share the same assumptions about the class.

User acceptance test case

at the time of writing detailed use cases, we also write the corresponding user acceptance tests.....user acceptance test case is a detailed procedure that fully tests a use case or one of its flows of events.

Equivalence testing

black-box testing method that divides the space of all possible inputs into equivalence groups such that the program "behaves the same" on each group. The goal is to reduce the total number of test cases by selecting representative input values from each equivalence group

Actor

can be a person or another system which interacts with out system-to-be.

White box testing

chooses test data with knowledge of the implementation, such as knowledge of the system architecture, used algorithms, or program code; This testing approach assumes that the code implements all parts of the specification, although possibly with bugs (programming errors)

State-based testing

defines a set of abstract states that a software unit can take and tests the unit's behavior by comparing its actual states to the expected states

Associations

describe who needs to work together and why, not how they work together

Path coverage

determines the number of distinct paths through the program that must be traversed (travelled over) at least once to verify the correctness. This strategy does not account for loop iterations or recursive calls.

v

disjunction (p or q)

System testing

ensures that the whole system complies with the functional and non-functional requirements

View

gives you a presentation of the Model. Gets data directly from the Model

Model

holds all the data, state and application logic. Oblivious to the View and Controller. Provides API to retrieve state and send notifications of state changes to "observer"

Examples of value classes..

include integer, character, string, and so on.

proposition

is a declarative sentence (a sentence that declares a fact) that is either true or false, but not both.

phenomenon

is a fact, or object, or occurrence that appears or is perceived to exist, or to be present, or to be the case, when you observe the world or some part of it

test stub

is a minimal implementation that simulates the components which are called by the tested component

precondition

is a predicate that is checked before an operation is executed; applies to a specific operation. Preconditions are frequently used to validate input parameters to an operation.

entity

is an individual with distinct existence, as opposed to a quality or relation. An entity persists over time and can change its properties and states from one point in time to another

value

is an intangible individual that exists outside time and space, and is not subject to change. The values we are interested in are such things as numbers and characters, represented by symbols

system

is an organized or complex whole, an assemblage of things or parts interacting in a coordinated way

System state

is defined as a tuple of state variables containing any valid combination of state relations

Test coverage

measures the degree to which the specification or code of a software program has been exercised by tests

invariant

must always evaluate to true for all instance objects of a class, regardless of what operation is invoked and in what order. An invariant applies to a class attribute.

refactoring

of existing code is a transformation that improves its design while preserving its behavior. Refactoring changes the internal structure of software to make it easier to understand and cheaper to modify that does not change its observable behavior;; The process of refactoring involves removing duplication, simplifying complex logic, and clarifying unclear code

causal domain

one whose properties include predictable causal relationships among its causal phenomena;; A causal domain may control some or all or none of the shared phenomena at an interface with another domain

p

p is called the premise (or antecedent or hypothesis)

designed domain

problem domain for which data structures and, to some extent, its data content need to be determined and constructed

q

q is called the conclusion (or consequence)

Black box testing

refers to analyzing a running program by probing it with various inputs; It involves choosing test data only from the specification, without looking at the implementation

System sequence diagram

represents in a visual form a usage scenario that an actor experiences while trying to obtain a service form the system

heuristics

rules of thumb that are generally useful but do not guarantee correctness

Regression testing

seeks to expose new errors, or "regressions," in existing functionality after changes have been made to the system; helps to populate test suite with good test cases, because every regression test is added after it uncovered a fault in one version of the code; protects against reversions that reintroduce faults

Edge coverage

selects a test set such that every edge (branch) of the control flow is traversed at least once by some test case

Statement coverage

selects a test set such that every elementary statement in the program is executed at least once by some test case in the test set.

relation

share a certain characteristic

test driver

simulates the part of the system that invokes operations on the tested component

Bottom-up integration

starts by combining the units at the lowest level of hierarchy. The "hierarchy" is formed by starting with the units that have no dependencies to other units

Top-down integration

starts by testing the units at the highest level of hierarchy that no other unit depends on ; we never need to develop test drivers, but we do need test stubs

microstates

states that are directly observable at a given level of detail

Use case diagram

sums up the actors, use cases, and their relationships

unit testing

testing individual components; finds differences between the object design model and its corresponding implementation

It is essential to document

the alternative solutions that were considered in the design process, identify all the tradeoffs encountered, and explain why the alternatives were abandoned

Business process risk

the chance of something happening that will have an impact on the process objectives, such as financial or reputational damage, and is measured in terms of likelihood and consequence

Goals

to carry out its responsibilities, an actor sets goals, which are time and context-dependent

Optimal design

to derive a "good" design

Design heuristics

used to achieve "optimal" designs can be roughly divided as: Bottom-up (inductive) approaches that are applying design principles and design patterns locally at the level of software objects. and Top-down (deductive) approaches that are applying architectural styles globally, at the system level, in decomposing they system into subsystems (micro-level design)

biddable domain

usually consists of people;; The most important characteristic of a biddable domain is that it lacks positive predictable internal causality

code coverage

which measures the degree to which the source code of a program has been tested. There are a number of code coverage criteria, including equivalence testing, boundary testing, control-flow testing, and state-based testing.

vertical integration

Agile methods use this approach to develop the user stories in parallel; Each story is developed in a feedback loop, where the developers use unit tests in the inner loop and the customer runs the acceptance test in the outer loop

Causal vs. Symbolic Phenomena

Causal phenomena are events, or roles, or states relating entities && Symbolic phenomena are values, and truths and states relating only values.