Software Engineering Exam 2

Software design process activities (7)

Requirements Specification, Architectural Design, Abstract Specification, Interface Design, Component Design, Data Structure Design, Algorithm Design

Software design process activity: What is the Architectural Design activity?

To outline the high-level structure of the system.

Software design process activity: What is the Requirements Specification activity?

Define what the software must do.

Software design process activity: What is the Abstract Specification activity?

Describe what each component should do, without specifying how.

Software design process activity: What is the Interface Design activity?

Define how different components communicate with each other.

Software design process activity: What is the Component Design activity?

Detail the internal design of each component/module.

Software design process activity: What is the Data Structure Design activity?

Choose and define the data organization that supports efficient implementation.

Software design process activity: What is the Algorithm Design activity?

Develop the logic and step-by-step procedures for solving problems within the system.

What is Software Architectural Design?

The software architecture of a system is the style of design of structure. SAD is a decision making process to determine the software architecture for the under-development system

Why Architectural Design?

The architecture of a system has significant impact on performance, efficiency, security, maintainability. It's vital to developing the system. Without it, design flaws may result in project failure

Architectural Design Process

Determine objectives, determine type of system, apply an architecture style in available, if not do custom, specify subsystem functions and interfaces and behavior, review the design

Four common types of systems

Interactive Subsystem, Event-Driven Subsystem, Transformational Subsystem, Database Subsystem

Interactive Subsystem characteristics

1. Has to process and respond to each request

2. Interacts with only one actor

3. The actor is often a human being

Event-Driven Subsystem characteristics

1. Its state may not reflect on computation progress

2. It interacts with more than one external entity at a time

3. External entities are often hardware devices or software

Transformational Subsystem characteristics

1. Usually stateless

2. Actors can be human beings, devices, or systems

3. May perform number crunching or intensive algorithms

Database Subsystem characteristics

1. It provides object storage and retrieval capabilities

2. It hides the implementation from the system

3. It only stores and retrieves objects and does no business processing

Classic system architectures (5)

N-Tier, Client-Server, Main program and subroutine, Event-Driven, Object-persistence framework

What type of system is N-Tier

Interactive System

What type of system is Client Server

Client-Server (lol)

What type of system is Main program and subroutine

Modular

What type of system is Event-Driven

Event-Driven (lol)

What type of system is Object-Persistence framework

Persistence Framework

If the system architectures don't work, what do we do?

Perform custom architectural design

Specify Subsystem Functions and Interfaces steps (4)

1. Allocate requirements and objectives to subsystems

2. Specify functionality or each subsystem

3. Specify the interfaces of the subsystems

4. Specify the interaction behavior of the subsystems

Why High Cohesion?

A software design principle, everything in the module is closely related and serves a single purpose

Why Low Coupling?

A software design principle, components are mostly independent. If one thing doesn't work, you don't want the rest to also not work

Why to keep it simple and stupid?

A software design principle, avoid complicated code to make reading, debug, and maintain easier

Objectives for software testing

To find an error

What is a successful test in software engineering

One that finds an undiscovered bug

Testing methods for software testing (2)

White box Black box

When do you use White Box Testing

When you know the internal workings of a product

Techniques of White Box Testing (3)

Basis Path, Condition, and Data Flow testing

When do you use Black Box Testing

When you know the specific function that a product has been designed to perform

Techniques of Black Box Testing (3)

Equivalence Partitioning, Boundary Value Analysis, Comparison testing

Basis Path testing

White Box method, Construct a flow chart, compute complexity of the chart (indicates the num of independent paths), determine basis paths, design test cases for the paths

Condition Testing

White Box method, Test each condition. Branch testing, define combinations of truth values, design test cases for combinations.

Data Flow testing

White Box method, Select test paths of a program according to the location of definitions and use of variables. Then test define-use chains.

Equivalence Testing

Black Box method, Divide input domain of a program into classes of data. Test cases can be derived. Basically, if an input condition specifies a range or a value, one valid and two valid equivalence classes are defined.

Boundary Value Analysis

Black Box method, Lead to a selection of test cases that exercise boundary values of the input domain.

Comparison Testing

Appropriate when multiple implementations of same specification have been produced. Use same inputs to test whether they generate same outputs.

Testing principles

All tests should be traceable to customers, planned ahead, start small and go larger, and be conducted by a third party

SOFTWARE TESTING STRATEGY (4)

Unit test --> Integration test --> Validation test --> System test

Unit test

Test Strategy: Use WBT techniques, test each module, including interface, local data structures, boundary conditions, independent paths, error handling paths, etc.

Integration test

Test Strategy: Test correctness of integrations of modules. Usually incremental integration. Integration strategies are Top down, Bottom up, and a combination

Top-Down Testing

Integration Strategy, test from the top and go down

Bottom-Up Testing

Integration strategy, test from the bottom and go up

How to do integration testing on an OO system

1. Identify modules and interactions. Dependencies (generalization, aggregation, association,)

2. Decide on a strategy (top down, bottom up)

3. Do it i guess

Generalization

---|> A cat is a kind of pet

Aggregation

---<> A tail is a part of both dogs and cats

Association

---> Owners feed pets, pets please owners

Validation Testing

Test Strategy: Test whether the software functions in a manner than can be reasonably expected by the customer. (software requirements). Alpha Testing and Beta Testing

Alpha Testing

Validation Testing Method: Developer observes customer

Beta Testing

Validation Testing Method: Developer does not observe customer

System Testing

Test Strategy: Focus on not only software but also the integration of software, hardware, environment.

Types of System Testing

Recovery, Security, Stress, Performance

Recovery Testing

How long a system takes to recover after crashing

Security Testing

How secure the system is from being attacked

Stress Testing

How much the system can handle at once

Performance Testing

How fast the system runs