Software Engineering-v2

They say it’s basically a class problem

Chapter1:intro

  • software=computer programs + associated documentation
  • we need methods to develope high-qualified software that are: standard,systematic,efficient,dependable,easy-to-use
  • software engineering is an discipline that is concerned with all aspects of software production from initial conception to operation and maintenance.
  • History of software engineering:

  • SE’s composition:

    • software development(needs methods, techniques and tools to support)

      • requirements engineering
      • software design
      • coding
      • testing
      • maintenance
    • project management

  • Delevoping software:(the whole design testing and so on is not the same system)

    • structured
    • object-oriented

  • software engineering ethics

    • confidentiality
    • competence
    • intellectual property rights
    • computer misuse

Chapter2:software process model

Organization of processes and activities

Key points in this chapter:

  1. What is software process?
  2. What is software process model?
  3. What are the software process models and what’s their advantages and disadvantages and implementation area?
  4. Difference between plan-driven and agile?
  5. What is agile method?
  6. What are the steps of software process?

Fundamental activities in software processes

(all processes involve the following steps)

  • Specification:what the system should do
  • Design and implementation:the organization of system
  • Validation:checking if it does what the customer wants
  • Evolution:changing in response to customer need(changing requirements) development and evolution
  • descriptions of activities in software process
    • Products
    • Roles

    • Pre- and Post- conditions

      • Pre-condition
      • Post-condition:conditions that must test true after exiting this module

        (If you exit the module without post-condition, the module is in error.)

  • software process:a sequence of activities leading to the production of a software product.
  • software process model/aka product life cycle : an abstract representation of a software process.

  • Software Processes (more on later)

    • Plan-driven processes:Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan.
    • Agile processes:In agile processes, planning is incremental and it is easier to change the plan and the software to reflect changing customer requirements.

Software process models:

  • Waterfall model:Plan-driven strict order

    Do not proceed to the next activity until the previous activity has finished

    5 steps in waterfall model:

    • requirements definition
    • system and software design
    • implementation and unit testing
    • integration and system testing
    • operation and maintenance

    Advantages of waterfall model

    • (The plan-driven nature of the waterfall model) Helps coordinate the work
    • Good requirements imporves software quality.

    Disadvantages of waterfall model: difficult to deal with changing requirements(Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements)

    Application domain of waterfall model:

    • Large system
    • requirements that are well-understood and unlikely to change radically

  • Incremental model

    interleaving activities

    Advantages of incremental model:

    • dealing with change(The cost of accommodating chaging customer requirements is reduced)
    • repid delivery and deployment(Can use and gain value from the software earlier than is possible with a waterfall model)
    • effective feedbacks(Customers can comment on the demonstrations of the software and see how much has been implemented)

    Disadvantages of incremental model:

    • invisible processes

      Managers need regular deliverables to measure progress.

      If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.

    • degrading system structure(system structure tends to degrade as new increments are added)

      Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly.

    Application condition of incremental model:

    • limited time and budget
    • changing requirements

  • Reuse-oriented model

    component search and configuration

    Key points of re-use oriented model:

    • Component selection
    • Component filtering
    • Component-dependent requirements development

    Types of component

    • Web services
    • Collections of objects(developed as a package to be integrated with a component framework suh as .NET or J2EE)
    • Stand-alone software systems(COTS)

    Advantages of reuse-oriented model:

    • Reduce the amoung of software to be developed
    • Reduce cost and risk
    • Faster delivery

    Disadvantages of reuse-oriented model:

    • Inevitable requirements compromises
    • Different from real needs
    • Components out of control
  • These models are not mutually exclusive and are often used together, especially for large systems development.
  • For large systems, it makes sense to combine some of the best features of the waterfall and the incremental development models.
  • You need to have information about the essential system requirements to design a software architecture to support these requirements. You cannot develop requirements incrementally.
  • Sub-systems within a larger system may be developed using different approaches.
  • Parts of the system that are well understood can be specified and devel- oped using a waterfall-based process.
  • Parts of the system which are difficult to specify in advance, such as the user interface, should always be developed using an incremental approach.
  • Question: Will you only test the three process Models on the PPT?

Coping with change

Cost of change include rework and the cost of implementing new functionality.

  • How to reduce the cost of rework?
    • Changing avoidance:
    • Change tolerance:
  • Prototype can be used in:
    • requirements engineering
    • design processes
    • testing processes

Agile Methods (concepts, ideas, and values, not specific models)

  • Why do we need agile methods?

    Overheads of tradition way of developing softwares is too big: planning+designing+documenting the system.(Disatisfaction with the overheads)

    To reduce overheads in the software process and to respond quickly to changing requirements without excessivee rework.

  • Agile methods applicability
    • product development: a software company is developing a small or medium-sized product.
    • custom system development:An organization, where there is a clear commitment from the customer to become involved in the development process and where there are not a lot of external rules and regulations that affect the software.
  • Agile Methods (Question: Do you need to know what these Agile methods mean?)
    • Extreme programming(XP):best known, most widely used
    • Scrum(Agile Development)

      focus is on managing iterative development rather than specific agile practices.

    • Crystal
    • Adaptive software development(ASD)
    • DSDM(Dynamic Systems Development Method)
    • Feature driven development(FDD)

  • software processes

    • Plan-driven development

      • Based around seperate development stages
      • Not necessarily waterfall model
      • Iteration occurs within activities

    • Agile development

      • Specification, design, implementation and testing are interleaved
      • A process of negotiation during the software development process decide the outputs
      • Iteration occurs across activities, the requirements and the design are developed together, rather than separately

  • How to choose between agile and plan-driven?

    • Plan-driven:

      • detailed specification and design
      • big system
      • require a lot of analysis before implementation
      • if has to be approved by external regulator

    • Agile:

      • rely on good tools to keep track of an evolving design
      • (Some people say) agile methods require better programmer
  • Scaling agile mothods:
    • Background: Agile methods have proved to be successful for small and medium sized projects that can be developed by a small colocated team.

      Agile Methods were originally intended for small and medium-sized teams, but if you want to use Agile Methods for large teams you should use one of the Scaling Agile Methods

    • Scaling up to large systems: replace the small one with a larger, more powerful one.

      • More up-front design and system documentation

        For large systems development, it is not possible to focus only on the code of the system. You need to do more up-front design and system documentation.

      • Cross-team communication mechanisms have to be designed and used.

        This should involve regular phone and video conferences between team members and frequent, short electronic meetings where teams update each other on progress.

      • Continuous integration.

        Continuous integration, where the whole system is built every time any developer checks in a change, is practically impossible. However, it is essential to maintain frequent system builds and regular releases of the system.

    • Scaling out to large companies(pipeline): replicate the small one to work in parallel.

      • Refuse to accept risk

        Project managers who do not have experience of agile methods may be reluctant to accept the risk of a new approach.

      • Against standard procedures

        Large organizations often have quality procedures and standards that all projects are expected to follow and, because of their bureaucratic nature, these are likely to be incompatible with agile methods.

      • A wide range of skills

        Agile methods seem to work best when team members have a relatively high skill level. However, within large organizations, there are likely to be a wide range of skills and abilities.

      • Cultural resistance

        There may be cultural resistance to agile methods, especially in those organizations that have a long history of using conventional systems engineering processes.

Activities in software processes:

  1. Specification

  2. Design and implementation

  3. Software validation

  4. Software evolution

    evolution stemmed from changing requirements

    development and evolution(maintenance)

Chapter 3:requirements engineering

Requirements engineering is to get good requirements

what should the system do?

key points in this capter:

  1. What is requirements engineering?
  2. What is the purpose of requirements engineering?
  3. What’s the 4 parts of requirements engineering?
  4. What is feasibility study?
  5. What are the requirements analysis models?
  6. What are formal specification?
  7. What are the methods in formal specification?
  8. What are the 3 kinds in requirements validation?
  9. What are the types of prototype? What’s their features and differences?
  10. What are software requirements reviews?

Why use requirements engineering?

  • Requirements errors are likely to be the most common class of error.
  • The quality of requirements is the key to the success of a software project.
  • Requirements errors are likely to be the cheapest errors to fix.

Requirement

  • Functional requirement(depending on the software)

    • finding and highlighting a misspelled word
    • displaying a dialog box with suggested replacement

  • Non-functional requirement

    • Useability
    • Flexibility
    • Reliability

What is not in requirements:

  • design or implementation details
  • project planning information
  • testing information

Requirements Engineering Composition

  • Feasibility study

    (Before getting started)

    • Purpose

      • Determing hether go ahead with project.
      • Should be cheap and fast.

    • Mission

      • Technical: Do the have the technique to implement the system?
      • Economic: Will we earn enough money?
      • Operational: Will the system solve the problems well enough?
  • Requirements Elicitation(Find out what requirements are available)

    Process of identifying the needs and constraints of stakeholders for a software system.

    Requirements elicitation is a complex process that consists of gathering, researching, defining, structuring, And clarifying a product ‘s requirements.

    As a result of elicitation, a BA creates a set of project objectives.

  • Requirements Analysis

    • Use analysis model as graphical representation
    • An Analysis Model is usually a graphic
    • We cannot use one single analysis model for requirements analysis.
  • Requirements Specification

    The product’s detailed functional and non-functional requirements reside in a software requirements specification.(SRS)

  • Requirements Validation

Requirements Analysis Models

  • State-Transition Diagram/State charts (STD)

    Describes how the system transferred among different states.

    Changes between states

    State: a collection of relationships between variables and certain allowed values.

    Software behaviors are regraded as “state transitions”.

    Usage:

    • Useful for specification review or test case generation
    • Not suitable for data-intensive systems
    • Powerful notation for demonstrating the change of system states
    • Logical model
    • Suitable for control system and real time system

    How to dram state transition diagram?

    1. Analyze which states have what state control information or state transition process
    2. The line draws the transitions between states

  • Data Flow Diagram (DFD)

    How data flows among different system modules.

    Process: must get inputs and then produce outputs (immediately)(compare with CDFD)

    There may be many levels of Hierachy to DFD :interface of high level should be consistent with the low one

    Advantages of DFD:

    • A good view of system functions.
    • Intuitive and expressive.
    • Easy to master.
    • Controllable.
    • Effective for transaction-intensive systems.

    Limitations of DFD:

    • Lack of explicit data relationships.
    • Cannot demonstrate temporal features.
    • Not appropriate for control systems.

    How to draw DFD?

    1. Analyze these things:

      • Terminator
      • Data terminator
      • Process
      • Storage (database)
    2. Building a top-level DFD (determining system boundaries, data inputs and outputs, system functions)

      In the top level DFD there’s only going to be one process on the whole diagram and that’s the system to be designed

    3. To refine the top layer DFD diagram, build layer 0 DFD (refine the top layer data flow diagram, add data store). The number of layer 0 is 1,2,3
    4. Refine each processing of 0 layers OF DFD, and construct 1 layer of DFD respectively, and so on. Refine layer by layer until 1 layer and 2 layers of the underlying DFD figure are constructed… The process number is similar to 1.1 and 1.1.1
  • Entity-Relationship Diagram (ERD)

    Commonly used data model.

  • Dialog Map

  • Decision Table

    Represents the correspondence between complex conditions and actions to be performed

  • Decision Tree

  • Use Case Diagram
  • Class Diagram
  • Activity Diagram

Requirements Specification

  • The product’s detailed <u>functional</u> and <u>nonfunctional</u> requirements reside in a software requirements specification (SRS).

  • Requirements(3 Requirements are essentially the same, different abstractions of Requirements)

    • Business Requirement
    • User Requirement
    • Function Requirement
  • Who need SRS:
    • User
    • Customer
    • Project manager
    • Analyst
    • Developer
    • Tester
  • Attributes of good SRS
    • Well-structured
    • Abstract
    • Complete
    • Easy to understand
    • Unambiguous
    • Verifiable

Requirements Specification Language

  • Natural language
  • Graphical models

  • Formal Specification: Define requirements using mathematically precise Formal logic languages.

    • Data definition in formal specification(Data Dictionary)

      1. Primitive data elements(No further decomposition is possible or necessary)
      2. Composition(Multiple data items)
      3. Iteration(Multiple instances of one item)
      4. Selection(Limited number of discrete values)

    • Formal specification(methods?)

      1. B,Z,VDM, you know what it is, right

        • B

        • Z

        • VDM

      2. SOFL(Structured Object-oriented Formal Language)

        A formal language+ A method for construction

        module

        Const// The constant used in the module

        Type// The Type used in module int real

        Var// Module b:int

        Behav// The CDFD name of the module

        Pre // The pre-condition for A to run correctly

        Post // Post condition that describes the relationship between output and input

        Decom CI // Process A can be decomposed into the underlying CDFDci

        end_process;

        Process_2;

        .

        Process_n;

        End-module;

        Hierarchy in SOFL specification

        • One-layer CDFDThere is only one layer of CDFD

          Describe functions by data flows among processes in the CDFD.

        • Hierarchical CDFDHierarchical CDFD

          If certain processes are too complex to describe in pre- and post-conditions, decompose them into low-level CDFDs

        Advantages:

        • Integrating graphical representation
        • Construction strategy
        • Tool support

Requirements Validation

Does the specification satisfy user’s requirement?

Check consistency between domain knowledge and specification.

3 requirements validation techniques: prototype,review and testing

  • Software prototype

    • Pros of software prototype:

      1. Making it alive.
      2. Easy to be understood by non-experts.
      3. Fast.
      4. Closes gaps in customer’s understanding of the requirements.
      5. Stimulates customer’s thinking.
      6. Early feedbacks.
      7. Deals with variability.

    • Types of software prototype:

      1. According to description:

        • Horizontal(behavioral prototype or mock-up)(Just a demo of the surface similar to the prototype)

          Does not dive into all the layers or into system details

          Demonstrate how the user interacts with the target system, the functional options the user will have available.

        • Vertical(structural prototype or proof of concept)(The in-depth demo is like a small piece of the full system)

          A splice of application functionality from the user interface through the technical services layers.

          Touches on all levels of the system implementation

          Looks like a subsystem of the target software

      2. According to purpose classification:

        • Exploratory Prototype Throwaway Prototype(Exploratory Prototype)

          For answering questions and resolving uncertainties and improving requirements quality.

          Discard or being integrated into the final system

        • Evolutionary Prototype(Must write code carefully and have a solid code foundation)

          A solid architectural foundation for building the product incrementally.

          Must be built with robust, production quality code

          Takes longer time than throwaway.

    • Requirement analysis: Building tools of Software prototype

      1. Paper:Cheap,Fast,Anytime,Hardly any interaction,Throw away
      2. Software:Tool selection,Interactive behaviors,Maybe used as part of the real system
    • Animation:Evolutionary prototype
  • Software review(another kind of documentation)

    Informal review approaches:Lack engineering guidelines and controllable processes.

    • peer deskcheck: ask one colleague to look over my work.
    • passround:invite several colleagues to examine a deliverable concurrently.
    • walkthrough:author describes a deliverable and solicits comments.

    Inspection (code)

    Best-estabilished type of formal peer review.

    Inspection Roles:

    • Author: Software Requirements Specification
    • Moderator: inspection leader and organizer
    • Reader/Inspector: paraphrases each requirements for checking defects
    • Recorder: document and confirm detected issues

    • Inspection meeting

      • reader describes each requirement
      • inspector brings up

    • Defect Checklist (in the review or a separate section?)

      • Organization and Completeness
      • Correctness
      • Quality attributes
      • Special Issues

    • Challenges in software review

      • Large requirements documents:priority and risk
      • Large inspection teams:reduce redundancy
      • Geographical separation of inspectors
  • Testing(validation of software)
    • For detecting missing, erroneous, or unnecessary requirements
    • Generate test cases
    • Walkthrough the specification with the test cases
    • Result analysis

Chapter 4:software design

requirements specification: what

design specification:how

software design definition:

A description of the structure of the software to be implemented, the data models and structures used by the system, the interfaces between system components and, sometimes, the algorithms used.

Software design:

  • Architectural design: The overall structure of the system. A model that describes how the system is organized as a set of communicating components. Design Patterns and Priciples
  • Detailed Design:Strategy, Methods and Tools

Architectural design

Designing the overall structure of the system.

A model that describes how the system is organized as a set of communicating components

  • Block diagram

  • Design Patterns

    Each pattern provides a solution for a kind of design problems under certain conditions

    Knowledge reuse

    Written in natural language

    • Layered architecture pattern
    • Repository architecture pattern
    • Client-server pattern
    • Pipe and filter pattern
    • MVC pattern

      Compare Design Pattern with Specification Pattern.

  • Application architectures

    • Design principles

      • Abstraction: focus on the nature rather than details.
      • Refinement:
      • Information hide: implementation details are hidden. The process and data of a module should be hidden from the modules that do not need them.
      • Modulization

        Decompose the software system into several interrelated modules.

        Each module performs a sub-function and can be independently applied.

        All the modules form a software system that satisfies user requirements.

      • Module independence:

        1. organize items for the same use into a same room(cohesion)
        2. purchase different items for different use(coupling)
        3. independent modules are easier to design, develop, test and maintain.

      • Cohesion:degree of interaction in one module(deep degree)

        • Informational CohesionEach operation has separate code and operates on the same data structure. performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structure.

        1. Informational Cohesion

          A module has informational cohesion if it performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structure

        2. 例 句 : All the element modules in Cohesion have concentrated on one action
        3. Communicational Cohesion: performs a series of actions related by the procedure to be followed by the product, but in addition all the actions operate on the same data.
        4. Procedural Cohesion: performs a series of actions related by the procedure to be followed by the product.
        5. Temporal Cohesion: to perform a series of actions related in time.
        6. Logical CohesionAn operation that is likely not to be called: performs so short a series of related actions, one of which is selected by the calling module.

          Problem:

          1.Interface may be difficult to understand.

          2.Code for more than one action may be intertwined.

          3.Difficult to reuse.

        7. Coincidental CohesionA module with unrelated operations: performs so short a period of timeunrelated actions.

          Problem:1. degrades maintainability 2.modules are not reusable

          Solution: break into separate modules, each performing one task.

        Another version of various interpretations of Cohesion:

        1. Functional Cohesion: Every essential element for a single computation is contained in the component. A functional cohesion performs the task and functions. It is an ideal situation.

      1. Sequential Cohesion: An element outputs some data that becomes the input for other element, i.e., data flow between the parts. It occurs naturally in functional programming languages.

        1. Communicational Cohesion: Two elements operate on the same input data or contribute towards the same output data. Example- update record int the database and send it to the printer.

      2. Procedural Cohesion: Elements of procedural cohesion ensure the order of execution. Actions are still weakly connected and unlikely to be reusable. Ex- calculate student GPA, print student record, calculate cumulative GPA, print cumulative GPA.

        1. Temporal Cohesion: The elements are related by their timing involved. A module connected with temporal cohesion all the tasks must be executed in the same time-span. This cohesion contains the code for initializing all the parts of the system. Lots of different activities occur, all at init time.

      3. Logical Cohesion: The elements are logically related and not functionally. Ex- A component reads inputs from tape, disk, and network. All the code for these functions is in the same component. Operations are related, but the functions are significantly different.

        1. Coincidental Cohesion: The elements are not related(unrelated). The elements have no conceptual relationship other than location in source code. It is accidental and the worst form of cohesion. Ex- print next line and reverse the characters of a string in a single component.

      • Coupling:degree of interation between different modules(light degree)

        1. Data Coupling: Two modules are data coupled if all parameters are homogeneous data items [simple parameters, or data structures all of whose elements are used by called module]

          Data coupling: modules share data by passing in values, each of which is basic data, such as strings, ints, etc., and only share that data (such as passing an integer to a function that calculates the square root).

        2. Stamp Coupling, where several modules share a complex data structure Two modules are stamp coupled if a data structure is passed as a parameter, but the called module operates on some but not all of the individual components of the data structure
        3. Control Coupling, in which one module invokes another, passing Control variables such as switches and flags that the invoked module uses to select a function Two modules are control coupled if one passes an element of control to the other.
        4. Common Coupling: Two modules have write access to global data.
        5. The term “Content Coupling” can also be used to refer to data from another module or to refer to data from another module. Two modules are content coupled if one directly references contents of the other

        Another version of the explanation for various coupling:

        1. Data Coupling: If the dependency between the modules is based on the fact that they communicate by passing only data, then the modules are said to be data coupled. In data coupling, the components are independent to each other and communicating through data. Module communications don’t contain tramp data. Example-customer billing system.
        2. Stamp Coupling In stamp coupling, the complete data structure is passed from one module to another module. Therefore, it involves tramp data. It may be necessary due to efficiency factors- this choice made by the insightful designer, not a lazy programmer.
        3. Control Coupling: If the modules communicate by passing control information, then they are said to be control coupled. It can be bad if parameters indicate completely different behavior and good if parameters allow factoring and reuse of functionality. Example- sort function that takes comparison function as an argument.
        4. Common Coupling: The modules have shared data such as global data structures.The changes in global data mean tracing back to all modules which access that data to evaluate the effect of the change. So it has got disadvantages like difficulty in reusing modules, reduced ability to control data accesses and reduced maintainability.
        5. Content Coupling: In a content coupling, one module can modify the data of another module or control flow is passed from one module to the other module. This is the worst form of coupling and should be avoided.
      • Good design has high cohesion and low coupling.
  • Tools for architectural design
    • Hierarchy chart
    • HIPO(Hierachy plus Input-Process-Output)

      A hierarchy chart+a set of IPO(input-process-output) charts

Detailed design

Designing the algorithms of each module, data structure and interfaces.

  • Flowchart
  • Problem Analysis Diagram(PAD

Chapter 5:software testing

Software testing definition

A set of activities for identifying failures in a software or system to obtain user satisfaction.

Definitions

  1. Test case:A set of input values + execution pre-conditions + expected output + execution post-conditions

    Test case = Input Output Pre and Post Conditions

  2. Test case instantiation:

  3. A mechanism for determining whether a program has passed or failed a Test

    • Mechanism
    • Matamorphic
  4. Why use software testing?
    • Demonstrate consistency between software program and requirements
    • Discover incorrect behaviors of the software
    • Not able to prove the correctness of the software program

Testing levels (Unit/Component testing, Integration testing, Acceptance testing)

  • Unit/Component testing

    Features:

    • Testing on components
    • Applicable to a piece of independent program
    • Usually with source code
    • Identified defects are directly fixed
    • Discovering errors at an early stage

    • Diver:

      • A Software component or test tool that replaces a component that takes care of the control and/or calling of a software component.
      • Receives testing data, transmits to tested unit, starts tested unit and prints result.
      • Simplest: Main function

    • Stub:

      • A skeletal or special-purpose implementation of a software module, used to develop or test a component that calls the stub or otherwise depends on it
      • Processes few data and returns values to the calling component.
      • Simplest: assign constant values to the outputs
  • Integration Testing

    • Big Bang integration

      • Test each unit and integrate units simultaneously.
      • Defects are difficult to isolate.
      • After unit testing, drivers and stubs will not be used any more

    • Top-down Integration

      • Test the top level first, take the unit called by top level as stubs, then test the second level, take the unit that has been tested as driver unit sequentially.

      • Advantages:

        • Isolating defects
        • Stubs can be reused for developing real components
        • Discovering design problems at an early stage
      • Disadvantage: Low-level components may not be fully tested

    • Bottom-up Integration

      • Test the bottom level first, set up driver unit for it, then test the upper level, take the unit that has been tested as stub sequentially.
      • No stub required!

      • Advantages:

        • Isolating defects
        • Low-level components can be fully tested since they are called by drivers avoiding defensive programming problem.
      • Disadvantage:Design problems are detected late

    • Sandwich Integration

      • The middle interface is tested separately, so there are more tests at the top and bottom
      • Bottom-up for operation units
      • Top-down for logic units
      • Test the interfaces of the two kinds

  • Acceptance testing:Objective is to obtain customer or user acceptance of the software
    • User acceptance
    • Operational acceptance
    • Contractual acceptance
    • Regulatory acceptance
    • Alpha test

      The user conducts Alpha test at the developer’s site in a controlled environment

    • Beta test

      The end users of the software work in multiple customer locations

  • Example of Metamorphic Testing F(x)=sinx

  • Different testing levels:

    • The simpler the Driver and Stub in Unit/Component Testing, the better

Software testing methods-white box and black box

White-box testing

Can access source code/inner structure of program, base the test cases on the inner structure of the software program.

  • Static analysis: Test without executing

    • NULL pointers
    • Use of uninitialized data
    • Incorrect usage of APIs
    • Buffer overruns
    • Error handling issues
    • Unreachable code
  • Dynamic analysis: Test while running (Usually used for unit testing)

  • Differet covering criteria:

    All kinds of coverage are ranked from high to low in terms of coverage degree:

    1. Path Coverage
    2. Combinatory coverage
    3. Clause/Branch coverage
    4. Clause coverage
    5. Branch coverage
    6. Statement coverage
  • Path coverage:

    Designing test cases that enable the execution of each path at least once.

    Every possible path from start to finish is taken

  • Combinatorial coverage: Designing test cases that enable the coverage of each possible combination of the clauses of each decision.

    (Every combination of conditions in each decision occurs at least once)

  • Branch/Clause Coverage

    Each clause can be true and false and each branch can be true and false

  • Clause coverage: Designing test cases that enable each clause to evaluate to each possible value.

    Each of the atomic predicates takes true and false once

    Predicate an assertion, predicate, or predicate

    Clause clause

    Clause Coverage Example:

    • Active clause coverage(Same as MCDC/ Modified Condition/Decision Coverage

      The TF clause for each predicate is called the active/major clause

      MCDC(corrected condition decision override) : the entry and exit points of each program module should be considered to be called at least once, and the decision of each program to all possible result values should be converted at least once;

      The program’s decisions are decomposed into bool conditions connected by the logical operator (and,or), each of which is independent of the resulting value of the decision.

    • Branch coverage/decision coverage: Designing test cases that enable the execution of each branch of each decision at least once.

      (Take true branch and false branch at least once for each judgment)

    • Statement coverage: Designing test cases that enable the execution of each statement at least once.

      (Execute each statement and statement at least once and walk through every box and diamond regardless of your true and false values.)

    • Graph coverage:

      • Node coverage
      • Edge coverage

Black-box testing

Test case design based on the specification of the software product

  • Input space partitioning

    (There should be no overlap and all possible inputs should be partitioned)

    • IDM(Input Domain Modeling) approach

      1. Interface-based IDM:Developing characteristics directly from input parameters to the program

        • Missing some important combinations of parameters since each parameter is analyzed in isolation
        • Easy to translate abstract tests into executable test cases
        • Easy to identify characteristics

      2. Functionality-based IDM:Developing characteristics from a functional or behavioral view of the program

        • Likely to yield better test cases since it includes more semantic information
        • If the system is large and complex, or the specifications are informal and incomplete, it can be hard to design reasonable characteristics
        • Requirements are available before the software is implemented and IDM can start early in the development
        • Harder to generate executable test cases
  • Boundary value analysis

  • Different black box testing techniques for different specification languages

    • Finite state machine
    • UML
    • Scenario-based
    • Z,B,SOFL

  • Tool support for black-box testing

    • Test case generation(MC/DC / Modified Condition/Decision Coverage)
    • Expected result generation
  • Grey-box (no further discussion)

Chapter 6:object oriented software development

Basic concept of object-oriented

  1. The Object (objects)

    An entity with a well-defined boundary

    and identity that encapsulates state and behavior.

  2. Class (Class)

    A set of objects that share the same properties and behaviors.

  3. Inheritance (Inheritance)

    Subclasses inherit all features of their superclasses:

    • attributes
    • operations
    • relationships
    • stereotypes, tags, constraints

    Subclasses can add new features

    Subclasses can override superclass operations

  4. Message

    A specification of a communication between objects that conveys information with the expectation that activity will ensue.

  5. Abstraction (abstract)
    • Emphasizes relevant characteristics
    • Suppresses other characteristics
  6. Encapsulation (packaging)

    In design, attributes usually have private visibility (encapsulation).

  7. Polymorphism (Polymorphism)

    Different implementation behind a single interface.

    Polymorphism = “many forms”. A polymorphic operation has many implementations

Object-oriented analysis and design

Four steps in object-oriented analysis
  1. Identifying objects and classes.
  2. Identifying the object relationships.
  3. Identifying the attributes.
  4. Identifying services.

UML(Unified Modeling Language)

  • Class diagram

    • Most widely use diagram of UML.
    • Static view of a system.
    • used for specifying structure, interface and relationships between classes that from the foundation of system architecture.

    • What’s in a class:

      • ClassName:UpperCamelCase
      • Attribute: visibility(+ – #) name : type [multiplicity] = initialValue

        (Nothing but the name)

        lowerCamelCase

      • Operations: visibility(+ – #) name(direction parameterName : parameterType = default,…) : returnType

        lowerCamelCase

    • Relationships between classes

      • Aggregation (polymerization): The relationship between elements is global and local. The aggregation relationship emphasizes the relationship between the whole and the parts, in which the parts can exist apart from the whole.

        It is represented by a hollow diamond

      • Composition (combination): The relationship between elements is also global and local. But the difference is that the parts cannot exist in isolation from the whole.

        It’s a solid diamond

      • Dependence (depend on)A dependency is a weak relationship between a class and another class. In this case, the student picks up the money and gives it to the police.

        It’s indicated by a dotted arrow

      • Association (link): Association is a strong relationship, their relationship is more lasting and stable.

        For example, students come out from home, students and home is a kind of association. This relationship is relatively stable. There are unidirectional and bidirectional associations. If one class knows or refers to another class and the other does not know or does not refer to it, the two classes are unidirectional.

        Use a solid line arrow (one-way connection) or a solid line (two-way connection)

      • Generalization: Denotes inheritance
      • Realization: Indicates the implementation of an interface
    • Associations between Classes are called associations(assiciation between Classes means links between the objects of that class) and links between Ojects
    • Multiplicity is used to constrain the number of objects participating in a connection

    • Generalization: The connection between a more general element and a more specific element

      Subclasses have all the features of Superclasses

  • Use-case diagram

    The context of the system to be built and the functionality provided by that system.

  • Sequence diagram

    Message:an arrow from sender to the receiver

    1. Synchronous message
    2. Asynchronous message
    3. Response message
  • State Machine Diagram

Object-oriented testing:

  • Individual class testing

    • Random
    • Partition testing(state,attribute,function)
  • Integration testing