software engineering cse470 fall 2001 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Software Engineering CSE470 (Fall 2001) PowerPoint Presentation
Download Presentation
Software Engineering CSE470 (Fall 2001)

Loading in 2 Seconds...

play fullscreen
1 / 555

Software Engineering CSE470 (Fall 2001) - PowerPoint PPT Presentation


  • 328 Views
  • Uploaded on

Software Engineering CSE470 (Fall 2001). Instructors: Dr. B. Cheng (Sect. 1-3) Dr. W. McUmber (Sect. 4-6). Acknowledgments. G. Coombs L. Dillon M. Heimdahl R. Stephenson National Science Foundation: VESL (Visions of Embedded Systems Laboratory) CDA-9700732

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Software Engineering CSE470 (Fall 2001)' - albert


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
software engineering cse470 fall 2001

Software Engineering CSE470(Fall 2001)

Instructors:

Dr. B. Cheng (Sect. 1-3)

Dr. W. McUmber (Sect. 4-6)

Software Engineering CSE470: Cheng and McUmber

acknowledgments
Acknowledgments
  • G. Coombs
  • L. Dillon
  • M. Heimdahl
  • R. Stephenson
  • National Science Foundation:
    • VESL (Visions of Embedded Systems Laboratory)
    • CDA-9700732
  • Tony Torre, Detroit Diesel Corp.

Software Engineering CSE470: Cheng and McUmber

what is software engineering
The study of systematic and effective processes and technologies for supporting software development and maintenance activities

Improve quality

Reduce costs

What is Software Engineering ???

Software Engineering CSE470: Cheng and McUmber

historical perspective
Historical Perspective
  • 1940s: computers invented
  • 1950s: assembly language, Fortran
  • 1960s: COBOL, ALGOL, PL/1, operating systems

1969: First conference on Software Eng

  • 1970s: multi-user systems, databases, structured programming

Software Engineering CSE470: Cheng and McUmber

historical perspective cont
Historical Perspective (cont.)
  • 1980s: networking, personal computing, embedded systems, parallel architectures
  • 1990s: information superhighway, distributed systems, OO
  • 2000s: virtual reality, voice recognition, video conferencing, global computing, ...

Software Engineering CSE470: Cheng and McUmber

hardware costs vs software costs of overall costs
Hardware Costs vs Software Costs(% of overall costs)

s/w costs

h/w costs

Software Engineering CSE470: Cheng and McUmber

why is software so expensive
Why is software so expensive?
  • Hardware has made great advances
  • But, software has made great advances ...
  • Do the least understood tasks in software
  • When task is simple & understood, encode it in hardware
  • Demand more and more of software

Software Engineering CSE470: Cheng and McUmber

size of programs continues to grow
Size of programs continues to grow
  • Trivial: 1 month, 1 programmer, 500 LOC,
    • Intro programming assignments
  • Very small: 4 months, 1 programmer, 2000 LOC
    • Course project
  • Small: 2 years, 3 programmers, 50K LOC
    • Nuclear power plant, pace maker
  • Medium: 3 years, 10s of programmers, 100K LOC
    • Optimizing compiler

Software Engineering CSE470: Cheng and McUmber

size of programs continues to grow1
Size of programs continues to grow
  • Large: 5 years, 100s of programmers, 1M LOC
    • MS Word, Excel
  • Very large: 10 years, 1000s of programmers, 10M LOC
    • Air traffic control,
    • Telecommunications, space shuttle

Software Engineering CSE470: Cheng and McUmber

goals of this course
Goals of this Course
  • Expose you to some of the problems typically encountered in software eng
  • Expose you to some of the techniques that have been found to be effective
  • Requires more rigor
  • Often appears “obvious”
  • (but only after being learned)

Software Engineering CSE470: Cheng and McUmber

overview of course
Overview of Course
  • Emphasis on analysis and design
  • Learn/apply new techniques for software development
  • Learn to work with a group
  • Improve technical writing skills
  • Become up to date on current trends in SE
  • Explore presentation media

Software Engineering CSE470: Cheng and McUmber

what s the problem
What’s the problem?
  • Software cannot be built fast enough to keep up with
    • H/W advances
    • Rising expectations
    • Feature explosion
  • Increasing need for high reliability software

Software Engineering CSE470: Cheng and McUmber

what s the problem1
What’s the problem?
  • Software is difficult to maintain

“aging software”

  • Difficult to estimate software costs and schedules
  • Too many projects fail
    • Arianne Missile
    • Denver Airport Baggage System

Software Engineering CSE470: Cheng and McUmber

why is software engineering needed
Why is software engineering needed?
  • To predict time, effort, and cost
  • To improve software quality
  • To improve maintainability
  • To meet increasing demands
  • To lower software costs
  • To successfully build large, complex software systems
  • Tofacilitate group effort in developing software

Software Engineering CSE470: Cheng and McUmber

structure of course
Structure of Course
  • (Short) assignments over readings
  • In lab assignments (various SE tools)
  • Group projects (prototype, analysis, design)
  • One hour exam
  • Presentations: oral presentations, prototype demos

Software Engineering CSE470: Cheng and McUmber

software engineering

Software Engineering

A Brief Introduction

Software Engineering CSE470: Cheng and McUmber

software engineering phases
Software Engineering Phases
  • Definition: What?
  • Development: How?
  • Maintenance: Managing change
  • Umbrella Activities: Throughout lifecycle

Software Engineering CSE470: Cheng and McUmber

definition
Definition
  • Requirements definition and analysis
    • Developer must understand
      • Application domain
      • Required functionality
      • Required performance
      • User interface

Software Engineering CSE470: Cheng and McUmber

definition cont
Project planning

Allocate resources

Estimate costs

Define work tasks

Define schedule

System analysis

Allocate system resources to

Hardware

Software

Users

Definition (cont.)

Software Engineering CSE470: Cheng and McUmber

development
Development
  • Software design
    • User interface design
    • High-level design
      • Define modular components
      • Define major data structures
    • Detailed design
      • Define algorithms and procedural detail

Software Engineering CSE470: Cheng and McUmber

development cont
Coding

Develop code for each module

Unit testing

Integration

Combine modules

System testing

Development (cont.)

Software Engineering CSE470: Cheng and McUmber

maintenance
Maintenance
  • Correction - Fix software defects
  • Adaptation - Accommodate changes
    • New hardware
    • New company policies
  • Enhancement - Add functionality
  • Prevention - make more maintainable

Software Engineering CSE470: Cheng and McUmber

umbrella activities
Umbrella Activities
  • Reviews - assure quality
  • Documentation - improve maintainability
  • Version control - track changes
  • Configuration management - integrity of collection of components

Software Engineering CSE470: Cheng and McUmber

software engineering costs
Software Engineering Costs

Software Engineering CSE470: Cheng and McUmber

software engineering costs1
Software Engineering Costs

Software Engineering CSE470: Cheng and McUmber

relative costs to fix errors
Relative Costs to Fix Errors

Software Engineering CSE470: Cheng and McUmber

waterfall process model
Waterfall Process Model

Requirements

Design

Coding

Testing

Maintenance

Software Engineering CSE470: Cheng and McUmber

prototyping process model

Requirements

Quick Design

Prototype

Evaluate

Design

Prototyping Process Model

Software Engineering CSE470: Cheng and McUmber

when to use prototyping
When to use prototyping?
  • Help the customer pin down the requirements
    • Concrete model to “test out”
    • Often done via the user interface
  • Explore alternative solutions to a troublesome component
    • e.g., determine if an approach gives acceptable performance
  • Improve morale
    • Partially running system provides visibility into a project

Software Engineering CSE470: Cheng and McUmber

spiral process model

Planning

Risk Analysis

Customer

Evaluation

Engineering

Spiral Process Model

Software Engineering CSE470: Cheng and McUmber

process models
Process Models
  • Idealized views of the process
  • Different models are often used for different subprocesses
    • may use spiral model for overall development
      • prototyping for a particularly complex component
      • waterfall model for other components

Software Engineering CSE470: Cheng and McUmber

capability maturity model
Level 1: Initial

success depends on people

Level 2: Repeatable

track cost, schedule, functionality

Level 3: Defined

use standardized processes

Level 4: Managed

collect detailed metrics

Level 5: Optimizing

continuous process improvement

“built-in” process improvement

Capability Maturity Model

Software Engineering CSE470: Cheng and McUmber

why is software development so difficult
Communication

Between customer and developer

Poor problem definition is largest cause of failed software projects

Within development team

More people = more communication

New programmers need training

Project characteristics

Novelty

Changing requirements

5 x cost during development

up to 100 x cost during maintenance

Hardware/software configuration

Security requirements

Real time requirements

Reliability requirements

Why is software development so difficult?

Software Engineering CSE470: Cheng and McUmber

why is software development difficult cont
Personnel characteristics

Ability

Prior experience

Communication skills

Team cooperation

Training

Facilities and resources

Identification

Acquisition

Management issues

Realistic goals

Cost estimation

Scheduling

Resource allocation

Quality assurance

Version control

Contracts

Why is software development difficult?(cont.)

Software Engineering CSE470: Cheng and McUmber

summary
Summary
  • Software lifecycle consist of
    • Definition (what)
    • Development (how)
    • Maintenance (change)
  • Different process models concentrate on different aspects
    • Waterfall model: maintainability
    • Prototype model: clarifying requirements
    • Spiral model: identifying risk
  • Maintenance costs much more than development

Software Engineering CSE470: Cheng and McUmber

bottom line
Bottom Line
  • U.S. software is a major part of our societal infrastructure
    • Costs upwards of $200 billion/year
  • Need to
    • Improve software quality
    • Reduce software costs/risks

Software Engineering CSE470: Cheng and McUmber

systems engineering

Systems Engineering

Software Engineering CSE470: Cheng and McUmber

computer system engineering
Computer System Engineering
  • Computer System Engineering is a problem-solving activity.
    • Itemize desired system functions
    • Analyze them
    • Allocate functions to individual system elements
  • Systems Analyst (computer systems engineer)
    • Start with customer-defined goals and constraints
    • Derive a representation of function, performance, interfaces, design constraints, and information structure
    • That can be allocated to each of the generic system elements (i.e., Software, Hardware, People, database, documentation, procedures)
  • Focus on WHAT, NOT how.

Software Engineering CSE470: Cheng and McUmber

criteria for system configuration technical
Criteria for System Configuration: Technical

Criteria for allocation of function and performance to generic system elements:

  • Technical Analysis: (existence of necessary technology, function and performance assured, maintainability)
  • Environmental Interfaces: (proposed configuration integrate with external environment, interoperability)
  • Off-the-shelf options must be considered.
  • Manufacturing evaluation: (facilities and equipment available, quality assured?)

Software Engineering CSE470: Cheng and McUmber

criteria for system configuration business issues
Criteria for System Configuration: Business Issues

Criteria for allocation of function and performance to generic system elements:

  • Project_Considerations: (cost, schedules, and risks)
  • Business_Considerations: (marketability, profitability)
  • Legal_Considerations: (liability, proprietary issues, infringement?)
  • Human issues: (personnel trained? political problems, customer understanding of problem)

Software Engineering CSE470: Cheng and McUmber

hardware and hardware engineering
Hardware and Hardware Engineering
  • Characteristics:
    • Components are packaged as individual building blocks
    • Standardized interfaces among components
    • Large number of off-the-shelf components
    • Performance, cost, and availability easily determined/measured
  • Hardware configuration built from a hierarchy of "building blocks."

Software Engineering CSE470: Cheng and McUmber

hardware engineering
Hardware Engineering
  • Phases to system engineering of hardware:
    • Development Planning and requirements analysis:
      • best classes of hardware for problem,
      • availability of hardware
      • type of interface required
      • identification of what needs to be designed and built
    • Establish a Plan or "road map" for design implementation
      • May involve a hardware specification.
      • Use CAE/CAD to develop a prototype (breadboard)
      • Develop printed circuit (PC) boards
      • Manufacturing of boards

Software Engineering CSE470: Cheng and McUmber

software and software engineering
Software and Software Engineering
  • Function may be the implementation of a sequential procedure for data manipulation
  • Performance may not be explicitly defined (exception is real-time systems)
  • Software element of computer-based system consists of two classes of programs, data, and documentation
    • Application_Software:
      • implements the procedure that is required to accommodate information processing functions
    • System Software:
      • implements control functions that enable application software to interface with other system elements

Software Engineering CSE470: Cheng and McUmber

three high level phases of software engineering
Three high-level phases of Software Engineering
  • Definition phase:
    • Software planning step Software Project Plan
      • scope of project,
      • risk,
      • resource identification
      • cost and schedule estimates
    • Software Requirements Analysis Requirements Specification
      • System element allocated to software is defined in detail.
      • Formal information domain analysis to establish models of information flow and structure (expand to produce specification)
      • Prototype of software is built and evaluated by customer
      • Performance requirements or resource limits defined in terms of software characteristics
    • Definition and Requirements must be performed in cooperation

Software Engineering CSE470: Cheng and McUmber

third phase of software engineering
Third Phase of Software Engineering
  • Development Phase:
    • Translate set of requirements into an operational system element
      • Design Design Specification
      • Coding (appropriate programming language or CASE tool)
    • Should be able to directly trace detail design descriptions from code.
  • Verification, release, and maintenance phase:
    • Testing software: Testing Plan
      • to find maximum number of errors before shipping
    • Prepare software for release Quality Assurance
    • Maintain software throughout its lifetime

Software Engineering CSE470: Cheng and McUmber

structured design design issues
Structured Design: Design Issues
  • Modularity Criteria:
    • Decomposability: decompose large problem into easier to solve subproblems
    • Composability: how well modules can be reused to create other systems
    • Understandability: how easily understood without other reference info
    • Continuity: make small changes and have them reflected in corresponding changes in one or a few modules
    • Protection: architectural characteristic to reduce propagation of side effects of a given error in a module.

Software Engineering CSE470: Cheng and McUmber

design issues
Design Issues
  • Basic Design Principle:
    • Linguistic modular units: correspond to syntactic units in implementation language
    • Few interfaces: minimize the number of interfaces between modules
    • Small interfaces (weak coupling): minimize amount of info moving across interfaces
    • Explicit interfaces: when modules do interact, should be in obvious way
    • Information hiding: all info about module is hidden from outside access

Software Engineering CSE470: Cheng and McUmber

design heuristics
Design Heuristics
  • Evaluate "First-cut" program structure
    • Reduce coupling:
    • Improve cohesion
    • Use exploding: common process exists in 2 or more modules
    • Use imploding: if high coupling exists, implode to reduce control transfer, reference to global data, and interface complexity
  • Minimize Structures with high fan-out ; Strive for Fan-in as depth increases
  • Keep scope effect of a module within scope of control of that module effect of module should be in deeper nesting
  • Evaluate module interfaces:
    • Reduce complexity
    • Reduce redundancy
    • Improve consistency

Software Engineering CSE470: Cheng and McUmber

design heuristics cont d
Design Heuristics (cont’d)
  • Define predicatable functions for modules, but not too restrictive:
    • Black box modules are predictable
    • Restricting module processing to single subfunction (high cohesion)
    • High maintenance: if randomly restrict local data structure size, options within control flow, or types of external interface
  • "Single-entry-single-exit" modules: Avoid "Pathological Connections"
    • Enter at top, exit at bottom
    • Pathological connection: entry into middle of module
  • Package SW based on design constraints and portability requirements
    • Assemble SW for specific processing environment
    • Program may "overlay" itself in memory reorganize group modules according to degree of repetition, access frequency, and interval of calls
    • Separate out modules only used once.

Software Engineering CSE470: Cheng and McUmber

design postprocessing
Design Postprocessing
  • After Transaction or transform analysis: complete documentation to be included as part of architectural design
  • Processing narrative for each module
  • Interface description for each module
  • Definition of local and global data structures
  • Description of all design restrictions
  • Perform review of preliminary design
  • "optimization" (as required or necessary)

Software Engineering CSE470: Cheng and McUmber

design optimization
Design Optimization
  • Objectives:
    • Smallest number of modules (within effective modularity criteria)
    • Least complex data structure for given purpose
  • Refinement of program structure during early design stages is best
  • Time-critical applications may require further refinements for optimizations in later stages (detailed design and coding)

Software Engineering CSE470: Cheng and McUmber

embedded systems introduction

Embedded Systems Introduction

Software Engineering CSE470: Cheng and McUmber

what is an embedded system
What is an Embedded System?
  • Definition of an embedded computer system:
    • is a digital system.
    • uses a microprocessor (usually).
    • runs software for some or all of its functions.
    • frequently used as a controller.

Software Engineering CSE470: Cheng and McUmber

what an embedded system is not
What an embedded system is NOT.
  • Not a computer system that is used primarily for processing.
  • Not a software system on a PC or Unix box.
  • Not a traditional business or scientific application.

Software Engineering CSE470: Cheng and McUmber

examples of embedded systems

Automotive systems: electronic

dashboards, ABS brakes,

transmission controls.

Medical instrument’s controls:

CAT scanners, implanted heart

monitors, etc.

Controls for digital equipment: CD players, TV remote,

programmable sprinklers, household appliances, etc.

Examples of Embedded Systems

Software Engineering CSE470: Cheng and McUmber

why embedded
Why ‘embedded’?
  • Because the processor is ‘inside’ some other system.
  • A microprocessor is ‘embedded’ into your TV, car, or appliance.
  • The consumer does not think about performing processing,
  • Considers running a machine or `making something work’.

Software Engineering CSE470: Cheng and McUmber

special characteristics
Special Characteristics

hardware andsoftware (in one system)

concurrency (several

processes working at

same time)

timing (often real time)

sensors and

actuators

(for inputs

and outputs)

synchronization (this process

must complete before this

process begins)

Software Engineering CSE470: Cheng and McUmber

how are embedded systems different than traditional software
How are embedded systems different than traditional software?
  • Responding to sensors (Was this button pushed?)
  • Turning on actuators (Turn on power to the boiler.)
  • Real-time (Respond to temperature change within 3 seconds.)

Software Engineering CSE470: Cheng and McUmber

differences between es and traditional software development
Differences between ES and traditional software development
  • Not dealing with only sequential code.
  • Routine can stop at completion or in response to an external event.
  • Many parts of system might be running concurrently.
  • Safety-critical component of many systems.

Software Engineering CSE470: Cheng and McUmber

small and many
Small and Many!
  • Most embedded systems use 4-, 8-, or 16-bit processors. 32-bit used for intensive applications like printer controls.
  • 8-bit processors have about 64K of memory, that limits amount of code.
  • “By 1990 a total of about 45 million recognizable computers (i.e., PCs, Macintosh, even CP/M systems) were in place. Yet over 1 billion microprocessors and microcontrollers were shipped in that year alone!”

Ganssle, J. The Art of Programming Embedded Systems Academic Press, 1992, San Diego, Cal.

Software Engineering CSE470: Cheng and McUmber

hardware or software
hardwareorsoftware?
  • Where to place functionality?
    • ex: A Sort algorithm
      • Faster in hardware, but more expensive.
      • More flexible in software but slower.
  • Must be able to explore these various trade-offs:
    • Cost.
    • Speed.
    • Reliability.
    • Form (size, weight, and power constraints.)

Software Engineering CSE470: Cheng and McUmber

hardware software codesign or codesign
hardware/software Codesign or‘Codesign’
  • Model the hardware and the software system in a unified approach.
  • Use similar design models.
  • Need for ‘model continuity’ spanning levels of the design process.

Software Engineering CSE470: Cheng and McUmber

traditional embedded system development approach
Traditional Embedded System Development Approach
  • Decide on the hardware
  • Give the chip to the software people.
  • Software programmer must make software ‘fit’ on the chip and only use that hardware’s capabilities.

Software Engineering CSE470: Cheng and McUmber

increased complexity
Increased Complexity
  • Systems are becoming more and more complex.
  • Harder to think about total design.
  • Harder to fix ‘bugs.’
  • Harder to maintain systems over time.
  • Therefore, the traditional development process has to change,

Software Engineering CSE470: Cheng and McUmber

less time to develop
Less Time to Develop
  • In embedded electronics, the total design cycle must decrease.
  • Historically, design for automotive electronic systems takes 3-5 years to develop.
  • Must become a 1-3 year development cycle.
  • Must still be reliable and safe.

B. Wilkie, R. Frank and J. Suchyta - Motorola Semiconductor Products Sectors, ‘Silicon or Software: The Foundation of Automotive Electronics’, IEEE Vehicular Tech., August 95.

Software Engineering CSE470: Cheng and McUmber

solutions to complexity
Solutions to Complexity:
  • Need to keep design process abstract for a longer period of time.
  • Decomposable hierarchy (object-oriented).
  • Reuse previous designs:
    • When a design changes, reuse similar sections.
    • Don’t throw away last year’s design and start from scratch!
  • Automated verification systems.

Software Engineering CSE470: Cheng and McUmber

example fly by wire airplane
Example: Fly-by-Wire Airplane
  • How would you start to think about developing this complex/large system?
  • What are potential problems with deciding on the hardware right away?
  • What are possible concurrent systems needs?
  • What type of timing constraints might be needed?

Software Engineering CSE470: Cheng and McUmber

fly by wire airplane continued
Fly-by-Wire Airplane Continued
  • What would be the sensors and actuators of this system?
  • How concerned should developers be about the safety of the system?
  • Would testing be enough?

Software Engineering CSE470: Cheng and McUmber

intentionally blank
Intentionally Blank

Software Engineering CSE470: Cheng and McUmber

the problems with software engineering

The Problems with Software Engineering

Where do we go wrong?

The UML lecture notes are based in part on those developed originally by Mats PE Heimdahl

Software Engineering CSE470: Cheng and McUmber

common problems
The requirements are wrong

Incomplete, inconsistent, or ambiguous

The developer and the customer did not interpret the requirements the same way

Requirements drift

The requirements tend to change throughout the project

Late design changes

Continual change

The functionality of the system continually changes

Many changes come late in the project

Many changes during maintenance

Breakdown of system structure

The system finally becomes unusable

Common Problems

Software Engineering CSE470: Cheng and McUmber

solutions
Solutions
  • Rigorous requirements and planning stage
    • Make sure all stakeholders understand and agree on the requirements
  • Structure the system design to accommodate change
    • Isolate parts that are likely to change
    • Modularize so changes are contained
    • Attempt to not compromise system structure during change

Software Engineering CSE470: Cheng and McUmber

use cases and scenarios
Use-Cases and Scenarios
  • A powerful approach to find out what the requirements on the system are
  • Helps the analysts identify
    • The various users of the system
      • Humans, software, and machines
    • The functions the system must provide
  • Provide more stable requirements

Software Engineering CSE470: Cheng and McUmber

intentionally blank1
Intentionally Blank

Software Engineering CSE470: Cheng and McUmber

intentionally blank2
Intentionally Blank

Software Engineering CSE470: Cheng and McUmber

object oriented development

Object-Oriented Development

Software Engineering CSE470: Cheng and McUmber

the oo solution
The OO Solution
  • The problem domain is relatively constant
    • Creating cards
      • Assemble the card and get the right thing at the right place
    • Auto pilot
      • Get a plane from point A to point B using the available control surfaces
  • The functionality and data representation is what is likely to change
    • Creating cards
      • The type of information and placement of information changes often
      • The options available to the user evolve with time
    • Auto pilot
      • The hardware interfaces are different between different models
      • The operational modes vary between models and evolve over time

Structure the system based on the structure of the problem domain, NOT based on the structure of the solution

Software Engineering CSE470: Cheng and McUmber

what is oo
What is OO
  • A way of thinking about a problem (software) based on abstractions of concepts that exist in the real world
  • OO is not constrained by implementation language (C, Pascal, FORTRAN , etc. will work)

Software Engineering CSE470: Cheng and McUmber

what is not oo
What is not OO
  • Using an “object oriented” language (C++, Eiffel, Smalltalk)
    • You can easily misuse the OO support in these languages
  • Using an “OO notation” for design
    • Misuse the notation for a non-OO design
  • Calling what you do OO
    • Management and customers like OO, therefore, that is what we are doing

OO is not the answer to all your problems

Software Engineering CSE470: Cheng and McUmber

several complementary models
Several Complementary Models
  • Structural Models
    • Describes the structure of the objects in a system
      • Structure of individual objects (attributes and operations)
      • Relationships between the objects (inheritance, sharing, and associations)
      • Clustering of objects in logical packages and on the actual hardware
  • Dynamic models (behavioral models)
    • The aspects related to sequencing of operations
      • Changes to attributes and sequences of changes
      • The control aspects of the system

Software Engineering CSE470: Cheng and McUmber

intentionally blank3
Intentionally Blank

Software Engineering CSE470: Cheng and McUmber

the oo development process

The OO Development Process

Software Engineering CSE470: Cheng and McUmber

we will cover
We Will Cover
  • Requirements specification
    • Very briefly
  • Iterative development
  • Different models
    • Three distinct models for which you can use UML
      • Domain (or conceptual) model
      • Analysis (specification) model
      • Design (implementation) model
  • How do we move between the models

Software Engineering CSE470: Cheng and McUmber

process overview

Inception

Elaboration

Transition

Construction 1

Construction 2

Construction 3

Construction n

Process Overview
  • Inception
  • Elaboration
  • Construction
    • Many iterations
  • Transition

Software Engineering CSE470: Cheng and McUmber

inception
Inception
  • Creation of the basic idea that we want to implement (presumably with software)
  • Could take many shapes
    • A discussion over a beer at the pub
    • A full fledged feasibility study
  • Figure out (roughly)
    • The business case
      • How much money will this make the company
    • Project scope

Software Engineering CSE470: Cheng and McUmber

elaboration
Elaboration
  • Answer the following:
    • What is it you are going to build?
    • How are you going to build it?
    • What technology are you going to use?
  • Your decisions should be guided by the risks
    • Requirements risks
    • Technological risks
    • Skills risks
    • Political risks

Software Engineering CSE470: Cheng and McUmber

requirements risks
Requirements Risks
  • Poor or wrong requirements a serious problem
  • Use UML notations to help you understand the customers requirements and the inherent structure of the problem domain
    • Use-case diagrams and use cases to understand customer requirements
    • Class diagrams, activity diagrams, and possibly other diagrams to understand the domain

Software Engineering CSE470: Cheng and McUmber

plan the construction phase
Plan the Construction Phase
  • We will never build the entire system at once
    • Incremental development
  • Categorize the use cases
    • “I absolutely must have this function in the system”
    • “I can live without this feature for a little while”
    • “This is an important function, but we might be able to live without it”
  • Time estimate and allocate the use cases to iterations

Software Engineering CSE470: Cheng and McUmber

construction
Construction
  • Construct the system as a series of iterations
    • Each iteration is a “mini” project
      • Analyze the use case, design, code, test, and integrate.
  • Refine your domain model
    • Identify all attributes and operations
    • Define the dynamic behavior of all objects
      • State machines
      • “Contracts”
  • Make decisions influenced by platform and language

Software Engineering CSE470: Cheng and McUmber

transition
Transition
  • The phase between the beta release and the final product
  • Wrap up all the issues that should not be done or cannot be done during the iterations
    • Examples include performance evaluation and optimization
    • Complete system testing
  • No new functionality added
    • Fix bugs
    • Refactor your system a final time

Software Engineering CSE470: Cheng and McUmber

three distinct models
Three Distinct Models
  • A conceptual model (domain model)
    • Try to figure out what is really going on
    • Build a model to better understand the problem
    • Used to communicate with the customer and “domain” experts
  • An analysis model (specification model)
    • Model the software that will implement the system
    • Focus on the software structure and the module interfaces
  • Design model (implementation model)
    • A detailed design of the software
    • Including all attributes and detailed descriptions of the operations

Software Engineering CSE470: Cheng and McUmber

summary1

Inception

Elaboration

Transition

Construction 1

Construction 2

Construction 3

Construction n

Summary
  • Inception
  • Elaboration
  • Construction
    • Many iterations
  • Transition

Software Engineering CSE470: Cheng and McUmber

intentionally blank4
Intentionally Blank

Software Engineering CSE470: Cheng and McUmber

use cases and scenarios1

Use Cases and Scenarios

Software Engineering CSE470: Cheng and McUmber

we will cover1
We Will Cover
  • What is a use-case
    • Use-case versus user interaction
  • Use-Case diagrams
    • The constructs in the use-case diagrams
  • Capturing the use-case
    • High-level use-case
    • Extended use-case
    • Difference between use case and scenario

Software Engineering CSE470: Cheng and McUmber

what is a use case
What is a Use-Case
  • A use-case captures some user visible function
  • This may be a large or small function
    • Depends on the level of detail in your modeling effort
  • A use-case achieves a discrete goal for the user
  • Examples
    • Format a document
    • Request an elevator
  • How are the use cases found (captured or elicited)?

Software Engineering CSE470: Cheng and McUmber

user goals versus user interactions
User Goals versus User Interactions
  • Consider the following when formatting a document
      • Define a style
      • Change a style
      • Copy a style from one document to the next
    • versus
      • Format a document
      • Ensure consistent formatting of two documents
  • The latter is a user goal
    • Something the user wants to achieve
  • The former are user interactions
    • Things the user does to the system to achieve the goal

Software Engineering CSE470: Cheng and McUmber

goals and interactions
Goals and Interactions
  • There is a place for both goals and interactions
  • Understand what the system shall do
    • Capture the user goals
  • Understand how the user will achieve the goals
    • Capture user interactions
    • Sequences of user interactions
  • Thus, start with the user goals and then refine the user goals into several (many) user interactions

Software Engineering CSE470: Cheng and McUmber

use case diagrams post

Use Case

POST

System Boundary

Buy Item

Log In

Cashier

Customer

Refund a Purchased Item

Use-Case Diagrams (POST)

POST: Point of Sale Terminal

Adapted from Larman “Applying UML and Patterns”

Software Engineering CSE470: Cheng and McUmber

another example

Set Limits

Update Accounts

Accounting System

Trading Manager

Analyze Risk

«uses»

Valuation

«uses»

Price Deal

Trader

Capture Deal

Salesperson

«extends»

Limit Exceeded

Another Example

Financial Trading System

Adapted from Fowler “UML Distilled”

Software Engineering CSE470: Cheng and McUmber

uses and extends
Includes

You have a piece of behavior that is similar across many use cases

Break this out as a separate use-case and let the other ones “include” it

Examples include

Valuation

Validate user interaction

Sanity check on sensor inputs

Check for proper authorization

Extends

A use-case is similar to another one but does a little bit more

Put the normal behavior in one use-case and the exceptional behavior somewhere else

Capture the normal behavior

Try to figure out what can go wrong in each step

Capture the exceptional cases in separate use-cases

Makes it a lot easier to understand

Uses and Extends

Software Engineering CSE470: Cheng and McUmber

includes
Includes
  • You have a piece of behavior that is similar across many use cases
  • Break this out as a separate use-case and let the other ones “include” it
  • Examples include
    • Valuation
    • Validate user interaction
    • Sanity check on sensor inputs
    • Check for proper authorization

Software Engineering CSE470: Cheng and McUmber

extends
Extends
  • A use-case is similar to another one but does a little bit more
  • Put the normal behavior in one use-case and the exceptional behavior somewhere else
    • Capture the normal behavior
    • Try to figure out what can go wrong in each step
    • Capture the exceptional cases in separate use-cases
  • Makes it a lot easier to understand

Software Engineering CSE470: Cheng and McUmber

setting the system boundary
Setting the System Boundary
  • The system boundary will affect your actors and use-cases

Adapted from Larman “Applying UML and Patterns”

Software Engineering CSE470: Cheng and McUmber

a different boundary
A Different Boundary
  • Let us view the whole store as our system

Store

Buy Item

Refund a Purchased Item

Customer

Adapted from Larman “Applying UML and Patterns”

Software Engineering CSE470: Cheng and McUmber

partial post
Partial POST

Adapted from Larman “Applying UML and Patterns”

Software Engineering CSE470: Cheng and McUmber

post use case
POST Use-Case

Use case:Buy Item

Actors: Customer (initiator), Cashier

Type: Primary

Description: The Customer arrives at the

checkout with items to purchase.

The Cashier records the purchase

items and collects a payment.

On completion the Customer

leaves with the items

Software Engineering CSE470: Cheng and McUmber

post expanded use case
POST Expanded Use-Case

Use case:Buy Item

Actors: Customer (initiator), Cashier

Type: Primary and essential

Description: The Customer arrives at the checkout with items

to purchase. The Cashier records the purchase

items and collects a payment. On completion the

Customer leaves with the items.

Cross Ref.: Requirements XX, YY, and ZZ

Use-Cases: Cashier must have completed the Log In use-case

Software Engineering CSE470: Cheng and McUmber

the home heating system

Water Valve

Water Pump

Home

Hot Water

Controller

Burner

90

80

70

60

50

Off

On

Fuel

Control Panel

Temp Sensor

The Home Heating System

Fuel Valve

Software Engineering CSE470: Cheng and McUmber

home heating use case diagram
Home Heating Use-Case Diagram

Software Engineering CSE470: Cheng and McUmber

home heating use cases
Home Heating Use-Cases

Use case:Power Up

Actors: Home Owner (initiator)

Type: Primary and essential

Description:The Home Owner turns the power on. Each room

is temperature checked. If a room is below the

the desired temperature the valve for the room is

opened, the water pump started, the fuel valve

opened, and the burner ignited.

If the temperature in all rooms is above the desired

temperature, no actions are taken.

Cross Ref.: Requirements XX, YY, and ZZ

Use-Cases: None

Software Engineering CSE470: Cheng and McUmber

modified home heating
Modified Home Heating

Software Engineering CSE470: Cheng and McUmber

slide113
HACS
  • Homework assignment and collection are an integral part of any educational system. Today, this task is performed manually. What we want the homework assignment distribution and collection system (HACS for short) to do is to automate this process.
  • HACS will be used by the instructor to distribute the homework assignments, review the students’ solutions, distribute suggested solution, and distribute student grades on each assignment.
  • HACS shall also help the students by automatically distributing the assignments to the students, provide a facility where the students can submit their solutions, remind the students when an assignment is almost due, remind the students when an assignment is overdue.

Software Engineering CSE470: Cheng and McUmber

hacs use case diagram
HACS Use-Case Diagram

Software Engineering CSE470: Cheng and McUmber

hacs use cases
HACS Use-Cases

Use case:Distribute Assignments

Actors: Instructor (initiator)

Type: Primary and essential

Description: The Instructor completes an assignment and submits

it to the system. The instructor will also submit the

due date and the class the assignment is assigned for.

Cross Ref.: Requirements XX, YY, and ZZ

Use-Cases:Configure HACS must be done before any user

(Instructor or Student) can use HACS

Software Engineering CSE470: Cheng and McUmber

alternate hacs
Alternate HACS

Software Engineering CSE470: Cheng and McUmber

alternate hacs use cases
Alternate HACS Use-Cases

Use case:Distribute Assignments

Actors: Instructor (initiator), Student

Type: Primary and essential

Description: The Instructor completes an assignment and submits

it to the system. The instructor will also submit the

delivery date, due date, and the class the assignment

is assigned for. The system will at the due date mail

the assignment to the student.

Cross Ref.: Requirements XX, YY, and ZZ

Use-Cases:Configure HACS must be done before any user

(Instructor or Student) can use HACS

Software Engineering CSE470: Cheng and McUmber

when to use use cases
When to use Use-Cases
  • In short, always!!!
  • Requirements is the toughest part of software development
    • Use-Cases is a powerful tool to understand
      • Who your users are (including interacting systems)
      • What functions the system shall provide
      • How these functions work at a high level
  • Spend adequate time on requirements and in the elaboration phase

Software Engineering CSE470: Cheng and McUmber

how it fits together

Preliminary Investigation Report

Requirements Specification

Use-Cases

a. All High Level

b. Some Expanded

Prototypes

Use-Case Diagram

Budget, Schedule

Draft Conceptual Model

Glossary (data dictionary)

How it Fits Together

Adapted from Larman “Applying UML and Patterns”

Software Engineering CSE470: Cheng and McUmber

conceptual modeling

Conceptual Modeling

A Short Discussion

Software Engineering CSE470: Cheng and McUmber

outline
Outline
  • Conceptual modeling
    • The goal of conceptual modeling
  • The OO solution
  • The object model (conceptual)
    • Syntax and semantics
  • Object modeling approach
    • Home Heating System

Software Engineering CSE470: Cheng and McUmber

conceptual modeling1
Conceptual Modeling
  • Early modeling to understand the problem
  • Conducted in cooperation with the customer
    • Domain experts
      • Domain engineers
  • No real problem analysis if the customer is not involved
  • Power of OO
    • It is simple and people can quickly participate effectively

Software Engineering CSE470: Cheng and McUmber

the oo solution1
The OO Solution
  • The OO model closely resembles the problem domain
    • Base your model on the objects in the problem domain
  • Iteratively refine the high-level model until you have an implementation
    • Attempt to avoid big conceptual jumps during the development process

Software Engineering CSE470: Cheng and McUmber

objects

State of Michigan

Drivers License

VISA

J. Q. Public

A-123456

03-12-63

J. Q. Public

123 4567 887766 998

Objects

Software Engineering CSE470: Cheng and McUmber

attributes and operations

Person objects

Attributes

name

age

height

weight

Operations

move

change-job

abstracts to

Card objects

Card class

Attributes

height

width

id-number

Operations

issue

change

State of Michigan

Drivers License

VISA

J. Q. Public

A-123456

03-12-63

J. Q. Public

123 4567 887766 998

Attributes and Operations

Person class

characteristics of objects
Characteristics of Objects
  • Identity
    • Discrete and distinguishable entities
  • Classification
    • Abstract entities with the same structure (attributes) and behavior (operations) into classes
  • Polymorphism
    • The same operation may behave differently on different classes
  • Inheritance
    • Sharing of attributes and operations based on a hierarchical relationship

Software Engineering CSE470: Cheng and McUmber

intentionally blank5
Intentionally Blank

Software Engineering CSE470: Cheng and McUmber

intentionally blank6
Intentionally Blank

Software Engineering CSE470: Cheng and McUmber

the class diagrams

The Class Diagrams

Software Engineering CSE470: Cheng and McUmber

objects1
Objects
  • Something that makes sense in the application context (application domain)
    • J.Q. Public
    • Joe’s Homework Assignment 1
    • J. Q. Public’s drivers license
  • All objects have identity and are distinguishable
  • NOT objects
    • Person
    • Drivers license

Software Engineering CSE470: Cheng and McUmber

classes
Classes
  • Describes a group of objects with similar properties (attributes), common behavior (operations), common relationships to other classes, and common semantics
  • Person
      • J. Q. Public
      • Joe Smith
      • D. Q. Public
    • Card
      • Credit card
      • Drivers license
      • Teller card

Software Engineering CSE470: Cheng and McUmber

class diagrams

Class diagram

Instance diagram

Person

Person

D. Q. Public

J. Q. Public

32

35

Class with attributes

Objects with values

Objects have an identity

Do not explicitly list

object identifiers

SSN OK!

Class Diagrams

Software Engineering CSE470: Cheng and McUmber

examples
Examples

Software Engineering CSE470: Cheng and McUmber

operations and methods
Transformation that can be applied to or performed by an object

May have arguments

Operations and Methods

Software Engineering CSE470: Cheng and McUmber

object notation summary
Object Notation - Summary

Software Engineering CSE470: Cheng and McUmber

associations
Associations
  • Conceptual connection between classes
    • A credit card is issued-by a bank
    • A person works-for a company

Class diagrams

Person

Company

Instance diagram

8

Works-for

J.Q. Public

Michigan State Univ

35

Software Engineering CSE470: Cheng and McUmber

associations are bi directional
Associations are Bi-directional
  • There is no direction implied in an association (Rumbaugh - OMT)

Country

name

City

name

Has-capital

Person

name

Drivers-license

lic.-number: integer

Is-issued

Software Engineering CSE470: Cheng and McUmber

associations have direction
Associations Have Direction
  • Unified adds a direction indicator
    • Inconsistently used

Country

name

City

name

Has-capital

Person

name

Drivers-license

lic.-number: integer

Is-issued

Software Engineering CSE470: Cheng and McUmber

multiplicity
Multiplicity
  • One object can be related to many objects through the same association

One person holds one credit card

One person can hold zero or more credit cards (* stands for many)

Software Engineering CSE470: Cheng and McUmber

multiplicity cont

Credit-Card

8

Holds

123 456 789

Person

J. Q. Public

Person

35

D.Q. Public

8

Holds

Credit-Card

32

111 222 333

Multiplicity (Cont.)

One person can hold zero or more credit cards (0..*)

Each card has zero or one holder (0..1)

Software Engineering CSE470: Cheng and McUmber

multiplicity cont1

Credit-Card

3

Authorized

123 456 789

Person

8

Holds

J. Q. Public

35

8

Holds

3

Authorized

Credit-Card

111 222 333

3

Authorized

Person

D. Q. Public

8

Holds

32

Credit-Card

3

Authorized

111 222 333

Multiplicity (Cont.)
  • One person can hold zero or more credit cards (0..*)
  • Each card has one holder (no indication or 1)
  • Each card has one or more authorized users (1..*)
  • One person can be authorized to use zero or more cards

Explicit enumeration is also possible (2, 3, 2..5, etc.)

8

Holds

1

0..*

Credit-card

Person

3

Authorized

card-number: integer

name: String

1..*

0..*

Software Engineering CSE470: Cheng and McUmber

higher order associations

Language

Project

C++

Compiler

Person

J. Q. Public

35

Language

Project

LISP

TicTacToe

Higher order associations
  • Ternary association
    • Project, language, person
  • Seldom needed (and should be avoided)

Software Engineering CSE470: Cheng and McUmber

link attributes

How to represent salary and job title?

Use a link attribute!

Link Attributes
  • Associations can have properties the same way objects have properties

Software Engineering CSE470: Cheng and McUmber

folding link attributes

Why not this?

Salary and job title are properties of the job not the person

In this case, a link attribute is the only solution

Folding Link Attributes

Software Engineering CSE470: Cheng and McUmber

role names
Role Names
  • Attach names to the ends of an association to clarify its meaning

Software Engineering CSE470: Cheng and McUmber

aggregation

Aggregation symbol

Aggregation
  • A special association, the is-part-of association
    • A sentence is part of a paragraph (a paragraph consists of sentences)
    • A paragraph is part of a document (a document consists of paragraphs)

Software Engineering CSE470: Cheng and McUmber

aggregation cont
Aggregation (Cont.)
  • Often used in parts explosion

Software Engineering CSE470: Cheng and McUmber

generalization and inheritance
The is-a association

Cards have many properties in common

Generalize the common properties to a separate class, the base-card

Let all cards inherit from this class, all cards is-a base-card (plus possibly something more)

Generalization and Inheritance

Software Engineering CSE470: Cheng and McUmber

aggregation versus association
Aggregation Versus Association
  • Can you use the phrase is-part-of or is-made-of
  • Are operations automatically applied to the parts (for example, move) - aggregation
  • Not clear what it should be……

Software Engineering CSE470: Cheng and McUmber

aggregation versus inheritance
Do not confuse the is-a relation (inheritance) with the is-part-of relation (aggregation)

Use inheritance for special cases of a general concept

Use aggregation for parts explosion

4

Wheel

Body

Car

Gearbox

Engine

Minivan

Compact

Jeep

Roll Bar

Aggregation Versus Inheritance

Software Engineering CSE470: Cheng and McUmber

recursive aggregates
Recursive Aggregates
  • A recursive aggregate contains (directly or indirectly) an instance of the same kind of aggregate

Software Engineering CSE470: Cheng and McUmber

object modeling summary
Classes

Name

Attributes

Operations

Associations

Roles

Link attributes

Aggregation

Inheritance

Object Modeling Summary

Software Engineering CSE470: Cheng and McUmber

intentionally blank7
Intentionally Blank

Software Engineering CSE470: Cheng and McUmber

intentionally blank8
Intentionally Blank

Software Engineering CSE470: Cheng and McUmber

object modeling approach

Object Modeling Approach

Software Engineering CSE470: Cheng and McUmber

object modeling approach1
Object Modeling Approach
  • Start with a problem statement
    • High-level requirements
  • Define object model
    • Identify objects and classes
    • Prepare data dictionary
    • Identify associations and aggregations
    • Identify attributes of objects and links
    • Organize and simplify using inheritance
    • Iterate and refine the model
    • Group classes into modules

Software Engineering CSE470: Cheng and McUmber

the home heating system1

Water Valve

Water Pump

Home

Hot Water

Controller

Burner

Fuel Valve

90

80

70

60

50

Off

On

Fuel

Control Panel

Temp Sensor

The Home Heating System
home heating requirements
The software shall control the heat in each room

The room shall be heated when the temperature is 2F below desired temp

The room shall no longer be heated when the temperature is 2F above desired temp

The flow of heat to each room shall be individually controlled by opening and closing its water valve

The valve shall be open when the room needs heat and closed otherwise

The user shall set the desired temperature on the thermostat

The operator shall be able to turn the heating system on and off

The furnace must not run when the system is off

When the furnace is not running and a room needs heat, the software shall turn the furnace on

To turn the furnace on the software shall follow these steps

open the fuel valve

turn the burner on

The software shall turn the furnace off when heat is no longer needed in any room

To turn the furnace off the software shall follow these steps

close fuel valve

turn burner off

Home Heating Requirements

The purpose of the software for the Home Heating System is to control the heating system that heats the rooms of a house. The software shall maintain the temperature of each room within a specified range by controlling the heat flow to individual rooms.

Software Engineering CSE470: Cheng and McUmber

identify object classes

Requirements

Statements

Extract

Nouns

Tentative

Object Classes

Eliminate

Spurious Classes

Object

Classes

Candidate Classes

Water Pump

Controller

operator

Hot Water

Home Heating System

house

thermostat

furnace

Burner

range

room

Water Valve

heating system

Fuel Valve

temperature

heat

software

desired temp

Home

Fuel

Temp Sensor

on-off switch

Control Panel

Identify Object Classes

Software Engineering CSE470: Cheng and McUmber

eliminate bad classes
Redundant classes

Classes that represent the same thing with different words

Irrelevant classes

Classes we simply do not care about

Vague classes

Classes with ill defined boundaries

Attributes

Things that describe individual objects

Operations

Sequences of actions are often mistaken for classes

Roles

The name of a class should reflect what it is, not the role it plays

Implementation details

Save that for implementation

Eliminate Bad Classes

Software Engineering CSE470: Cheng and McUmber

eliminate classes

Redundant

Irrelevant

Vague

Attributes

desired temp

heating system

heat

house

Fuel

software

temperature

user

heat flow

home

Hot Water

range

Operations

Roles

Implementation

None

None

None

Fuel Valve

Burner

furnace

Home Heating System

Water Pump

room

Water Valve

operator

Temp Sensor

thermostat

Controller

Control Panel

on-off switch

Eliminate Classes

Software Engineering CSE470: Cheng and McUmber

classes after elimination

Burner

Fuel Valve

Home Heating System

Water Pump

Room

Water Valve

Furnace

Thermostat

Temp Sensor

on-off switch

Operator

Control Panel

Controller

Classes After Elimination

Software Engineering CSE470: Cheng and McUmber

prepare data dictionary
Prepare Data Dictionary
  • Water Tank
    • The storage tank containing the water that circulates in the system.
  • Pump-1
    • The pump pumping water from the Water Tank to the radiators in the rooms

Software Engineering CSE470: Cheng and McUmber

possible associations
Not much information from the prose requirements

A lot of information from the system design

A room consists of a thermometer and a radiator

A radiator consists of a valve and a radiator element

The home heating system consists of a furnace, rooms, a water pump, a control panel, and a controller

The furnace consists of a fuel pump and a burner

The control panel consists of an on-off switch and a thermostat

The controller controls the fuel pump

The controller controls the burner

The controller controls the water pump

The controller monitors the temperature in each room

The controller opens and closes the valves in the rooms

The operator sets the desired temperature

The operator turns the system on and off

The controller gets notified of the new desired temperature

Possible Associations

Software Engineering CSE470: Cheng and McUmber

object model modified
Object Model - Modified

Home Heating

System

3

Runs

Control Panel

Furnace

Water Pump

Burner

Fuel Valve

On-Off Switch

Thermostat

3

Opens/Closes

1..*

3

8

3

Pushes

Adjusts

Ignites

Room

1..*

1..*

Operator

Notifies

3

3

Monitor

8

Heats

Water Valve

Temp Sensor

Controller

attributes
Attributes

Thermostat

desired-temp

On-Off switch

setting

Temp Sensor

temperature

Software Engineering CSE470: Cheng and McUmber

final oo model
Final OO Model

Home Heating

System

3

Runs

Control Panel

Furnace

Water Pump

Burner

Fuel Valve

On-Off Switch

Thermostat

setting

desired-temp

3

Opens/Closes

1..*

3

Ignites

3

8

Pushes

Adjusts

Room

1..*

1..*

Operator

Notifies

3

3

Monitor

8

Heats

Water Valve

Temp Sensor

temperature

Controller

iterate the model

Iterate

Iterate the Model
  • Keep on doing this until you, your customer, and your engineers are happy with the model

Software Engineering CSE470: Cheng and McUmber

operation vs method
Operation vs Method
  • Operation: specifies object behavior
  • Service: represented by set of operns.
  • Message: object requests execution of an opern. from another object by sending it mesg.
  • Method: mesg is matched up with method defined by the class to which the receiving object belongs (or any of its superclasses)
  • Operations of class are public services offered by class.
  • Methods of its classes are the implementations of these operations.

Software Engineering CSE470: Cheng and McUmber

intentionally blank9
Intentionally Blank

Software Engineering CSE470: Cheng and McUmber

intentionally blank10
Intentionally Blank

Software Engineering CSE470: Cheng and McUmber

oo using uml dynamic models

OO Using UML:Dynamic Models

Defining how the objects behave

Software Engineering CSE470: Cheng and McUmber

overview
Overview
  • The object model describes the structure of the system (objects, attributes, and operations)
  • The dynamic model describes how the objects change state (how the attributes change) and in which order the state changes can take place
  • Several models used to find the appropriate dynamic behavior
    • Interaction diagrams
    • Activity diagrams
    • State Diagrams
  • Uses finite state machines and expresses the changes in terms of events and states

Software Engineering CSE470: Cheng and McUmber

interaction diagrams

Interaction Diagrams

Software Engineering CSE470: Cheng and McUmber

we will cover2
We Will Cover
  • Why interaction diagrams?
  • Sequence diagrams
    • Capturing use-cases
    • Dealing with concurrency
  • Collaboration diagrams
  • When to use what
  • When to use interaction diagrams

Software Engineering CSE470: Cheng and McUmber

different types of interaction diagrams
Different Types of Interaction Diagrams
  • An Interaction Diagram typically captures a use-case
    • A sequence of user interactions
  • Sequence diagrams
    • Highlight the sequencing of the interactions between objects
  • Collaboration diagrams
    • Highlight the structure of the components (objects) involved in the interaction

Software Engineering CSE470: Cheng and McUmber

home heating use case
Home Heating Use-Case

Use case:Power Up

Actors: Home Owner (initiator)

Type: Primary and essential

Description:The Home Owner turns the power on. Each room

is temperature checked. If a room is below the

the desired temperature the valve for the room is

opened, the water pump started, the fuel valve

opened, and the burner ignited.

If the temperature in all rooms is above the desired

temperature, no actions are taken.

Cross Ref.: Requirements XX, YY, and ZZ

Use-Cases: None

Software Engineering CSE470: Cheng and McUmber

conditional behavior
Conditional Behavior
  • Something you will encounter trying to capture complex use-cases
    • The user does something. If this something is X do this… If this something is Y do something else… If this something is Z…
  • Split the diagram into several
    • Split the use-case also
  • Use the conditional message
    • Could become messy
  • Remember, clarity is the goal!

Software Engineering CSE470: Cheng and McUmber

comparison
Comparison
  • Both diagrams capture the same information
    • People just have different preferences
  • We prefer sequence diagrams
    • They clearly highlight the order of things
    • Invaluable when reasoning about multi-tasking
  • Others like collaboration diagrams
    • Shows the static structure
      • Very useful when organizing classes into packages
  • We get the structure from the Class Diagrams

Software Engineering CSE470: Cheng and McUmber

when to use interaction diagrams
When to Use Interaction Diagrams
  • When you want to clarify and explore single use-cases involving several objects
    • Quickly becomes unruly if you do not watch it
  • If you are interested in one object over many use-cases -- state transition diagrams
  • If you are interested in many objects over many use cases -- activity diagrams

Software Engineering CSE470: Cheng and McUmber

state diagrams

State Diagrams

Software Engineering CSE470: Cheng and McUmber

we will cover3
We Will Cover
  • State Machines
    • An alternate way of capturing scenarios
      • Large classes of scenarios
  • Syntax and Semantics
  • When to use state machines

Software Engineering CSE470: Cheng and McUmber

events conditions and states
Events, Conditions, and States
  • Event: something that happens at a point in time
      • Operator presses self-test button
      • The alarm goes off
  • Condition: something that has a duration
      • The fuel level is high
      • The alarm is on
  • State : an abstraction of the attributes and links of an object (or entire system)
      • The controller is in the state self-test after the self-test button has been pressed and the rest-button has not yet been pressed
      • The tank is in the state too-low when the fuel level has been below level-low for alarm-threshold seconds

Software Engineering CSE470: Cheng and McUmber

making a phone call scenario
Making a Phone Call Scenario

To make a call, the caller lifts receiver. The caller gets a dial dial tone and the caller dials digit (x). The dial tone ends. The caller completes dialing the number. The callee phone begins ringing at the same time a ringing begins in caller phone. When the callee answers the called phone stops ringing and ringing ends in caller phone. The phones are now connected. The caller hangs up and the phones are disconnected. The callee hangs up.

Software Engineering CSE470: Cheng and McUmber

partial class diagram
Partial Class Diagram

Software Engineering CSE470: Cheng and McUmber

event trace
Event Trace

Caller

Line

Callee

caller lifts receiver

dial tone begins

dials digit (4)

dial tone ends

dials digit (2)

dials digit (3)

dials digit (4)

dials digit (5)

ringing tone

phone rings

callee answers

tone stops

ringing stops

phones connected

phones connected

caller hangs up

phones disconnected

phones disconnected

callee hangs up

state diagram for scenario
State Diagram for Scenario

Idle

on-hook

off-hook

Dial tone

digit(x)

digit(x)

Dialing

valid-number

Ringing

called-phone-answers

Connected

called-phone-hangs-up

Disconnected

scenario 2
Scenario 2

Caller

Line

Callee

caller lifts receiver

dial tone begins

dials digit (4)

dial tone ends

dials digit (2)

dials digit (3)

dials digit (4)

dials digit (5)

busy tone

caller hangs up

modified state machine
Modified State Machine

Idle

on-hook

off-hook

digit(x)

Dial tone

Dialing

digit(x)

valid-number

Busy tone

number-busy

Connecting

routed

Ringing

called-phone-answers

Connected

called-phone-hangs-up

Disconnected

conditions
Sometimes the state transitions are conditional

Idle

on-hook

off-hook

Dial tone

digit(x) [x = 8]

digit(x) [x != 8]

digit(x)

digit(x)

Dial tone

(external)

digit(x)

Dialing

Dialing

valid-number

valid-number

Busy tone

number-busy

Connecting

routed

Ringing

Conditions

Software Engineering CSE470: Cheng and McUmber

operations aka actions
Actions are performed when a transition is taken or performed while in a state

Actions are terminated when leaving the state

Idle

off-hook

Dial tone

on-hook

digit(x)

do/ sound dial tone

Dialing

digit(x)

on-hook

valid-number

Busy tone

on-hook

number-busy

do/ busy tone

Connecting

on-hook

routed

do/ find connection

Ringing

on-hook

do/ ring bell

called-phone-answers / connect line

Connected

on-hook / disconnect line

called-phone-hangs-up / disconnect line

Disconnected

on-hook

Operations (AKA Actions)

Software Engineering CSE470: Cheng and McUmber

hierarchical state machines
Group states with similar characteristics

Enables information hiding

Simplifies the diagrams

Hierarchical State Machines

on-hook

Idle

Dial tone

off-hook

do/ sound dial tone

dial(x) [x is a digit]

dial(x) [x = *]

Make Call

Establish call

Voice Mail

dial(x)

Dialing

valid-number

number-busy

Connecting

on-hook

do/ find connection

Busy tone

do/ busy tone

routed

Ringing

do/ ring bell

called-phone-answers /

connect line

on-hook / disconnect line

Connected

called-phone-hangs-up /

disconnect line

on-hook

Disconnected

information hiding
Information Hiding

Establish call

on-hook

dial(x)

Idle

Dial tone

Dialing

off-hook

do/ sound dial tone

valid-number

dial(x) [x is a digit]

dial(x) [x = *]

number-busy

Make Call

Connecting

do/ find connection

Busy tone

Establish call

do/ busy tone

Voice Mail

routed

on-hook

Ringing

called-phone-answers /

connect line

do/ ring bell

on-hook /

disconnect line

Connected

called-phone-hangs-up /

disconnect line

on-hook

Disconnected

Software Engineering CSE470: Cheng and McUmber

event generalization
Related events can inherit properties from each other

If an event at a lower level occurs - the event at a higher level also occurred

Event attributes

mouse-up.location

mouse-down.device

mouse-button.time

event

time

user-input

device

mouse-button

location

keyboard-key

character

mouse-down

mouse-up

Event Generalization

Software Engineering CSE470: Cheng and McUmber

concurrency1
Some states represent several concurrent concepts

Concurrency is supported by the state machines

Concurrent state machines are separated by dashed lines

Alarms Disabled

out-of-bounds-event

Alarms Enabled

Visual Alarm

reset

On

Off

visual-on

Aural Alarm

reset

On

Off

aural-on

Concurrency

Software Engineering CSE470: Cheng and McUmber

state machines summary
Events

instances in time

Conditions

conditions over time

States

abstraction of the attributes and associations

Transitions

Takes the state machine from one state to the next

Triggered by events

Guarded by conditions

Cause actions to happen

Internal actions

something performed in a state

Hierarchies

allows abstraction and information hiding

Parallelism

models concurrent concepts

State Machines - Summary

Software Engineering CSE470: Cheng and McUmber

when to use state machines
When to use State Machines
  • When you want to describe the behavior of one object for all (or at least many) scenarios that affect that object
  • Not good at showing the interaction between objects
    • Use interaction diagrams or activity diagrams
  • Do not use them for all classes
    • Some methods prescribe this
    • Very time consuming and questionable benefit

Software Engineering CSE470: Cheng and McUmber

coming up with the state diagrams

Coming up with the State Diagrams

Software Engineering CSE470: Cheng and McUmber

modeling approach
Modeling Approach
  • Prepare scenarios
    • Work with the customer
    • Start with normal scenarios
    • Add abnormal scenarios
  • Identify events (often messages)
    • Group into event classes
  • Draw some sequence diagrams
    • Find objects with complex functionality you want to understand better
  • Build a state diagram for the complex classes

Software Engineering CSE470: Cheng and McUmber

scenario 1

close-valve

stop-burner

pump-off

close-water-valve

Scenario-1

Fuel

Valve

Water

Pump

Room

Controller

Burner

request-temp

Every 5s

respond-temp

open-valve

Temp Low

start-burner

pump-on

open-water-valve

request-temp

Every 5s

respond-temp

Temp Normal

scenario 21

close-valve

stop-burner

pump-off

close-water-valve

Scenario-2

Control

Panel

Fuel

Valve

Water

Pump

Room

Controller

Burner

request-temp

Every 5s

respond-temp

desired-temp-change

Desired temp change

request-temp

respond-temp

Every 5s

open-valve

Temp Low

start-burner

pump-on

open-water-valve

request-temp

respond-temp

Every 5s

Temp Normal

dynamic model

Water Pump

pump-on

On

Off

pump-off

Fuel Valve

open-valve

Open

Closed

close-valve

Burner

start-burner

On

Off

stop-burner

Dynamic Model

Software Engineering CSE470: Cheng and McUmber

more dynamic model

Room

Water-Valve

Temp-Sensor

open-water-valve/

wv-open

Idle

Valve

temp-report(x)/

respond-temp(x)

request-temp

close-water-valve/

wv-close

Processing

Request

More Dynamic Model

Software Engineering CSE470: Cheng and McUmber

even more dynamic model

Controller

Temperature

respond-temp(x)[x>desired-temp+2]/stop-heating

timeout(5s)\

request-temp

timeout(5s)\

request-temp

Temp-Low

Temp-Normal

respond-temp(x)[x<desired-temp-2]/start-heating

Home Heating System

timeout(1s)/start-burner

timeout(1s)/

pump-on,open-water-valve

Burner-On

Fuel-Open

start-heating/open-valve

All-Running

All-Off

Fuel-Off

Water-Off

stop-heating/

pump-off,close-water-valve

timeout(1s)/close-valve

timeout(1s)/stop-burner

Even More Dynamic Model

Software Engineering CSE470: Cheng and McUmber

identify key operations
Operations from the object model

Accessing and setting attributes and associations (often not shown)

Operations from events

All events represent some operation

Operations from actions and activities

Actions and activities represent some processing activity within some object

Operations from functions

Each function typically represent one or more operations

Shopping list operations

Inherent operations (what should be there)

Identify Key Operations

Software Engineering CSE470: Cheng and McUmber

complete oo model
Complete OO Model

Software Engineering CSE470: Cheng and McUmber

iterate the model1

Iterate

Iterate the Model
  • Keep on doing this until you, your customer, and your engineers are happy with the model

Software Engineering CSE470: Cheng and McUmber

activity diagrams

Activity Diagrams

Software Engineering CSE470: Cheng and McUmber

we will cover4
We Will Cover
  • History of activity diagrams in UML
    • A highly personal perspective
  • Activity diagrams
  • Swimlanes
  • When to use activity diagrams
    • When not to

Software Engineering CSE470: Cheng and McUmber

activity diagrams1
Activity Diagrams
  • Shows how activities are connected together
    • Shows the order of processing
    • Captures parallelism
  • Mechanisms to express
    • Processing
    • Synchronization
    • Conditional selection of processing
  • A glorified flowchart

Software Engineering CSE470: Cheng and McUmber

why activity diagrams
Why Activity Diagrams
  • Very good question
    • Not part of any previous (UML related) method
    • Introduced to sell products
  • Suitable for modeling of business activities
    • UML and OO is becoming more prevalent in business applications
    • Object frameworks are making an inroad
    • Stay within one development approach and notation
  • Generally a flowchart and I do not really see the need in OO modeling
    • Probably because I do not do business systems

Software Engineering CSE470: Cheng and McUmber

hacs use cases1
HACS Use-Cases

Use case:Distribute Assignments

Actors: Instructor (initiator), Student

Type: Primary and essential

Description: The Instructor completes an assignment and submits

it to the system. The instructor will also submit the

delivery date, due date, and the class the assignment

is assigned for. The system will at the due date mail

the assignment to the student.

Cross Ref.: Requirements XX, YY, and ZZ

Use-Cases:Configure HACS must be done before any user

(Instructor or Student) can use HACS

Software Engineering CSE470: Cheng and McUmber

swimlanes who does what
Swimlanes (Who Does What?)

Software Engineering CSE470: Cheng and McUmber

problems with activity diagrams
Problems with Activity Diagrams
  • They are glorified flowcharts
    • Very easy to make a traditional data-flow oriented design
  • Switching to the OO paradigm is hard enough as it is
    • Extensive use of activity charts can make this shift even harder
  • However...
    • Very powerful when you know how to use them correctly

Software Engineering CSE470: Cheng and McUmber

when to use activity diagrams
When to Use Activity Diagrams
  • Not clear how useful in OO modeling
    • Particularly when modeling control systems
  • Useful when
    • Analyzing a use case (or collection of use cases)
    • Understanding workflow in an organization
    • Working with multi-threaded applications
      • For instance, process control applications
    • Do not use activity diagrams
      • To figure out how objects collaborate
      • See how objects behave over time

Software Engineering CSE470: Cheng and McUmber

approaching a problem

Approaching a Problem

Where do we start?

How do we proceed?

Software Engineering CSE470: Cheng and McUmber

where do we start
Where Do We Start?
  • Start with the requirements
    • Capture your goals and possible constraints
    • Environmental assumptions
  • Use-case analysis to better understand your requirements
    • Find actors and a first round of use-cases
  • Start conceptual modeling
    • Conceptual class diagram
    • Interaction diagrams to clarify use-cases
    • Activity diagrams to understand major processing

Software Engineering CSE470: Cheng and McUmber

how do we continue
How Do We Continue?
  • Refine use-cases
    • Possibly some “real” use-cases
      • Using interface mockups
  • Refine (or restructure) your class diagram
    • Based on your hardware architecture
      • For instance, client server
  • Refine and expand your dynamic model
    • Until you are comfortable that you understand the required behavior
  • Identify most operations and attributes

Software Engineering CSE470: Cheng and McUmber

how do we wrap up
How Do We Wrap Up?
  • Refine the class diagram based on platform and language properties
    • Navigability, public, private, etc
    • Class libraries
  • Identify all operations
    • Not the trivial get, set, etc.
  • Write a contract for each operation
  • Define a collection of invariants for each class
  • Implement

Software Engineering CSE470: Cheng and McUmber

process overview1

Inception

Elaboration

Transition

Construction 1

Construction 2

Construction 3

Construction n

Process Overview
  • Inception
  • Elaboration
  • Construction
    • Many iterations
  • Transition

Software Engineering CSE470: Cheng and McUmber

requirements analysis

Requirements Analysis

Defining the WHAT

Software Engineering CSE470: Cheng and McUmber

requirements
Requirements
  • Specify functionality
    • model objects and resources
    • model behavior
  • Specify data interfaces
    • type, quantity, frequency, reliability
    • providers, receivers
    • operational profile (expected scenarios)
    • stress profile (worst case scenarios)

Software Engineering CSE470: Cheng and McUmber

requirements1
Requirements
  • Specify interfaces
    • Control interfaces (APIs)
    • User interfaces - functionality and style
    • Hardware interfaces
  • Specify error handling
  • Identify potential modifications

Software Engineering CSE470: Cheng and McUmber

requirements2
Requirements
  • Identify necessary constraints
    • performance, security, reliability
  • Identify areas of risk
    • alternatives to be explored
  • Specify validation plans
  • Specify documentation to be provided

Software Engineering CSE470: Cheng and McUmber

analysis principles
Analysis Principles
  • Document reason for specific requirements
  • Prioritize requirements
    • High, medium, low
  • Ignore implementation details
    • Need to know feasible solutions can be developed
    • If feasibility is a concern, then propose alternatives to be explored
  • Be prepared to change

Software Engineering CSE470: Cheng and McUmber

reviewing a requirements document
Is it ambiguous?

Carefully define terms and use these terms

Is it consistent?

Is it complete?

Vague requirements

Omitted requirements

Is it verifiable?

Is it realistic?

Does it plan for change?

Does it not overly constrain the problem?

Have alternatives been considered and explored?

Is it clearly presented?

Precise, concise, clear

diagram complex objects and behaviors

Is it what the customer wants?

Reviewing a requirements document

Software Engineering CSE470: Cheng and McUmber

why is requirements analysis difficult
Why is requirements analysis difficult?
  • Communication: misunderstandings between the customer and the analyst
    • Analyst doesn’t understand the domain
    • Customer doesn’t understand alternatives and trade-offs
  • Problem complexity
    • Inconsistencies in problem statement
    • Omissions/incompleteness in problem statement
    • Inappropriate detail in problem statement

Software Engineering CSE470: Cheng and McUmber

why is requirements analysis difficult1
Why is requirements analysis difficult?
  • Need to accommodate change
    • Hard to predict change
    • Hard to plan for change
    • Hard to forsee the impact of change

Software Engineering CSE470: Cheng and McUmber

first law of software engineering
First Law of Software Engineering

“No matter where you are in the system lifecycle, the system will change, and the desire to change it will persist throughout the lifecycle.”

Software Engineering CSE470: Cheng and McUmber

reasons for changing requirements
Poor communication

Inaccurate requirements analysis

Failure to consider alternatives

New users

New customer goals

New customer environment

New technology

Competition

Software is seen as malleable

Reasons for changing requirements

Changes made after the requirements are approved increase cost and schedule

Software Engineering CSE470: Cheng and McUmber

requirements products
Requirements Products
  • Specification document
    • Agreement between customer and developer
    • Validation criteria for software
  • Preliminary users manual
  • Prototype
    • If user interaction is important
    • If resources are available
  • Review by customer and developer
    • Iteration is almost always required

Software Engineering CSE470: Cheng and McUmber

analysis steps to follow
Analysis: Steps to follow
  • Obtain a problem statement
  • Develop use cases (depict scenarios of use)
  • Build an object model and data dictionary
  • Develop a dynamic model
    • state and sequence diagrams
  • Verify, iterate, and refine the models
  • Produce analysis document

Software Engineering CSE470: Cheng and McUmber

use cases
Use Cases
  • High-level overview of system use
  • Identify scenarios of usage
  • Identify actors of the system:
    • External entities (e.g., users, systems, etc.)
  • Identify system activities
  • Draw connections between actors and activities
  • Identify dependencies between activities (i.e., extends, uses)

Software Engineering CSE470: Cheng and McUmber

analysis object model
Analysis: Object Model
  • Organization of system into classes connected by associations
    • Shows the static structure
    • Organizes and decomposes system into more manageable subsystems
    • Describes real world classes and relationships

Software Engineering CSE470: Cheng and McUmber

analysis object model1
Analysis: Object Model
  • Object model precedes the dynamic model because
    • static structure is usually better defined
    • less dependent on details
    • more stable as the system evolves

Software Engineering CSE470: Cheng and McUmber

analysis object model2
Analysis: Object Model
  • Information comes from
    • The problem statement and use cases
    • Expert knowledge of the application domain
      • Interviews with customer
      • Consultation with experts
      • Outside research performed by analyst
    • General knowledge of the real world

Software Engineering CSE470: Cheng and McUmber

object model steps to follow
Object Model: Steps to follow
  • Identify classes and associations
    • nouns and verbs in a problem description
  • Create data dictionary entry for each
  • Add attributes
  • Combine and organize classes using inheritance

Software Engineering CSE470: Cheng and McUmber

analysis dynamic model
Analysis: Dynamic model
  • Shows the time dependent behavior of the system and the objects in it
  • Expressed in terms of
    • states of objects and activities in states
    • events and actions
  • State diagram summarizes permissible event sequences for objects with important dynamic behavior

Software Engineering CSE470: Cheng and McUmber

dynamic model steps to follow
Dynamic Model: Steps to follow
  • Use cases provide scenarios of typical interaction sequences
  • Identify events between objects (Sequence Diagram)
  • Prepare an event trace for each scenario
  • Build state diagrams
  • Match events between objects to verify consistency

Software Engineering CSE470: Cheng and McUmber

analysis iteration
Analysis: Iteration
  • Analysis model will require multiple passes to complete
  • Look for inconsistencies and revise
  • Look for omissions/vagueness and revise
  • Validate the final model with the customer

Software Engineering CSE470: Cheng and McUmber

object model four main system objects or classes
Object Model: Four main system objects or classes
  • Controller object
    • might be made up of several controllers
    • is the brains of the system.
    • Takes input from the sensors and gives instructions to the actuators.
  • Sensor object
    • environmental objects that gives information to controller.
    • Can be passive (thermometer) or active (button).

Software Engineering CSE470: Cheng and McUmber

embedded systems details

Embedded Systems Details

Software Engineering CSE470: Cheng and McUmber

object model four main system objects continued
Object Model: Four main system objects (continued)
  • Actuator object
    • Environmental objects that are controlled by the controller.
    • Can be turned on or influenced by controller.
    • Examples: User indicator lights, motors, burners.
  • User Interface object
    • A display for the user.
    • Can be made up of both sensors and actuators.
    • Example: machine control panel

Software Engineering CSE470: Cheng and McUmber

step one develop a high level object model
Step One: Develop a high-level object model

Embedded

System

*

*

*

Controller

Actuator

User-Interface

Sensor

Button

Pedal

Inheritance

Class Name

Class

*

Zero or more

Attribute()

Association

Aggregation

Operation()

Software Engineering CSE470: Cheng and McUmber

review of dynamic model
Review of Dynamic Model
  • A dynamic model is a type of state machine.
  • System can only be in one state at a time.
  • Arrows: Transitions
    • from one state to another happen
    • when events happen.
  • Events are labeled on the transitions.
  • Guards are conditions that keep a transition from happen, such as [is in neutral or park ]

Software Engineering CSE470: Cheng and McUmber

step two develop a system level dynamic model

‘On’ button pushed [in neutral or park]

Idle or off state

Running state

‘Off’ button pushed

State

Transition

[ condition ] Guard

Step Two: Develop a system-level dynamic model

Software Engineering CSE470: Cheng and McUmber

example automotive door control
Example: Automotive Door Control
  • The system controls the windows and door locking functions.
  • All doors have window roll up and down controls.
  • Driver’s door has window lock feature.
  • Driver and front passenger have door lock and unlock toggle.
  • Fob unit for locking and unlocking doors, with driver notification (horn honk and lights flash.)
  • Three concurrent systems identified.

Software Engineering CSE470: Cheng and McUmber

summary of development process
Summary of development process
  • The object model shows the real world objects grouped in classes with attributes and operations and associations.
  • The dynamic model shows the control aspects with superstates refined into substates.

Software Engineering CSE470: Cheng and McUmber

review of embedded systems
Review of Embedded Systems
  • Softwarecontroller that is interacting with its hardware environment through sensors and actuators.
  • Concurrency and realtime issues.
  • Safety critical nature of many of these systems.
  • Increased demand for these systems to be designed well.

Software Engineering CSE470: Cheng and McUmber

high level design initial thoughts for embedded systems
High level design: Initial thoughts for embedded systems.
  • Assume there is a hardware environment.
  • Assume that somehow the needed signals are coming from the environment (sensors.)
  • Assume the needed hardware is there to respond to your signals (actuators.)

Software Engineering CSE470: Cheng and McUmber

object model1
Object Model

Class

attribute

operation

  • In UML the object model is the starting place for the modeling process.
  • The object model will include objects and their relationships.
  • The Object Model will be the static, structural aspect of the system.

Software Engineering CSE470: Cheng and McUmber

identify real world objects
Identify Real World Objects
  • Read over the problem description and find the nouns in the text.
  • These nouns are candidates for objects in your object model.
  • Discard unnecessary and incorrect classes.
  • Object classes will include the controller (software unit that will be built), sensors, and actuators.

Software Engineering CSE470: Cheng and McUmber

data dictionary needs to be written
Data Dictionary: needs to be written
  • A written paragraph describing each modeling entity.
  • Needed so that names are non-ambiguous.

Software Engineering CSE470: Cheng and McUmber

class sensor
Class: Sensor
  • Because of the common properties of all sensors, this can be a class of objects, called a superclass.
  • Generalization - this superclass can be generalized into subclasses.
  • Inheritance - each subclass will inherit the properties or features from the superclass.
  • Examples: user interface (buttons etc), thermometers, hardware sensors.

Software Engineering CSE470: Cheng and McUmber

class actuator
Class: Actuator
  • Similarly the actuators will probably become a superclass.
  • Generalization - The various actuators can be generalized into subclasses.
  • Inheritance - each actuator subclass will inherit properties or features from the superclass.
  • Examples: LEDs, motor controls, etc.

Software Engineering CSE470: Cheng and McUmber

the controller
The Controller
  • At an abstract level, this would be only one object in most embedded systems.
  • This object would be refined at lower levels of the modeling process into subsystems or sub-objects.
  • Aggregation could be used to show the parts of the controller.

Software Engineering CSE470: Cheng and McUmber

model itself
Model itself

Class

attribute

operation

  • Graphically a class is shown as a box with the name on top.
  • Attributes (middle third) and operations (bottom third) added eventually.
  • Attributes and operations are not needed for high-level object model.

Software Engineering CSE470: Cheng and McUmber

find the associations
Find the Associations
  • Interaction between objects must be shown by associations or lines draw with labels.
    • ex: line between user button and associated LED.
  • Many times these associations will be a physical connection between objects in an embedded system.
  • Multiplicity must be shown eventually.

Software Engineering CSE470: Cheng and McUmber

example1
Example

Controller

turned on by

reads

Actuators

Sensors

*

*

LED

Motor

Water level

User buttons

Software Engineering CSE470: Cheng and McUmber

conclusion about object model
Conclusion about Object Model:
  • Not very complex at first.
  • More details will come as designer proceeds from abstraction to more and more concreteness.
    • controller will be divided into more objects
    • attributes and operations are identified and included.
  • Starting place for OO Modeling. Sets the stage.

Software Engineering CSE470: Cheng and McUmber

next step dynamic model
Next step: Dynamic Model
  • The dynamic model shows the control aspect of the system.
  • Because embedded systems are mainly controllers, the dynamic model is the ‘key’ model for embedded systems.
  • This model can show the timing aspects.
  • Shows sequence of operations in response to external stimuli.

Software Engineering CSE470: Cheng and McUmber

getting started on a dynamic model
Getting started on a Dynamic Model
  • Helpful to make a scenario:
    • sequence of events that happens in one execution of a system.
    • Example: insert coins, make selection, pop dispensed.
  • Interface (high-level prototyping)
    • a rough draft of user interface will help thinking about the events in an embedded system.

Software Engineering CSE470: Cheng and McUmber

interface type of rapid prototyping
Interface (type of rapid prototyping)

0

1

2

3

4

5

6

7

8

8

enter

clear

cancel

receipts

cash slot

ATM interface from Figure 8.17 by Rumbaugh

Software Engineering CSE470: Cheng and McUmber

continue getting started
continue getting started….
  • Next make an event trace.
    • each object is a vertical line.
    • events as horizontal arrow.
    • time goes from top to bottom.
  • Use previously discussed ‘creation tips.’

Software Engineering CSE470: Cheng and McUmber

example of an event trace
Example of an Event Trace

User

ATM

Consortium

Bank

insert card

request password

enter password

verify account

verify card with bank

bank account OK

account OK

request kind

enter kind

request amount

enter amount

process transaction

process bank transactions

bank transaction succeeds

Event trace for ATM scenario

Example from Figure 8.18 of Rumbaugh

more dynamic modeling

More Dynamic Modeling

Software Engineering CSE470: Cheng and McUmber

dynamic model state diagram
Dynamic Model - State Diagram
  • Graphical representation of a finite state machine.
  • Each ‘state’ represents all the values of the objects in the system.
  • Changing states - transitioning on events.
  • Events - external stimuli
    • ex. button pushed; timer complete; tub full.

Software Engineering CSE470: Cheng and McUmber

review of getting started
Review of getting started:
  • Scenario making: gets us started thinking about events.
  • Interface (high-level prototyping): helps us to think about order of things. (happening in projects)
  • Event trace: helps to know what object is doing what action.
  • State Diagram creation tips.

Software Engineering CSE470: Cheng and McUmber

dynamic models for e s
Dynamic Models for E.S.
  • Dynamic Model for user buttons would be simplistic; modeling might not be needed.
  • Some environmental units might have behavior that should be modeled. (like an engine shifting through speeds)
  • For embedded systems - might only need one significant behavior model (for controller.)
  • Complex models will be decomposed into more detailed behavioral models.
  • Concurrency could be present within a model.

button

pushed

on

off

button

pushed

Software Engineering CSE470: Cheng and McUmber

how dynamic model relates to object model
How dynamic model relates to object model
  • One state diagram for each class (with important behavior.)
  • Each class has concurrent behavior.
  • Aggregation in the Object Model implies concurrency in the Dynamic Model.

Software Engineering CSE470: Cheng and McUmber

examples of aggregation 5 17
Examples of Aggregation (5.17)
  • Object model

Car

Ignition

Transmission

Brake

Accelerator

Each class will need a concurrent state diagram

Software Engineering CSE470: Cheng and McUmber

how to model concurrency within an object

Car

Ignition

turn key to start

release key

[Transmission

in Neutral]

Off

Starting

On

turn key off

Transmission

push R

push N

Neutral

Reverse

push N

push F

Forward

stop

upshift

upshift

First

Second

Third

downshift

downshift

Accelerator

Brake

depress accelerator

depress brake

Off

On

release accelerator

Off

On

release brake

How to model concurrency within an object
how to hide complexity
How to hide complexity
  • Not have a ‘flat’ state diagram
  • Start abstract and then do subdiagrams.
    • use bull’s eye
  • Take one abstract state and expand it with state generalization.

Software Engineering CSE470: Cheng and McUmber

example of nesting and other syntax as well
Example of nesting(and other syntax as well)

coins in(amount) / set balance

Collecting money

coins in(amount) / add to balance

Idle

cancel / refund coins

select(item)

[change<0]

[item empty]

do: test item and compute change

[change=0]

[change>0]

do: dispense item

do: make change

do: move arm

do: move arm

do: push item

to correct row

to correct column

off shelf

Example: lower-level state diagram for Dispense item activity

Software Engineering CSE470: Cheng and McUmber

state generalization
State Generalization

push R

push N

Neutral

Reverse

push F

push N

ex. level 0 Dynamic Model

for a transmission.

Forward

Transmission

push R

push N

Neutral

Reverse

push N

push F

Forward

stop

upshift

upshift

First

Second

Third

downshift

downshift

ex. level 1 Dynamic Model for a transmission.

Software Engineering CSE470: Cheng and McUmber

notation on transitions and in states
Notation on Transitions and in States
  • do: activity
    • takes some time.
    • associated with a state.
  • Guards
    • conditions - boolean
    • [ guard ]
  • Actions :
    • instantaneous
    • associated with an event.
    • /action

event1 (attribs) [condition1]/ action1

State1

do: activity 1

State2

You might need any or

all of these for your project!

Software Engineering CSE470: Cheng and McUmber

checking for completeness and consistency
Checking for completeness and consistency
  • Formal specifications do this better!
    • The mathematical format can allow automation of these types of checks.
  • Every state should have a way in and out.
    • unless starting point or ending point.
  • Look for one object’s Dynamic Model sending an event that doesn’t have any receiving transition in another object’s DM.

Software Engineering CSE470: Cheng and McUmber

things to watch out for
Things to watch out for
  • Think about input from concurrent objects at unexpected times.
    • ex. If more than one ATM machine is trying to access the same account at the same time.
    • User input when not planned. (OK to ignore, but make sure that is what is really wanted.)
  • Take your scenarios and see if they work!
    • Walk through seeing that all the object’s operations/messages has all the needed transitions.

Software Engineering CSE470: Cheng and McUmber

topics covered
Dynamic Model

Synchronization schemes

Exception Handling

Timing including safety critical issues.

Topics Covered:

Software Engineering CSE470: Cheng and McUmber

synchronization
Synchronization
  • In concurrent processing, the actions of the objects are rarely independent of each other.
  • One may need to stop and wait for another process to ‘catch up’ or get to a certain state.
  • Example: In a nuclear power plant, the model would need to reflect waiting for rods to be in place before generating power.

Software Engineering CSE470: Cheng and McUmber

synchronization of states by status detection
Synchronization of Statesby status detection

B

A

A1

B1

event

[A is in state

A2]

A2

B2

Transition between B1 and B2 will not fire until

object A has entered state A2.

Software Engineering CSE470: Cheng and McUmber

synchronization of states by a common event
Synchronization of Statesby a common event

A

B

StateA1

StateB1

event1

event1

StateB2

StateA2

Firing of the two transitions in the two models

will happen at the same time.

Software Engineering CSE470: Cheng and McUmber

synchronization of states by common data
Synchronization of Statesby common data

A

B

StateA1

do: x:=0

StateB1

event

[x=1]

StateA2

do: x:= 1

StateB2

Transition from StateB1 to StateB2 will not fire until

StateA2 has been done. (This assumes shared memory.)

Software Engineering CSE470: Cheng and McUmber

exception handling
Exception Handling
  • Events such as resets and hardware interrupts must be handled.
  • These are called Exceptions.
  • Crucial to terminate the behavior of an object.
  • Needed if user can exit a sequence of states at anytime.

Software Engineering CSE470: Cheng and McUmber

examples of exception handling

Superstate

event1

substate1

substate2

normal exiting by completion

exception event

Examples of exception handling
  • Possible to modeling exiting all the substates of a superstate in UML.
    • Ex. Pushing the N (neutral button) in any of the forward states of a transmission.
  • 2 ways to exit: normal completion and exception.

Software Engineering CSE470: Cheng and McUmber

timing issues in dynamic model
Timing Issues in Dynamic Model
  • Sometimes the firing of a transition is time dependent, especially in embedded systems.
  • Real-time systems might have transitions that are tied to a real-time clock.
  • States might time-out after a certain length of time.
  • Transitions might need to be stalled for a certain length of time.

Software Engineering CSE470: Cheng and McUmber

timing safety critical
Timing (Safety critical)
  • Safety criticalreal-time solutions
    • example:
      • transition out of ‘boiler on’ state after being in this state for 1 hour, even if one expects a transition on temperature>=expected.

Boiler

  • temperature >= expected

On

Off

in ‘boiler on’ state >= 1 hour

(Event on transition could just be labeled ‘1 hour’)

delays in dynamic model
Delays in Dynamic Model
  • Sometimes a transition should not be fired for a certain amount of time.
  • This timing constraint can be modeled as a guard on transition
    • ex.
      • [10 seconds since the exit from state A]
      • This will delay the firing of the transition for 10 seconds.

Software Engineering CSE470: Cheng and McUmber

more timing issues in d m

[time = 2200 hours]

Day

superstate

Night

superstate

[time = 0600 hours]

More Timing Issues in D. M.
  • For a real-time system, the guard might refer to a real-time clock
    • example:
      • changing a traffic signal from day operation to night operation at 10 p.m.
      • because there is no event on transition: ready to fire when the guard is true.

Software Engineering CSE470: Cheng and McUmber

intentionally blank11
Intentionally Blank

Software Engineering CSE470: Cheng and McUmber

intentionally blank12
Intentionally Blank

Software Engineering CSE470: Cheng and McUmber

quality assurance

Quality Assurance

Software Engineering CSE470: Cheng and McUmber

software qualities

Maintainer

Good Documentation

Readable Code

Good Design

Reliability

Correctness

Efficiency

Low Cost

Portability

Increased

productivity

Functionality

Ease of use

Ease of learning

Customer

User

Software Qualities

Software Engineering CSE470: Cheng and McUmber

software quality assurance
Software Quality Assurance
  • Use of analysis to validate artifacts
    • requirements, designs, code, test plans
  • Technical reviews
  • Document reviews
  • Compliance to standards
  • Control of changes

Software Engineering CSE470: Cheng and McUmber

costs of poor quality
Costs of Poor Quality
  • Increased time to find and fix problems
  • Increased cost to distribute modifications
  • Increased customer support
  • Product liability
  • Failure in the market place

Software Engineering CSE470: Cheng and McUmber

qa terminology
QA Terminology
  • Correctness
  • Reliability
  • Testing
  • Debugging
  • Failure
  • Fault
  • Error
  • Verification
  • Validation
  • V&V

Software Engineering CSE470: Cheng and McUmber

terminology
Terminology
  • Correctness:artifact is consistent with its specification
    • Specification could be wrong or incomplete
    • Rarely is software known to be correct
    • Rarely is the specification correct
  • Reliability:probability that the software is correct
    • Statistical measure based on past performance
      • e.g., mean time to failure

Software Engineering CSE470: Cheng and McUmber

more terminology
More terminology
  • Testing:entails executing the software on selected test cases
    • Evaluate the results (oracle)
    • Evaluate the performance
    • Evaluate the ease of use
  • Common Wisdom: Testing reveals bugs but does not guarantee the absence of bugs
    • How should you select test cases?
    • How do you know when to stop testing?

Software Engineering CSE470: Cheng and McUmber

more terminology1
More terminology
  • Failure:an erroneous result
    • incorrect outputs/response for given inputs/stimuli
    • fails to meet real-time constraints
  • Error:incorrect concept
    • may cause failures if not corrected
  • Fault:the cause of one or more failures
    • discovered after release

Software Engineering CSE470: Cheng and McUmber

more terminology2
More terminology
  • Debugging: the process of finding the cause of a “bug” and a way to fix it
    • w/o introducing additional bugs!
  • Verification:process of proving, using mathematical reasoning, that a program is “correct”
    • is expensive and is not always possible
    • is not foolproof

Software Engineering CSE470: Cheng and McUmber

more terminology3
More terminology
  • Validation:process associated with showing that the software performs reasonably well
  • V & V:verification & validation?
    • more typically equated with validation

Software Engineering CSE470: Cheng and McUmber

many different kinds of testing
Many different kinds of testing
  • Unit testing:test individual components
    • test stubs simulate called components
    • test harness simulates “outer” context and maintains stubs
  • Integration testing:combine components and test them
    • follows build plan
  • System testing:test whole system

Software Engineering CSE470: Cheng and McUmber

more kinds of testing
More kinds of testing
  • Acceptance testing:testing to determine if the product is acceptable
  • Regression testing:retesting after the system has been modified
    • determine “old” test cases that must be re-executed
    • determine what new test cases are required

Software Engineering CSE470: Cheng and McUmber

more kinds of testing1
More kinds of testing
  • Black box / functional testing:
    • testing based on specifications
  • White box / structural testing:
    • testing based on looking at the artifact
  • Both black box and white box testing are needed

Software Engineering CSE470: Cheng and McUmber

testing is hard work
Testing is hard work
  • Typically 50% of software development effort goes into testing
    • up to 85% for life-critical software
  • How to identify “good” test cases?
    • high probability of finding a new error
  • Objective is to find errors
    • test case is “successful” if it finds a new error

Software Engineering CSE470: Cheng and McUmber

testing is hard work cont
Testing is hard work (cont.)
  • Psychologically difficult for a programmer to test his/her own code thoroughly
  • Exhaustive testing requires testing all combinations of input values
    • Sorting an array of size 10 containing integers in the range 1 . . 10 has 10! combinations (3,628,800 cases)

Software Engineering CSE470: Cheng and McUmber

testing
Testing
  • CAN:
    • Uncover errors
    • Show specifications are met for specific test cases
    • Be an indication of overall reliability
  • CANNOT:
    • Prove that a program is error-free

Software Engineering CSE470: Cheng and McUmber

testing principles
Testing Principles
  • Tests should be traceable to requirements
  • Tests should be planned long before testing begins
  • Exhaustive testing is not possible
    • 80% of all errors typically occur in 20% of the modules
    • test cases should be chosen to maximize likelihood of finding an error

Software Engineering CSE470: Cheng and McUmber

testing principles cont
Testing Principles (cont.)
  • Testing should be done by someone other than the developers
    • Developers do original testing
    • SQA does independent testing
      • usually black box testing
  • Automated testing tools should be used
    • Reduce testing costs
    • Reduce likelihood of human error

Software Engineering CSE470: Cheng and McUmber

testability
Testability
  • Simple software is easier to test
    • minimize coupling, maximize cohesion
  • Output is sufficient to determine correct behavior
  • Performs its own tests for internal errors
    • raises meaningful exceptions
  • All code is reachable
  • Independent modules can be tested in isolation
  • Documentation is complete and accurate

Software Engineering CSE470: Cheng and McUmber

quality is an on going concern
Quality is an on-going concern
  • You can’t build quality into a system after the fact
  • Quality should be a consideration during every phase of development
  • Plan for testing / validation in all phases
    • requirements -> functional test cases
    • design -> functional and structural test cases
    • code -> enhanced func & struc test cases
    • maintenance -> further enhanced func & struc test cases

Software Engineering CSE470: Cheng and McUmber

debugging
Debugging
  • Find the cause of a failure and fix it
    • an art, not a science
  • Debugging is difficult because
    • symptom may appear long after the fault occurs
    • symptom may be difficult to reproduce
    • symptom may be intermittent
  • Unit testing helps localize errors

Software Engineering CSE470: Cheng and McUmber

software reviews
Software Reviews
  • Individuals read and comment on the software artifacts
  • Very human intensive
  • Overriding evidence shows that it
    • improves quality and productivity
    • reduces cost
  • It is usually one of the first activities to be dropped when schedules get tight

Software Engineering CSE470: Cheng and McUmber

software reviews cont
Software Reviews (cont.)
  • Applicable to all software artifacts
    • code inspections
    • requirements and design reviews
    • walk-throughs
  • Recent research shows that
    • particular kind of review, size of team, etc. doesn’t matter
    • need at least one good, dedicated person doing the review

Software Engineering CSE470: Cheng and McUmber

typical review team
Typical Review Team
  • Developer -- presents the material
  • Moderator -- keeps the review on track
    • makes sure everyone abides by the process
  • Secretary -- takes minutes, documents problems found
  • Optionally
    • Apprentice -- learning about the project
    • Domain expert -- familiar with the domain and can verify assumptions

Software Engineering CSE470: Cheng and McUmber

software review guidelines
Software Review Guidelines
  • Review the artifact
    • don’t attack the developer
  • Stick to an agenda
  • Limit debate
  • Identify problems, not solutions
  • Keep accurate notes
  • Establish and follow evaluation guidelines
  • Limit number of participants

Software Engineering CSE470: Cheng and McUmber

technical review guidelines cont
Technical Review Guidelines (cont.)
  • Prepare beforehand
    • both developers and reviewers
  • Allocate resources for reviews
    • people and time
  • Possible outcomes
    • accept product as is
    • reject product outright
    • accept product provisionally

Software Engineering CSE470: Cheng and McUmber

sample evaluation guidelines code inspection
Sample evaluation Guidelines: Code Inspection
  • Has the design been correctly translated to code?
  • Are the language features used appropriately?
  • Are coding standards followed?
  • Are documentation standards followed?
  • Are there misspellings or typos?
  • Are the comments accurate and unambiguous?

Software Engineering CSE470: Cheng and McUmber

sample evaluation guidelines code inspection cont
Sample evaluation Guidelines: Code Inspection (cont.)
  • Are data types and declarations appropriate?
  • Are all constants correct?
  • Are all variables initialized before being used?
  • Are there overly complex conditions?
  • Is there unreachable code?
  • Are there obvious inefficiencies?

Software Engineering CSE470: Cheng and McUmber

sqa summary
SQA Summary
  • U.S. software costs $200 billion/year
  • Need to
    • improve software quality
    • reduce costs
      • V&V is over 50% of the cost
  • Improving V&V should reduce costs significantly while improving quality

Software Engineering CSE470: Cheng and McUmber

intentionally blank13
Intentionally Blank

Software Engineering CSE470: Cheng and McUmber

overview of formal methods

Overview of Formal Methods

Software Engineering CSE470: Cheng and McUmber

topics
Topics
  • Introduction and terminology
  • FM and Software Engineering
  • Applications of FM
  • Propositional and Predicate Logic
  • Program derivation
  • Intuitive program verification
  • Algebraic Specifications
  • Overview of Specification languages

Software Engineering CSE470: Cheng and McUmber

terminology1
Terminology
  • Methods:
    • general guidelines governing an activity
    • rigorous, systematic, and may be formal
  • Techniques:
    • are technical, mechanical, approaches
    • may have restricted applicability
  • Methodologies:combine methods. techniques
  • Tools: can be built to support methodology

Software Engineering CSE470: Cheng and McUmber

components of a formal method
Components of a Formal Method
  • Formal systems.
    • formal languages with well-defined syntax
    • well-defined semantics
    • proof systems
  • Development technique.
    • implementation produced from specification
    • application of development steps
    • refinement process
  • Verification technique.
    • verify implementation satisfies specification
    • verify each development step

Software Engineering CSE470: Cheng and McUmber

formal vs rigorous
Formal vs. Rigorous
  • Formal
    • based on mathematics (including logic)
    • validity of statements can be mechanically checked
  • Rigorous
    • strictly follows the rules
    • compliance can be audited

Software Engineering CSE470: Cheng and McUmber

important characteristics of fm
Important characteristics of FM
  • Abstraction
  • Proof obligations
  • Tool support
  • Systematic process

Software Engineering CSE470: Cheng and McUmber

fm does not replace testing
FM does not replace testing!
  • Reduces burden on testing phases to detect all critical errors
  • Facilitates more effective allocation of testing resources
  • Can guide the selection of test cases

Software Engineering CSE470: Cheng and McUmber

why use formal methods
Why Use Formal Methods
  • Improve quality of software system
  • Fitness for purpose
  • Maintainability
  • Ease of construction
  • Higher confidence in software product
  • Reveal ambiguity, incompleteness, and inconsistency in system
  • Detect design flaws
  • Determine correctness

Software Engineering CSE470: Cheng and McUmber

v v and traceability
V&V and Traceability

The Real World

Validation

Formal Specification

Verification

Code

Software Engineering CSE470: Cheng and McUmber

v v and traceability1
V&V and Traceability

The Real World

Validation

Formal Specification

Verification

Traceability

Code

Software Engineering CSE470: Cheng and McUmber

traditional verification techniques not successful
Traditional verification techniques not successful.

Why not?

  • Too much like math? (proofs, ugh!)
  • Notation too hard to use
  • Notation too hard to write out
  • "Simple" things take a lot of effort
  • "Complex" things seem impossible
  • Program verification is an undecidable problem
  • "If it works, why mess with it?"

Software Engineering CSE470: Cheng and McUmber

potential solutions
Potential solutions?:
  • Need experimental evidence on large projects.
  • Construction of support tools
  • Early education!?!?
  • Integration of formal methods in more than one phase of software engineering
  • Improved (automated) theorem proving strategies
  • Handle more than just functional properties
  • MOST IMPORTANTLY: do not verify "after the fact"

Software Engineering CSE470: Cheng and McUmber

when and where
When and Where?
  • Introduce FM into existing systems
    • Verify critical properties
    • Facilitate maintenance and reimplementation
  • Introduce FM into new systems
    • Capture requirements precisely
    • Reduce ambiguity
    • Guide software development process
    • Basis for testing
    • Formalize requirements analysis and design

Software Engineering CSE470: Cheng and McUmber

rushby s levels of rigor
Rushby’s “Levels of Rigor”
  • Level 0:No use of formal methods.
    • structured walk throughs, ‘formal’ inspections
  • Level 1:Use of concepts and notation from discrete mathematics.
    • cleanroom, SCR (software cost reduction)
  • Level 2:Use of formalized specification languages with some mechanized support tools.
    • specification languages, ‘rigorous’ proofs
  • Level 3:Use of fully formal specification languages with comprehensive support environments, including mechanized theorem proving or proof checking.

Software Engineering CSE470: Cheng and McUmber

formal semantics
Formal Semantics
  • Formal semantics provide precise, machine-independent concepts
  • Provide unambiguous specification techniques and a rigorous theory to support reliable reasoning.
  • A formal definition of a language can suggest a method for constructing programs guaranteed to conform to their specifications.
  • So, the purpose of formal specification is ...

Software Engineering CSE470: Cheng and McUmber

purpose of formal specification
Purpose of Formal Specification
  • The purpose of a formal specification is to state what a system should do without describing how to do it
  • A formal specification may define a system as an abstract datatype.
  • A formal specification should avoid implementation bias.

Software Engineering CSE470: Cheng and McUmber

purpose of formal specification1
Purpose of Formal Specification
  • The purpose of a formal specification is to state what a system should do without describing how to do it
  • A formal specification may define a system as an abstract datatype.
  • A formal specification should avoid implementation bias.

Software Engineering CSE470: Cheng and McUmber

formal specifications
Formal Specifications
  • Formal specifications serve as a
    • contract
    • documentation
    • means of communication between client, specifier, and implementer
  • Formal specifications are amenable to machine analysis and manipulation

Software Engineering CSE470: Cheng and McUmber

too little and too much
Too Little and Too Much
  • There exists a balance between saying enough in a specification and saying too much.
    • say enough so that implementers do not choose unacceptable implementations
    • specifications should capture the requirements completely
    • avoid implementation-bias by not restricting freedom of later designers

Software Engineering CSE470: Cheng and McUmber

operational approach
Operational Approach
  • Define an abstract machine having states, possibly several components, and some set of primitive instructions.
  • Define the machine by specifying how the components of the state are changed by each instruction.
  • Define the semantics of a particular programming language in terms of states.
  • Abstract machines may be unrealistic from a practical point of view, but the simplistic definition prevents misunderstanding code later.

SKIP

Software Engineering CSE470: Cheng and McUmber

operational approach con t
Operational Approach con’t
  • The semantic description of the programming language specifies a translation into this code.
  • Trace through the translated program step-by-step to determine its precise effect.
  • Languages defined in this way include PL/I (by the VDM method)

SKIP

Software Engineering CSE470: Cheng and McUmber

the axiomatic approach
The Axiomatic Approach
  • Associate an "axiom" with each kind of statement in the programming language
    • state what may be asserted after execution of that statement in terms of what was true before
    • an example is the use of pre- and postconditions.

SKIP

Software Engineering CSE470: Cheng and McUmber

another view
Another View
  • Model-Oriented: define system behavior by constructing model of system in terms of mathematical structures
    • tuples, functions. sets, or sequences
    • languages include VDM, Z, CSP, and Petri Nets
  • Property-Oriented: define system behavior indirectly by stating a set of properties that the system must satisfy

SKIP

Software Engineering CSE470: Cheng and McUmber

two types of property oriented approaches
Two Types of Property-Oriented Approaches
  • Axiomatic: use first-order predicate logic (pre- and postconditions)
  • Algebraic: use axioms in equational form to describe properties

SKIP

Software Engineering CSE470: Cheng and McUmber

obvious applications
Obvious Applications
  • Computer Security
  • Fault-tolerant systems (e.g. Nuclear reactors)
  • Safety-critical system (e.g. diagnostic X-ray machine)
  • Gain insight into hardware/software systems (e.g. oscilloscope)
  • Basically, wherever the cost of failure is high:
  • including systems that are critical in some way
  • replicated many times
  • fixed into hardware, or
  • dependent on quality for commercial reasons

Software Engineering CSE470: Cheng and McUmber

relevant areas of research
Relevant Areas of Research
  • Programming environments
  • Formal methods in software development
  • Tools that support construction of formal specifications
  • Design tools that will generate formal specifications
  • Problem/specification decomposition
  • Procedural and data abstraction
  • Synthesis of efficient code
  • "Smart" user interfaces (user-friendly ones!!)
  • Methods for determining reuse (of design/specifications/code)

Software Engineering CSE470: Cheng and McUmber

intentionally blank14
Intentionally Blank

Software Engineering CSE470: Cheng and McUmber

model checking

Model Checking

Software Engineering CSE470: Cheng and McUmber

model checking1
Model Checking
  • Used in studying behaviors of reactive systems
  • Typically involves three steps:
    • Create a finite state model (FSM) of the system design
    • Specify critical correctness properties
    • Validate the model w/r to the specifications

Software Engineering CSE470: Cheng and McUmber

create a fsm
Create a FSM
  • FSM languages
    • focus on expressing concurrency, synchronization, and communication
    • abstract details of internal computations
    • must be precise and unambiguous (formally defined syntax and semantics)
  • We will use Promela for giving system descriptions

Software Engineering CSE470: Cheng and McUmber

specify correctness properties
Specify correctness properties
  • Safety properties:
    • Nothing “bad” ever happens
    • Formalized using state invariants
      • execution never reaches a “bad” state
  • Liveness properties:
    • Something “good” eventually happens
    • Formalized using temporal logic
      • special logic for describing sequences

Software Engineering CSE470: Cheng and McUmber

validate the model
Validate the model
  • “Execute” the model to test it
    • simulate executions of the system
    • check satisfaction of safety properties along simulated executions
  • Exhaustive analysis
    • generate reachability graph to verify safety and liveness properties
  • Generate counterexamples to illustrate failures

Software Engineering CSE470: Cheng and McUmber

home heating system
Home Heating System

Software Engineering CSE470: Cheng and McUmber

example properties
Example properties
  • Pump is never on unless Burner is also on
  • Whenever Sensor calls resp-temp(LOW), eventually Controller becomes all-on

Software Engineering CSE470: Cheng and McUmber

reachability graph
Reachability Graph
  • Graph of global states that can be “reached” during execution
    • global state contains a state for each concurrent “process”
    • transitions show how an event or action transforms the global state
  • Analyze global state space to verify safety properties
  • Analyze paths through the RG to verify liveness properties

Software Engineering CSE470: Cheng and McUmber

promela
Promela
  • The system description language of SPIN
    • Designed for modeling data communication protocols
    • System described as a collection of concurrent processes
    • Processes communicate and synchronize via message channels and global variables

Software Engineering CSE470: Cheng and McUmber

promela1
Promela
  • Specify macro definitions

#define signal 0

  • Declare symbolic constants

mtype = { ON, OFF, LOW, OK }

  • Declare a synchronous message channel

chan pump_in = [0] of { mtype }

Software Engineering CSE470: Cheng and McUmber

promela2
Promela
  • Create a process instance

active proctype pump ( ) { statements }

  • Send a message

pump_in!ON

  • Receive a message

pump_in?ON

Software Engineering CSE470: Cheng and McUmber

promela version of hhs
Promela version of HHS

Software Engineering CSE470: Cheng and McUmber

promela version of hhs1
Promela version of HHS

Software Engineering CSE470: Cheng and McUmber

promela version of hhs2
Promela version of HHS

Software Engineering CSE470: Cheng and McUmber

spin simulation of hhs
SPIN simulation of HHS
  • SPIN automatically generates sequence diagrams to represent executions
    • random
    • guided
    • interactive
  • Automates tracing between system views
    • sequence diagram
    • Promela description
    • state diagram
    • textual execution traces

Software Engineering CSE470: Cheng and McUmber

verification of a safety property
Verification of a safety property
  • Pump is never on unless Burner is also on

Software Engineering CSE470: Cheng and McUmber

verification of a liveness property
Verification of a liveness property
  • Whenever Sensor calls resp-temp(LOW), eventually Controller becomes all-on

Software Engineering CSE470: Cheng and McUmber

verification of a liveness property1
Verification of a liveness property

Software Engineering CSE470: Cheng and McUmber

system design

System Design

Software Engineering CSE470: Cheng and McUmber

design how to implement a system
Design: HOW to implement a system
  • Goals:
    • Satisfy the requirements
    • Satisfy the customer
    • Reduce development costs
    • Provide reliability
    • Support maintainability
    • Plan for future modifications

Software Engineering CSE470: Cheng and McUmber

design issues1
Architecture

User Interface

Data Types

Operations

Data Representations

Algorithms

Design Issues

Software Engineering CSE470: Cheng and McUmber

design
Design
  • System design (high level design)
    • Focus on architecture
    • Identification of subsystems
  • Object design (lower level design)
    • Modules and their implementations
    • Focus on data representations and algorithms

Software Engineering CSE470: Cheng and McUmber

system design1
System Design
  • Choose high-level strategy for solving problem and building solution
  • Decide how to organize the system into subsystems
  • Identify concurrency / tasks
  • Allocate subsystems to HW and SW components

Software Engineering CSE470: Cheng and McUmber

system design2
System Design
  • Major conceptual and policy decisions
    • Approach for management of data stores
    • Access mechanism for global resources
    • Software control mechanism
  • Handle boundary conditions
  • Prioritize trade-offs

Software Engineering CSE470: Cheng and McUmber

design principles
Design Principles
  • Consider alternative approaches
    • Do pro and con analysis
    • Delay decisions until superior choice is clear
    • Isolate decisions so alternative implementations can be evaluated later
  • Avoid unnecessary embellishments
  • But don’t oversimplify

Software Engineering CSE470: Cheng and McUmber

design principles cont
Design Principles (cont.)
  • Make design traceable to requirements
  • Use uniform documentation style
  • Reuse existing designs when possible
  • Keep design simple unless performance, maintainability, etc. DEMAND otherwise

Software Engineering CSE470: Cheng and McUmber

design principles cont1
Design Principles (cont.)
  • Define interfaces between modules carefully
  • Consider how to handle the unexpected
  • Don’t code!!
  • Document decisions
  • Review, review, review . . .

Software Engineering CSE470: Cheng and McUmber

system architecture
System Architecture
  • Overall organization of system into subsystems
  • Decide basic interaction patterns
  • Numerous architectural styles for different applications
  • Architecture provides context for detailed design decisions

Software Engineering CSE470: Cheng and McUmber

subsystem identification
Subsystem Identification
  • Divide system into a manageable number of components
  • Each major component is a subsystem
  • Subsystem groups components with common properties/function

Software Engineering CSE470: Cheng and McUmber

subsystem
Collection of

Classes

Associations

Operations

Events

Constraints

Interrelated

Good cohesion

Well-defined, small interface with other subsystems

Low coupling

Identified by the service it provides

Subsystem

Software Engineering CSE470: Cheng and McUmber

subsystem discussion
Subsystem Discussion
  • Provide services for other sub-systems
    • Group of related functions
    • Share a common purpose
  • Divide system into components (>20)
  • Subsystems are decomposed . . .
    • Module is the lowest level of subsystem

Software Engineering CSE470: Cheng and McUmber

subsystem relationships
Subsystem Relationships
  • Client-Server relationship
    • Client subsystems actively drive the system by requesting services provided by a server subsystem
  • Peer-to-peer relationship
    • Subsystems interact and communicate to accomplish a common goal

Software Engineering CSE470: Cheng and McUmber

client server relationship
Client-Server Relationship
  • Server supplies services for clients
    • Need not know identity of clients
    • Need not know interface of clients
  • Client calls server
    • Client knows interface of server
    • Server performs some service and returns a result

Software Engineering CSE470: Cheng and McUmber

peer to peer relationship
Peer-to-Peer Relationship
  • Subsystems call one another
  • The results of/responses to calls may not be immediately visible
  • Subsystems must know the interfaces of other subsystems
  • More likely to have communication dependencies

Software Engineering CSE470: Cheng and McUmber

strategies for decompositions
Strategies for Decompositions
  • Layers: Horizontal decomposition
    • Open
    • Closed
  • Partitions: Vertical decomposition
  • System topology:
    • General decompositions

Software Engineering CSE470: Cheng and McUmber

layered subsystems
Layered Subsystems
  • Set of “virtual” worlds
  • Each layer is defined in terms of the layer(s) below it
    • Knowledge is one way: Layer knows about layer(s) below it
  • Objects within layer can be independent
  • Lower layer (server) supplies services for objects (clients) in upper layer(s)

Software Engineering CSE470: Cheng and McUmber

example layered architecture
Example: Layered architecture

Interactive Graphics Application

Windows Operations

Screen Operations

Pixel Operations

Device I/O Operations

Software Engineering CSE470: Cheng and McUmber

closed architectures
Closed Architectures
  • Each layer is built only in terms of the immediate lower layer
  • Reduces dependencies between layers
  • Facilitates change

Software Engineering CSE470: Cheng and McUmber

open architectures
Open Architectures
  • Layer can use any lower layer
  • Reduces the need to redefine operations at each level
  • More efficient /compact code
  • System is less robust/harder to change

Software Engineering CSE470: Cheng and McUmber

properties of layered architectures
Properties of Layered Architectures
  • Top and bottom layers specified by the problem statement
    • Top layer is the desired system
    • Bottom layer is defined by available resources (e.g. HW, OS, libraries)
  • Easier to port to other HW/SW platforms

Software Engineering CSE470: Cheng and McUmber

partitioned architectures
Partitioned Architectures
  • Divide system into weakly-coupled subsystems
  • Each provides specific services
  • Vertical decomposition of problem

Software Engineering CSE470: Cheng and McUmber

ex partitioned architecture
Ex: Partitioned Architecture

Operating System

Virtual

Memory

Manage-

ment

File

System

Process

Control

Device

Control

Software Engineering CSE470: Cheng and McUmber

typical application architecture
Typical Application Architecture

Application package

Window graphics

Screen graphics

Pixel graphics

Operating system

Computer hardware

User dialogue control

Simulation package

Software Engineering CSE470: Cheng and McUmber

system topology
System Topology
  • Describe information flow
    • Can use DFD to model flow
  • Some common topologies
    • Pipeline (batch)
    • Star topology

Software Engineering CSE470: Cheng and McUmber

ex pipeline topology
Ex: Pipeline Topology

Compiler:

source program

Lexical analyzer

Semantic analyzer

token stream

abstract syntax tree

code sequence

object code

Code generator

Code optimizer

Software Engineering CSE470: Cheng and McUmber

ex star toplogy
Ex: Star Toplogy

Monitoring system:

Alarm

Sensors

sensor status

On/Off signals, alarm type

SafeHome software

commands, data

Telephone line

number tones

Control panel

display information

Software Engineering CSE470: Cheng and McUmber

modularity
Modularity
  • Organize modules according to resources/objects/data types
  • Provide cleanly defined interfaces
    • operations, methods, procedures, ...
  • Hide implementation details
  • Simplify program understanding
  • Simplify program maintainance

Software Engineering CSE470: Cheng and McUmber

abstraction
Abstraction
  • Control abstraction
    • structured control statements
    • exception handling
    • concurrency constructs
  • Procedural abstraction
    • procedures and functions
  • Data abstraction
    • user defined types

Software Engineering CSE470: Cheng and McUmber

abstraction cont
Abstraction (cont.)
  • Abstract data types
    • encapsulation of data
  • Abstract objects
    • subtyping
    • generalization/inheritance

Software Engineering CSE470: Cheng and McUmber

cohesion
Cohesion
  • Contents of a module should be cohesive
  • Improves maintainability
    • Easier to understand
    • Reduces complexity of design
    • Supports reuse

Software Engineering CSE470: Cheng and McUmber

weak types of cohesiveness
(Weak) Types of cohesiveness
  • Coincidentally cohesive
    • contiguous lines of code not exceeding a maximum size
  • Logically cohesive
    • all output routines
  • Temporally cohesive
    • all initialization routines

Software Engineering CSE470: Cheng and McUmber

better types of cohesiveness
(Better) Types of cohesiveness
  • Procedurally cohesive
    • routines called in sequence
  • Communicationally cohesive
    • work on same chunk of data
  • Functionally cohesive
    • work on same data abstraction at a consistent level of abstraction

Software Engineering CSE470: Cheng and McUmber

example poor cohesion
Example: Poor Cohesion

package Output is

procedure DisplayDice( . . .);

procedure DisplayBoard( . . .);

Dice

I/O device

Output

Board

Software Engineering CSE470: Cheng and McUmber

example good cohesion
Example: Good Cohesion

package Dice is

procedure Display ( . . .);

procedure Roll( . . .);

Dice

I/O device

Board

Software Engineering CSE470: Cheng and McUmber

coupling
Coupling
  • Connections between modules
  • Bad coupling
    • Global variables
    • Flag parameters
    • Direct manipulation of data structures by multiple classes

Software Engineering CSE470: Cheng and McUmber

coupling cont
Coupling (cont.)
  • Good coupling
    • Procedure calls
    • Short argument lists
    • Objects as parameters
  • Good coupling improves maintain-ability
    • Easier to localize errors, modify implementations of an objects, ...

Software Engineering CSE470: Cheng and McUmber

information hiding1
Information Hiding
  • Hide decisions likely to change
    • Data representations, algorithmic details, system dependencies
  • Black box
    • Input is known
    • Output is predictable
    • Mechanism is unknown
  • Improves maintainability

Software Engineering CSE470: Cheng and McUmber

information hiding2
Information Hiding

Software Engineering CSE470: Cheng and McUmber

abstract data types
Abstract data types
  • Modules (Classes, packages)
    • Encapsulate data structures and their operations
    • Good cohesion
      • implement a single abstraction
    • Good coupling
      • pass abstract objects as parameters
    • Black boxes
      • hide data representations and algorithms

Software Engineering CSE470: Cheng and McUmber

identifying concurrency
Identifying Concurrency
  • Inherent concurrency
    • May involve synchronization
    • Multiple objects receive events at the same time with out interacting
    • Example:
      • User may issue commands through control panel at same time that the sensor is sending status information to the SafeHome system

Software Engineering CSE470: Cheng and McUmber

determining concurrent tasks
Determining Concurrent Tasks
  • Thread of control
    • Path through state diagram with only one active object at any time
  • Threads of control are implemented as tasks
    • Interdependent objects
    • Examine state diagram to identify objects that can be implemented in a task

Software Engineering CSE470: Cheng and McUmber

management of data stores
Management of Data Stores
  • Data stores permit separations between subsystems
    • Internal or external
  • Common types of data stores
    • Files
    • Databases

Software Engineering CSE470: Cheng and McUmber

file data stores
File Data Stores
  • When to use a database
    • Require access to voluminous data at fine levels of detail by multiple users
    • Access can be efficiently managed with DBMS commands
    • Application must port across many HW and OS platforms
    • Store is to be accessed by multiple application programs

Software Engineering CSE470: Cheng and McUmber

database data stores
Database Data Stores
  • Advantages
    • Infrastructure support
    • Common interface
    • Standard access language (SQL)
  • Disadvantages
    • Performance penalty
    • Awkward programming language

Software Engineering CSE470: Cheng and McUmber

file data stores1
File Data Stores
  • When to use file data stores
    • Data does not fit structure of DBMS
    • Voluminous data that is low in information density
    • “Raw” data
    • Volatile data
      • only retained for a short time

Software Engineering CSE470: Cheng and McUmber

global resources
Global Resources
  • Identify global resources and determine access patterns
  • Examples
    • physical units (processors, tape drives)
    • available space (disk, screen, buttons)
    • logical names (object IDs, filenames)
    • access to shared data (database, file)

Software Engineering CSE470: Cheng and McUmber

software control mechanism
Software Control Mechanism
  • How SW will control interactions between objects
    • Internal control
      • flow of control within a process
    • External control
      • flow of externally-visible events among objects
  • Uniform control style for objects

Software Engineering CSE470: Cheng and McUmber

internal control
Internal Control
  • Under control of programmer
  • Structured for convenience
    • efficiency, clarity, reliability, . . .
  • Common types of control flow
    • Procedure calls
    • Quasi-concurrent inter-task calls
    • Concurrent inter-task calls

Software Engineering CSE470: Cheng and McUmber

external control
External Control
  • Procedure-driven systems
  • Event-driven systems
  • Concurrent systems

Software Engineering CSE470: Cheng and McUmber

procedure driven systems
Procedure-driven systems
  • Control resides within the program code
    • procedure issues request, waits for reply, then continues execution
  • System state defined by
    • program counter, stack of procedure calls, local variables

Software Engineering CSE470: Cheng and McUmber

event driven systems
Event-Driven Systems
  • Control resides within a central dispatcher
    • calls to the dispatcher send output or enable input
    • dispatcher invokes procedures when events occur (“call back”)
    • state maintained
      • using global variables, or
      • by dispatcher for procedures

Software Engineering CSE470: Cheng and McUmber

concurrent systems
Concurrent Systems
  • Control resides concurrently in independent tasks
  • Events are implemented as messages between tasks
  • OS schedules tasks for execution

Software Engineering CSE470: Cheng and McUmber

boundary conditions
Boundary Conditions
  • Initialization
    • Constants, parameters, global variables, tasks, guardians, class hierarchy
  • Termination
    • Release external resources, notify other tasks
  • Failure
    • Clean up and log failure info

Software Engineering CSE470: Cheng and McUmber

identify trade off priorities
Identify Trade-off Priorities
  • Establish priorities for choosing between incompatible goals
  • Implement minimal functionality initially and embellish as appropriate
  • Isolate decision points for later evaluation
  • Trade efficiency for simplicity, reliability, . . .

Software Engineering CSE470: Cheng and McUmber

intentionally blank15
Intentionally Blank

Software Engineering CSE470: Cheng and McUmber

chapter 7 object design

Chapter 7,Object Design

Software Engineering CSE470: Cheng and McUmber

object design
Object Design
  • Object design is the process of adding details to the requirements analysis and making implementation decisions
  • The object designer must choose among different ways to implement the analysis model with the goal to minimize execution time, memory and other measures of cost.
  • Requirements Analysis: Use cases, functional and dynamic model deliver operations for object model
  • Object Design: We iterate on where to put these operations in the object model
  • Object Design serves as the basis of implementation

Software Engineering CSE470: Cheng and McUmber

object design closing the gap
Object Design: Closing the Gap

Software Engineering CSE470: Cheng and McUmber

object design issues
Object Design Issues
  • Full definition of associations
  • Full definition of classes
  • Choice of algorithms and data structures
  • Detection of new application-domain independent classes (example: Cache)
  • Optimization
  • Increase of inheritance
  • Decision on control
  • Packaging

Software Engineering CSE470: Cheng and McUmber

terminology of activities
Terminology of Activities
  • Object-Oriented Methodologies
    • System Design
      • Decomposition into subsystems
    • Object Design
      • Implementation language chosen
      • Data structures and algorithms chosen
  • SA/SD uses different terminology:
    • Preliminary Design
      • Decomposition into subsystems
      • Data structures are chosen
    • Detailed Design
      • Algorithms are chosen
      • Data structures are refined
      • Implementation language is chosen
      • Typically in parallel with preliminary design, not separate stage
object design activities
Object Design Activities

1. Service specification

  • Describes precisely each class interface

2. Component selection

  • Identify off-the-shelf components and additional solution objects

3. Object model restructuring

  • Transforms the object design model to improve its understandability and extensibility

4. Object model optimization

  • Transforms the object design model to address performance criteria such as response time or memory utilization.

Software Engineering CSE470: Cheng and McUmber

service specification
Service Specification
  • Requirements analysis
    • Identifies attributes and operations without specifying their types or their parameters.
  • Object design
    • Add visibility information
    • Add type signature information
    • Add contracts

Software Engineering CSE470: Cheng and McUmber

add visibility
Add Visibility

UML defines three levels of visibility:

  • Private:
    • A private attribute can be accessed only by the class in which it is defined.
    • A private operation can be invoked only by the class in which it is defined.
    • Private attributes and operations cannot be accessed by subclasses or other classes.
  • Protected:
    • A protected attribute or operation can be accessed by the class in which it is defined and on any descendent of the class.
  • Public:
    • A public attribute or operation can be accessed by any class.

Software Engineering CSE470: Cheng and McUmber

information hiding heuristics
Information Hiding Heuristics
  • Build firewalls around classes
    • Carefully define public interfaces for classes as well as subsystems
  • Apply “Need to know” principle. The fewer an operation knows
    • the less likely it will be affected by any changes
    • the easier the class can be changed
  • Trade-off
    • Information hiding vs efficiency

Software Engineering CSE470: Cheng and McUmber

information hiding design principles
Information Hiding Design Principles
  • Only the operations of a class are allowed to manipulate its attributes
    • Access attributes only via operations.
  • Hide external objects at subsystem boundary
    • Define abstract class interfaces which mediate between system and external world as well as between subsystems
  • Do not apply an operation to the result of another operation.
    • Write a new operation that combines the two operations.

Software Engineering CSE470: Cheng and McUmber

add type signature information

Hashtable

-numElements:int

+put()

+get()

+remove()

+containsKey()

+size()

Add Type Signature Information

Software Engineering CSE470: Cheng and McUmber

contracts
Contracts
  • Contracts on a class enable caller and callee to share the same assumptions about the class.
  • Contracts include three types of constraints:
    • Invariant: A predicate that is always true for all instances of a class. Invariants are constraints associated with classes or interfaces. Invariants are used to specify consistency constraints among class attributes.
    • Precondition: A predicate that must be true before an operation is invoked. Preconditions are associated with a specific operation. Preconditions are used to specify constraints that a caller must meet before calling an operation.
    • Postcondition: A predicate that must be true after an operation is invoked. Postconditions are associated with a specific operation. Postconditions are used to specify constraints that the object must ensure after the invocation of the operation.

Software Engineering CSE470: Cheng and McUmber

expressing constraints in uml
Expressing constraints in UML
  • OCL (Object Constraint Language)
    • OCL allows constraints to be formally specified on single model elements or groups of model elements
    • A constraint is expressed as an OCL expression returning the value true or false. OCL is not a procedural language (cannot constrain control flow).
  • OCL expressions for Hashtable operation put():
    • Invariant:
      • context Hashtable inv: numElements >= 0
    • Precondition:
      • context Hashtable::put(key, entry) pre:!containsKey(key)
    • Post-condition:
      • context Hashtable::put(key, entry) post: containsKey(key) and get(key) = entry

Context is a class

operation

OCL expression

Software Engineering CSE470: Cheng and McUmber

expressing constraints in uml1
Expressing Constraints in UML
  • A constraint can also be depicted as a note attached to the constrained UML element by a dependency relationship.

Software Engineering CSE470: Cheng and McUmber

object design areas
Object Design Areas

1. Service specification

  • Describes precisely each class interface

2. Component selection

  • Identify off-the-shelf components and additional solution objects

3. Object model restructuring

  • Transforms the object design model to improve its understandability and extensibility

4. Object model optimization

  • Transforms the object design model to address performance criteria such as response time or memory utilization.

Software Engineering CSE470: Cheng and McUmber

component selection
Component Selection
  • Select existing off-the-shelf class libraries, frameworks or components
  • Adjust the class libraries, framework or components
    • Change the API if you have the source code.
    • Use the adapter or bridge pattern if you don’t have access

Software Engineering CSE470: Cheng and McUmber

reuse
Reuse...
  • Look for existing classes in class libraries
    • JSAPI, JTAPI, ....
  • Select data structures appropriate to the algorithms
    • Container classes
    • Arrays, lists, queues, stacks, sets, trees, ...
  • Define new internal classes and operations only if necessary
    • Complex operations defined in terms of lower-level operations might need new classes and operations

Software Engineering CSE470: Cheng and McUmber

object design areas1
Object Design Areas

1. Service specification

  • Describes precisely each class interface

2. Component selection

  • Identify off-the-shelf components and additional solution objects

3. Object model restructuring

  • Transforms the object design model to improve its understandability and extensibility

4. Object model optimization

  • Transforms the object design model to address performance criteria such as response time or memory utilization.

Software Engineering CSE470: Cheng and McUmber

restructuring activities
Restructuring Activities
  • Realizing associations
  • Revisiting inheritance to increase reuse
  • Revising inheritance to remove implementation dependencies

Software Engineering CSE470: Cheng and McUmber

increase inheritance
Increase Inheritance
  • Rearrange and adjust classes and operations to prepare for inheritance
  • Abstract common behavior out of groups of classes
    • If a set of operations or attributes are repeated in 2 classes the classes might be special instances of a more general class.
  • Be prepared to change a subsystem (collection of classes) into a superclass in an inheritance hierarchy.

Software Engineering CSE470: Cheng and McUmber

building a super class from several classes
Building a super class from several classes
  • Prepare for inheritance. All operations must have the same signature but often the signatures do not match:
    • Some operations have fewer arguments than others: Use overloading (Possible in Java)
    • Similar attributes in the classes have different names: Rename attribute and change all the operations.
    • Operations defined in one class but no in the other: Use virtual functions and class function overriding.
  • Abstract out the common behavior (set of operations with same signature) and create a superclass out of it.
  • Superclasses are desirable. They
    • increase modularity, extensibility and reusability
    • improve configuration management

Software Engineering CSE470: Cheng and McUmber

implement associations
Implement Associations
  • Strategy for implementing associations:
    • Be as uniform as possible
    • Individual decision for each association
  • Example of uniform implementation
    • 1-to-1 association:
      • Role names are treated like attributes in the classes and translate to references
    • 1-to-many association:
      • Translate to Vector
    • Qualified association:
      • Translate to Hash table

Software Engineering CSE470: Cheng and McUmber

unidirectional 1 to 1 association
Unidirectional 1-to-1 Association

Software Engineering CSE470: Cheng and McUmber

bidirectional 1 to 1 association
Bidirectional 1-to-1 Association

Software Engineering CSE470: Cheng and McUmber

1 to many association
1-to-Many Association

Object design model before

transformation

Layer

LayerElement

1

*

Object design model after transformation

Layer

LayerElement

-layerElements:Set

-containedIn:Layer

+elements()

+getLayer()

+addElement(le)

+setLayer(l)

+removeElement(le)

Software Engineering CSE470: Cheng and McUmber

qualification

Object design model before transformation

*

0..1

SimulationRun

Scenario

simname

Object design model after transformation

Scenario

SimulationRun

-runs:Hashtable

-scenarios:Vector

+elements()

+elements()

+addRun(simname,sr:SimulationRun)

+addScenario(s:Scenario)

+removeRun(simname,sr:SimulationRun)

+removeScenario(s:Scenario)

Qualification

Software Engineering CSE470: Cheng and McUmber

object design areas2
Object Design Areas

1. Service specification

  • Describes precisely each class interface

2. Component selection

  • Identify off-the-shelf components and additional solution objects

3. Object model restructuring

  • Transforms the object design model to improve its understandability and extensibility

4. Object model optimization

  • Transforms the object design model to address performance criteria such as response time or memory utilization.

Software Engineering CSE470: Cheng and McUmber

design optimizations
Design Optimizations
  • Design optimizations are an important part of the object design phase:
    • The requirements analysis model is semantically correct but often too inefficient if directly implemented.
  • Optimization activities during object design:

1. Add redundant associations to minimize access cost

2. Rearrange computations for greater efficiency

3. Store derived attributes to save computation time

  • As an object designer you must strike a balance between efficiency and clarity.
    • Optimizations will make your models more obscure

Software Engineering CSE470: Cheng and McUmber

design optimization activities
Design Optimization Activities

1. Add redundant associations:

  • What are the most frequent operations? ( Sensor data lookup?)
  • How often is the operation called? (30 times a month, every 50 milliseconds)

2. Rearrange execution order

  • Eliminate dead paths as early as possible (Use knowledge of distributions, frequency of path traversals)
  • Narrow search as soon as possible
  • Check if execution order of loop should be reversed

3. Turn classes into attributes

Software Engineering CSE470: Cheng and McUmber

implement application domain classes
Implement Application domain classes
  • To collapse or not collapse: Attribute or association?
  • Object design choices:
    • Implement entity as embedded attribute
    • Implement entity as separate class with associations to other classes
  • Associations are more flexible than attributes but often introduce unnecessary indirection.

Software Engineering CSE470: Cheng and McUmber

optimization activities collapsing objects

SocialSecurity

Person

ID:String

Person

SSN:String

Optimization Activities: Collapsing Objects

Software Engineering CSE470: Cheng and McUmber

to collapse or not to collapse
To Collapse or not to Collapse?
  • Collapse a class into an attribute if the only operations defined on the attributes are Set() and Get().

Software Engineering CSE470: Cheng and McUmber

design optimizations continued
Design Optimizations (continued)

Store derived attributes

    • Example: Define new classes to store information locally (database cache)
  • Problem with derived attributes:
    • Derived attributes must be updated when base values change.
    • There are 3 ways to deal with the update problem:
      • Explicit code: Implementor determines affected derived attributes (push)
      • Periodic computation: Recompute derived attribute occasionally (pull)
      • Active value: An attribute can designate set of dependent values which are automatically updated when active value is changed (notification, data trigger)

Software Engineering CSE470: Cheng and McUmber

optimization activities delaying complex computations

Image

filename:String

data:byte[]

width()

height()

paint()

Image

filename:String

width()

height()

paint()

image

RealImage

ImageProxy

1

0..1

filename:String

data:byte[]

width()

width()

height()

height()

paint()

paint()

Optimization Activities: Delaying Complex Computations

Software Engineering CSE470: Cheng and McUmber

documenting the object design the object design document odd
Documenting the Object Design: The Object Design Document (ODD)
  • Object design document
    • Same as RAD +...
    • … + additions to object, functional and dynamic models (from solution domain)
    • … + Navigational map for object model
    • … + Javadoc documentation for all classes
  • ODD Management issues
    • Update the RAD models in the RAD?
    • Should the ODD be a separate document?
    • Who is the target audience for these documents (Customer, developer?)
    • If time is short: Focus on the Navigational Map and Javadoc documentation?
  • Example of acceptable ODD:
    • http://macbruegge1.informatik.tu-muenchen.de/james97/index.html

Software Engineering CSE470: Cheng and McUmber

documenting object design odd conventions
Documenting Object Design: ODD Conventions
  • Each subsystem in a system provides a service(see Chapter on System Design)
    • Describes the set of operations provided by the subsystem
  • Specifying a service operation as
    • Signature: Name of operation, fully typed parameter list and return type
    • Abstract: Describes the operation
    • Pre: Precondition for calling the operation
    • Post: Postcondition describing important state after the execution of the operation

Use JavaDoc for the specification of service operations.

Software Engineering CSE470: Cheng and McUmber

javadoc
JavaDoc
  • Add documentation comments to the source code.
  • A doc comment consists of characters between /** and */
  • When JavaDoc parses a doc comment, leading * characters on each line are discarded. First, blanks and tabs preceding the initial * characters are also discarded.
  • Doc comments may include HTML tags
  • Example of a doc comment:

/**

* This is a <b> doc </b> comment

*/

Software Engineering CSE470: Cheng and McUmber

more on java doc
More on Java Doc
  • Doc comments are only recognized when placed immediately before class, interface, constructor, method or field declarations.
  • When you embed HTML tags within a doc comment, you should not use heading tags such as <h1> and <h2>, because JavaDoc creates an entire structured document and these structural tags interfere with the formatting of the generated document.
  • Class and Interface Doc Tags
  • Constructor and Method Doc Tags

Software Engineering CSE470: Cheng and McUmber

class and interface doc tags
Class and Interface Doc Tags

@author name-text

  • Creates an “Author” entry.

@version version-text

  • Creates a “Version” entry.

@see classname

  • Creates a hyperlink “See Also classname”

@since since-text

  • Adds a “Since” entry. Usually used to specify that a feature or change exists since the release number of the software specified in the “since-text”

@deprecated deprecated-text

  • Adds a comment that this method can no longer be used. Convention is to describe method that serves as replacement
  • Example: @deprecated Replaced by setBounds(int, int, int, int).

Software Engineering CSE470: Cheng and McUmber

constructor and method doc tags
Constructor and Method Doc Tags
  • Can contain @see tag, @since tag, @deprecated as well as:

@param parameter-name description

Adds a parameter to the "Parameters" section. The description may be continued on the next line.

@return description

Adds a "Returns" section, which contains the description of the return value.

@exception fully-qualified-class-name description

Adds a "Throws" section, which contains the name of the exception that may be thrown by the method. The exception is linked to its class documentation.

@see classname

Adds a hyperlink "See Also" entry to the method.

Software Engineering CSE470: Cheng and McUmber

example of a class doc comment
Example of a Class Doc Comment

/**

* A class representing a window on the screen.

* For example:

* <pre>

* Window win = new Window(parent);

* win.show();

* </pre>

*

* @author Sami Shaio

* @version %I%, %G%

* @see java.awt.BaseWindow

* @see java.awt.Button

*/

class Window extends BaseWindow {

...

}

Software Engineering CSE470: Cheng and McUmber

example of a method doc comment
Example of a Method Doc Comment

/**

* Returns the character at the specified index. An index

* ranges from <code>0</code> to <code>length() - 1</code>.

*

* @param index the index of the desired character.

* @return the desired character.

* @exception StringIndexOutOfRangeException

* if the index is not in the range <code>0</code>

* to <code>length()-1</code>.

* @see java.lang.Character#charValue()

*/

public char charAt(int index) {

...

}

Software Engineering CSE470: Cheng and McUmber

example of a field doc comment
Example of a Field Doc Comment
  • A field comment can contain only the @see, @since and @deprecated tags

/**

* The X-coordinate of the window.

*

* @see window#1

*/

int x = 1263732;

Software Engineering CSE470: Cheng and McUmber

example specifying a service in java
Example: Specifying a Service in Java

/** Office is a physical structure in a building. It is possible to create an instance of a office; add an occupant; get the name and the number of occupants */

public class Office {

/** Adds an occupant to the office */

* @param NAME name is a nonempty string */

public void AddOccupant(string name);

/** @Return Returns the name of the office. Requires, that Office has been initialized with a name */

public string GetName();

....

}

Software Engineering CSE470: Cheng and McUmber

implementation of application domain classes
Implementation of Application Domain Classes
  • New objects are often needed during object design:
    • Use of Design patterns lead to new classes
    • The implementation of algorithms may necessitate objects to hold values
    • New low-level operations may be needed during the decomposition of high-level operations
  • Example: The EraseArea() operation offered by a drawing program.
    • Conceptually very simple
    • Implementation
      • Area represented by pixels
      • Repair () cleans up objects partially covered by the erased area
      • Redraw() draws objects uncovered by the erasure
      • Draw() erases pixels in background color not covered by other objects

Software Engineering CSE470: Cheng and McUmber

application domain vs solution domain objects
Application Domain vs Solution Domain Objects

Requirements Analysis

(Language of Application

Domain)

Object Design

(Language of Solution Domain)

Incident

Report

Incident

Report

Text box

Menu

Scrollbar

Software Engineering CSE470: Cheng and McUmber

package it all up
Package it all up
  • Pack up design into discrete physical units that can be edited, compiled, linked, reused
  • Construct physical modules
    • Ideally use one package for each subsystem
    • System decomposition might not be good for implementation.
  • Two design principles for packaging
    • Minimize coupling:
      • Classes in client-supplier relationships are usually loosely coupled
      • Large number of parameters in some methods mean strong coupling (> 4-5)
      • Avoid global data
    • Maximize cohesiveness:
      • Classes closely connected by associations => same package

Software Engineering CSE470: Cheng and McUmber

packaging heuristics
Packaging Heuristics
  • Each subsystem service is made available by one or more interface objects within the package
  • Start with one interface object for each subsystem service
    • Try to limit the number of interface operations (7+-2)
  • If the subsystem service has too many operations, reconsider the number of interface objects
  • If you have too many interface objects, reconsider the number of subsystems
  • Difference between interface objects and Java interfaces
    • Interface object :Used during requirements analysis, system design and object design. Denotes a service or API
    • Java interface: Used during implementation in Java (A Java interface may or may not implement an interface object)

Software Engineering CSE470: Cheng and McUmber

summary2
Summary
  • Object design closes the gap between the requirements and the machine.
  • Object design is the process of adding details to the requirements analysis and making implementation decisions
  • Object design includes:

1. Service specification

2. Component selection

3. Object model restructuring

4. Object model optimization

  • Object design is documented in the Object Design Document, which can be generated using tools such as JavaDoc.

Software Engineering CSE470: Cheng and McUmber

intentionally blank16
Intentionally Blank

Software Engineering CSE470: Cheng and McUmber

intentionally blank17
Intentionally Blank

Software Engineering CSE470: Cheng and McUmber

testing1

Testing

Software Engineering CSE470: Cheng and McUmber

outline1
Terminology

Types of errors

Dealing with errors

Quality assurance vs Testing

Component Testing

Unit testing

Integration testing

Testing Strategy

Design Patterns & Testing

System testing

Function testing

Structure Testing

Performance testing

Acceptance testing

Installation testing

Outline

Software Engineering CSE470: Cheng and McUmber

terminology2
Terminology
  • Reliability: The measure of success with which the observed behavior of a system confirms to some specification of its behavior.
  • Failure: Any deviation of the observed behavior from the specified behavior.
  • Error: The system is in a state such that further processing by the system will lead to a failure.
  • Fault (Bug): The mechanical or algorithmic cause of an error.

There are many different types of errors and different ways how we can deal with them.

Software Engineering CSE470: Cheng and McUmber

what is this
What is this?

Software Engineering CSE470: Cheng and McUmber

erroneous state error
Erroneous State (“Error”)

Software Engineering CSE470: Cheng and McUmber

algorithmic fault
Algorithmic Fault

Software Engineering CSE470: Cheng and McUmber

mechanical fault
Mechanical Fault

Software Engineering CSE470: Cheng and McUmber

how do we deal with errors and faults
How do we deal with Errors and Faults?

Software Engineering CSE470: Cheng and McUmber

verification
Verification?

Software Engineering CSE470: Cheng and McUmber

modular redundancy
Modular Redundancy?

Software Engineering CSE470: Cheng and McUmber

declaring the bug as a feature
Declaring the Bug as a Feature?

Software Engineering CSE470: Cheng and McUmber

patching
Patching?

Software Engineering CSE470: Cheng and McUmber

testing2
Testing?

Software Engineering CSE470: Cheng and McUmber

examples of faults and errors
Faults in the Interface specification

Mismatch between what the client needs and what the server offers

Mismatch between requirements and implementation

Algorithmic Faults

Missing initialization

Branching errors (too soon, too late)

Missing test for nil

Mechanical Faults (very hard to find)

Documentation does not match actual conditions or operating procedures

Errors

Stress or overload errors

Capacity or boundary errors

Timing errors

Throughput or performance errors

Examples of Faults and Errors

Software Engineering CSE470: Cheng and McUmber

dealing with errors
Dealing with Errors
  • Verification:
    • Assumes hypothetical environment that does not match real environment
    • Proof might be buggy (omits important constraints; simply wrong)
  • Modular redundancy:
    • Expensive
  • Declaring a bug to be a “feature”
    • Bad practice
  • Patching
    • Slows down performance
  • Testing (this lecture)
    • Testing is never good enough

Software Engineering CSE470: Cheng and McUmber

another view on how to deal with errors
Another View on How to Deal with Errors
  • Error prevention (before the system is released):
    • Use good programming methodology to reduce complexity
    • Use version control to prevent inconsistent system
    • Apply verification to prevent algorithmic bugs
  • Error detection (while system is running):
    • Testing: Create failures in a planned way
    • Debugging: Start with an unplanned failures
    • Monitoring: Deliver information about state. Find performance bugs
  • Error recovery (recover from failure once the system is released):
    • Data base systems (atomic transactions)
    • Modular redundancy
    • Recovery blocks

Software Engineering CSE470: Cheng and McUmber

some observations
Some Observations
  • It is impossible to completely test any nontrivial module or any system
    • Theoretical limitations: Halting problem
    • Practial limitations: Prohibitive in time and cost
  • Testing can only show the presence of bugs, not their absence (Dijkstra)

Software Engineering CSE470: Cheng and McUmber

testing takes creativity
Testing takes creativity
  • Testing often viewed as dirty work.
  • To develop an effective test, one must have:
      • Detailed understanding of the system
      • Knowledge of the testing techniques
      • Skill to apply these techniques in an effective and efficient manner
  • Testing is done best by independent testers
    • We often develop a certain mental attitude that the program should in a certain way when in fact it does not.
  • Programmer often stick to the data set that makes the program work
    • "Don’t mess up my code!"
  • A program often does not work when tried by somebody else.
    • Don't let this be the end-user.

Software Engineering CSE470: Cheng and McUmber

testing activities

Requirements

Analysis

Document

Subsystem

Code

Requirements

Analysis

Document

Unit

System

Design

Document

T

est

Tested

Subsystem

User

Manual

Subsystem

Code

Unit

T

est

Integration

Tested

Subsystem

Functional

Test

Test

Functioning

System

Integrated

Subsystems

Tested Subsystem

Subsystem

Code

Unit

T

est

All tests by developer

Testing Activities

Software Engineering CSE470: Cheng and McUmber

testing activities ctd

Client’s

Understanding

of Requirements

User

Environment

Global

Requirements

Accepted

System

Validated

System

Functioning

System

Performance

Acceptance

Installation

Test

Test

Test

Usable

System

Tests by client

Tests by developer

User’s understanding

System in

Use

Tests (?) by user

Testing Activities ctd

Software Engineering CSE470: Cheng and McUmber

fault handling techniques

Fault Handling

Fault Avoidance

Fault Detection

Fault Tolerance

Design

Methodology

Reviews

Atomic

Transactions

Modular

Redundancy

Verification

Configuration

Management

Debugging

Testing

Correctness

Debugging

Performance

Debugging

Integration

Testing

System

Testing

Component

Testing

Fault Handling Techniques

Software Engineering CSE470: Cheng and McUmber

quality assurance encompasses testing

Quality Assurance

Usability Testing

Scenario

Testing

Prototype

Testing

Product

Testing

Fault Avoidance

Fault Tolerance

Atomic

Transactions

Modular

Redundancy

Verification

Configuration

Management

Fault Detection

Reviews

Debugging

Walkthrough

Inspection

Testing

Correctness

Debugging

Performance

Debugging

Integration

Testing

System

Testing

Component

Testing

Quality Assurance encompasses Testing

Software Engineering CSE470: Cheng and McUmber

component testing
Component Testing
  • Unit Testing:
    • Individual subsystem
    • Carried out by developers
    • Goal: Confirm that subsystems is correctly coded and carries out the intended functionality
  • Integration Testing:
    • Groups of subsystems (collection of classes) and eventually the entire system
    • Carried out by developers
    • Goal: Test the interface among the subsystem

Software Engineering CSE470: Cheng and McUmber

system testing
System Testing
  • System Testing:
    • The entire system
    • Carried out by developers
    • Goal: Determine if the system meets the requirements (functional and global)
  • Acceptance Testing:
    • Evaluates the system delivered by developers
    • Carried out by the client. May involve executing typical transactions on site on a trial basis
    • Goal: Demonstrate that the system meets customer requirements and is ready to use
  • Implementation (Coding) and testing go hand in hand

Software Engineering CSE470: Cheng and McUmber

unit testing
Unit Testing
  • Informal:
    • Incremental coding
  • Static Analysis:
    • Hand execution: Reading the source code
    • Walk-Through (informal presentation to others)
    • Code Inspection (formal presentation to others)
    • Automated Tools checking for
      • syntactic and semantic errors
      • departure from coding standards
  • Dynamic Analysis:
    • Black-box testing (Test the input/output behavior)
    • White-box testing (Test the internal logic of the subsystem or object)
    • Data-structure based testing (Data types determine test cases)

Software Engineering CSE470: Cheng and McUmber

black box testing
Black-box Testing
  • Focus: I/O behavior. If for any given input, we can predict the output, then the module passes the test.
    • Almost always impossible to generate all possible inputs ("test cases")
  • Goal: Reduce number of test cases by equivalence partitioning:
    • Divide input conditions into equivalence classes
    • Choose test cases for each equivalence class. (Example: If an object is supposed to accept a negative number, testing one negative number is enough)

Software Engineering CSE470: Cheng and McUmber

black box testing continued
Black-box Testing (Continued)
  • Selection of equivalence classes (No rules, only guidelines):
    • Input is valid across range of values. Select test cases from 3 equivalence classes:
      • Below the range
      • Within the range
      • Above the range
    • Input is valid if it is from a discrete set. Select test cases from 2 equivalence classes:
      • Valid discrete value
      • Invalid discrete value
  • Another solution to select only a limited amount of test cases:
    • Get knowledge about the inner workings of the unit being tested => white-box testing

Software Engineering CSE470: Cheng and McUmber

white box testing
White-box Testing
  • Focus: Thoroughness (Coverage). Every statement in the component is executed at least once.
  • Four types of white-box testing
    • Statement Testing
    • Loop Testing
    • Path Testing
    • Branch Testing

Software Engineering CSE470: Cheng and McUmber

white box testing continued

if ( i =

TRUE) printf("YES\n");

else

printf("NO\n");

Test cases: 1) i = TRUE; 2) i = FALSE

White-box Testing (Continued)
  • Statement Testing (Algebraic Testing): Test single statements (Choice of operators in polynomials, etc)
  • Loop Testing:
    • Cause execution of the loop to be skipped completely. (Exception: Repeat loops)
    • Loop to be executed exactly once
    • Loop to be executed more than once
  • Path testing:
    • Make sure all paths in the program are executed
  • Branch Testing (Conditional Testing): Make sure that each possible outcome from a condition is tested at least once

Software Engineering CSE470: Cheng and McUmber

white box testing example

FindMean(float Mean, FILE ScoreFile)

{ SumOfScores = 0.0; NumberOfScores = 0; Mean = 0;

Read(Scor

eFile, Score);

/*Read in and sum the scores*/

while (! EOF(ScoreFile) {

if ( Score > 0.0 ) {

SumOfScores = SumOfScores + Score;

NumberOfScores++;

}

Read(ScoreFile, Score);

}

/* Compute the mean and print the result */

if (NumberOfScores > 0 ) {

Mean = SumOfScores/NumberOfScores;

printf("The mean score is %f \n", Mean);

} else

printf("No scores found in file\n");

}

White-box Testing Example

Software Engineering CSE470: Cheng and McUmber

white box example determining the paths

FindMean (FILE ScoreFile)

  • { float SumOfScores = 0.0;
    • int NumberOfScores = 0;
    • float Mean=0.0; float Score;
    • Read(ScoreFile, Score);
    • while (! EOF(ScoreFile) {
      • if (Score > 0.0 ) {
          • SumOfScores = SumOfScores + Score;
          • NumberOfScores++;
          • }
      • Read(ScoreFile, Score);
    • }
    • /* Compute the mean and print the result */
    • if (NumberOfScores > 0) {
        • Mean = SumOfScores / NumberOfScores;
        • printf(“ The mean score is %f\n”, Mean);
    • } else
        • printf (“No scores found in file\n”);
  • }

1

2

3

4

5

6

7

8

9

White-box Example: Determining the Paths
constructing the logic flow diagram
Constructing the Logic Flow Diagram

Software Engineering CSE470: Cheng and McUmber

finding the test cases

Start

1

a (Covered by any data)

2

b

(Data set must contain at least

one value)

3

(Positive score)

d

e

(Negative score)

c

5

4

(Data set must

h

(Reached if either f or

g

f

be empty)

6

e is reached)

7

j

i

(Total score > 0.0)

(Total score < 0.0)

9

8

k

l

Exit

Finding the Test Cases

Software Engineering CSE470: Cheng and McUmber

test cases
Test Cases
  • Test case 1 : ? (To execute loop exactly once)
  • Test case 2 : ? (To skip loop body)
  • Test case 3: ?,? (to execute loop more than once)
  • These 3 test cases cover all control flow paths

Software Engineering CSE470: Cheng and McUmber

comparison of white black box testing
White-box Testing:

Potentially infinite number of paths have to be tested

White-box testing often tests what is done, instead of what should be done

Cannot detect missing use cases

Black-box Testing:

Potential combinatorical explosion of test cases (valid & invalid data)

Often not clear whether the selected test cases uncover a particular error

Does not discover extraneous use cases ("features")

Both types of testing are needed

White-box testing and black box testing are the extreme ends of a testing continuum.

Any choice of test case lies in between and depends on the following:

Number of possible logical paths

Nature of input data

Amount of computation

Complexity of algorithms and data structures

Comparison of White & Black-box Testing

Software Engineering CSE470: Cheng and McUmber

the 4 testing steps
1. Select what has to be measured

Completeness of requirements

Code tested for reliability

Design tested for cohesion

2. Decide how the testing is done

Code inspection

Proofs

Black-box, white box,

Select integration testing strategy (big bang, bottom up, top down, sandwich)

3. Develop test cases

A test case is a set of test data or situations that will be used to exercise the unit (code, module, system) being tested or about the attribute being measured

4. Create the test oracle

An oracle contains of the predicted results for a set of test cases

The test oracle has to be written down before the actual testing takes place

The 4 Testing Steps

Software Engineering CSE470: Cheng and McUmber

guidance for test case selection
Use analysis knowledge about functional requirements (black-box):

Use cases

Expected input data

Invalid input data

Use design knowledge about system structure, algorithms, data structures (white-box):

Control structures

Test branches, loops, ...

Data structures

Test records fields, arrays, ...

Use implementation knowledge about algorithms:

Force division by zero

Use sequence of test cases for interrupt handler

Guidance for Test Case Selection

Software Engineering CSE470: Cheng and McUmber

unit testing heuristics
1. Create unit tests as soon as object design is completed:

Black-box test: Test the use cases & functional model

White-box test: Test the dynamic model

Data-structure test: Test the object model

2. Develop the test cases

Goal: Find the minimal number of test cases to cover as many paths as possible

3. Cross-check the test cases to eliminate duplicates

Don't waste your time!

4. Desk check your source code

Reduces testing time

5. Create a test harness

Test drivers and test stubs are needed for integration testing

6. Describe the test oracle

Often the result of the first successfully executed test

7. Execute the test cases

Don’t forget regression testing

Re-execute test cases every time a change is made.

8. Compare the results of the test with the test oracle

Automate as much as possible

Unit-testing Heuristics

Software Engineering CSE470: Cheng and McUmber

component based testing strategy
Component-Based Testing Strategy
  • The entire system is viewed as a collection of subsystems (sets of classes) determined during the system and object design.
  • The order in which the subsystems are selected for testing and integration determines the testing strategy
    • Big bang integration (Nonincremental)
    • Bottom up integration
    • Top down integration
    • Sandwich testing
    • Variations of the above
  • For the selection use the system decomposition from the System Design

Software Engineering CSE470: Cheng and McUmber

using the bridge pattern to enable early integration testing
Using the Bridge Pattern to enable early Integration Testing
  • Use the bridge pattern to provide multiple implementations under the same interface.
  • Interface to a component that is incomplete, not yet known or unavailable during testing

Seat Interface

(in Vehicle Subsystem)

VIP

Seat Implementation

Simulated

Seat (SA/RT)

Stub Code

Real Seat

Software Engineering CSE470: Cheng and McUmber

example three layer call hierarchy

A

Layer I

D

C

B

Layer II

G

F

E

Layer III

Example: Three Layer Call Hierarchy

Software Engineering CSE470: Cheng and McUmber

integration testing big bang approach

Unit Test

UI

Don’t try this!

Unit Test

Billing

System Test

PAID

Unit Test

Learning

Unit Test

Event Service

Unit Test

Network

Unit Test

Database

Integration Testing: Big-Bang Approach

Software Engineering CSE470: Cheng and McUmber

bottom up testing strategy
Bottom-up Testing Strategy
  • The subsystem in the lowest layer of the call hierarchy are tested individually
  • Then the next subsystems are tested that call the previously tested subsystems
  • This is done repeatedly until all subsystems are included in the testing
  • Special program needed to do the testing, Test Driver:
    • A routine that calls a particular subsystem and passes a test case to it

Software Engineering CSE470: Cheng and McUmber

bottom up integration

A

Layer I

D

C

B

Layer II

G

F

E

Layer III

Bottom-up Integration

Test E

Test B, E, F

Test F

Test

A, B, C, D,

E, F, G

Test C

Test D,G

Test G

Software Engineering CSE470: Cheng and McUmber

pros and cons of bottom up integration testing
Pros and Cons of bottom up integration testing
  • Bad for functionally decomposed systems:
    • Tests the most important subsystem last
  • Useful for integrating the following systems
    • Object-oriented systems
    • real-time systems
    • systems with strict performance requirements

Software Engineering CSE470: Cheng and McUmber

top down testing strategy
Top-down Testing Strategy
  • Test the top layer or the controlling subsystem first
  • Then combine all the subsystems that are called by the tested subsystems and test the resulting collection of subsystems
  • Do this until all subsystems are incorporated into the test
  • Special program is needed to do the testing, Test stub :
    • A program or a method that simulates the activity of a missing subsystem by answering to the calling sequence of the calling subsystem and returning back fake data.

Software Engineering CSE470: Cheng and McUmber

top down integration testing

A

Layer I

D

C

B

Layer II

G

F

E

Layer III

Test

A, B, C, D,

E, F, G

Test A, B, C, D

Test A

Layer I

Layer I + II

All Layers

Top-down Integration Testing

Software Engineering CSE470: Cheng and McUmber

pros and cons of top down integration testing
Pros and Cons of top-down integration testing
  • Test cases can be defined in terms of the functionality of the system (functional requirements)
  • Writing stubs can be difficult: Stubs must allow all possible conditions to be tested.
  • Possibly a very large number of stubs may be required, especially if the lowest level of the system contains many methods.
  • One solution to avoid too many stubs: Modified top-down testing strategy
    • Test each layer of the system decomposition individually before merging the layers
    • Disadvantage of modified top-down testing: Both, stubs and drivers are needed

Software Engineering CSE470: Cheng and McUmber

sandwich testing strategy
Sandwich Testing Strategy
  • Combines top-down strategy with bottom-up strategy
  • The system is view as having three layers
    • A target layer in the middle
    • A layer above the target
    • A layer below the target
    • Testing converges at the target layer
  • How do you select the target layer if there are more than 3 layers?
    • Heuristic: Try to minimize the number of stubs and drivers

Software Engineering CSE470: Cheng and McUmber

selecting layers for the paid system
Selecting Layers for the PAID system
  • Top Layer:
    • User Interface
  • Middle Layer:
    • Billing, Learning,Event Service
  • Bottom Layer
    • Network, Database

Software Engineering CSE470: Cheng and McUmber

sandwich testing strategy1

A

Layer I

D

C

B

Layer II

G

F

Test E

E

Layer III

Test B, E, F

Bottom

Layer

Tests

Test F

Test

A, B, C, D,

E, F, G

Test D,G

Test G

Test A

Top

Layer

Tests

Sandwich Testing Strategy

Software Engineering CSE470: Cheng and McUmber

pros and cons of sandwich testing
Pros and Cons of Sandwich Testing
  • Top and Bottom Layer Tests can be done in parallel
  • Does not test the individual subsystems thoroughly before integration
  • Solution: Modified sandwich testing strategy

Software Engineering CSE470: Cheng and McUmber

modified sandwich testing strategy
Modified Sandwich Testing Strategy
  • Test in parallel:
    • Middle layer with drivers and stubs
    • Top layer with stubs
    • Bottom layer with drivers
  • Test in parallel:
    • Top layer accessing middle layer (top layer replaces drivers)
    • Bottom accessed by middle layer (bottom layer replaces stubs)

Software Engineering CSE470: Cheng and McUmber

modified sandwich testing strategy1

A

Layer I

D

C

B

Layer II

G

F

E

Layer III

Modified Sandwich Testing Strategy

Double

Test I

Test B

Test E

Triple

Test I

Triple

Test I

Test B, E, F

Double

Test II

Test F

Test

A, B, C, D,

E, F, G

Test D

Double

Test II

Test D,G

Test G

Test A

Test C

Double

Test I

steps in component based testing
1. Based on the integration strategy, select a component to be tested. Unit test all the classes in the component.

2. Put selected component together; do any preliminary fix-up necessary to make the integration test operational (drivers, stubs)

3. Do functional testing: Define test cases that exercise all uses cases with the selected component

4. Do structural testing: Define test cases that exercise the selected component

5. Execute performance tests

6. Keep records of the test cases and testing activities.

7. Repeat steps 1 to 7 until the full system is tested.

The primary goal of integration testing is to identify errors in the (current) component configuration.

Steps in Component-Based Testing

.

Software Engineering CSE470: Cheng and McUmber

which integration strategy should you use
Factors to consider

Amount of test harness (stubs &drivers)

Location of critical parts in the system

Availability of hardware

Availability of components

Scheduling concerns

Bottom up approach

good for object oriented design methodologies

Test driver interfaces must match component interfaces

...

...Top-level components are usually important and cannot be neglected up to the end of testing

Detection of design errors postponed until end of testing

Top down approach

Test cases can be defined in terms of functions examined

Need to maintain correctness of test stubs

Writing stubs can be difficult

Which Integration Strategy should you use?

Software Engineering CSE470: Cheng and McUmber

system testing1
System Testing
  • Functional Testing
  • Structure Testing
  • Performance Testing
  • Acceptance Testing
  • Installation Testing

Impact of requirements on system testing:

    • The more explicit the requirements, the easier they are to test.
    • Quality of use cases determines the ease of functional testing
    • Quality of subsystem decomposition determines the ease of structure testing
    • Quality of nonfunctional requirements and constraints determines the ease of performance tests:

Software Engineering CSE470: Cheng and McUmber

structure testing
Structure Testing
  • Essentially the same as white box testing.
  • Goal: Cover all paths in the system design
    • Exercise all input and output parameters of each component.
    • Exercise all components and all calls (each component is called at least once and every component is called by all possible callers.)
    • Use conditional and iteration testing as in unit testing.

Software Engineering CSE470: Cheng and McUmber

functional testing
Functional Testing

.

Essentially the same as black box testing

  • Goal: Test functionality of system
  • Test cases are designed from the requirements analysis document (better: user manual) and centered around requirements and key functions (use cases)
  • The system is treated as black box.
  • Unit test cases can be reused, but in end user oriented new test cases have to be developed as well.

.

Software Engineering CSE470: Cheng and McUmber

performance testing
Stress Testing

Stress limits of system (maximum # of users, peak demands, extended operation)

Volume testing

Test what happens if large amounts of data are handled

Configuration testing

Test the various software and hardware configurations

Compatibility test

Test backward compatibility with existing systems

Security testing

Try to violate security requirements

Timing testing

Evaluate response times and time to perform a function

Environmental test

Test tolerances for heat, humidity, motion, portability

Quality testing

Test reliability, maintain- ability & availability of the system

Recovery testing

Tests system’s response to presence of errors or loss of data.

Human factors testing

Tests user interface with user

Performance Testing

Software Engineering CSE470: Cheng and McUmber

test cases for performance testing
Test Cases for Performance Testing
  • Push the (integrated) system to its limits.
  • Goal: Try to break the subsystem
  • Test how the system behaves when overloaded.
    • Can bottlenecks be identified? (First candidates for redesign in the next iteration
  • Try unusual orders of execution
    • Call a receive() before send()
  • Check the system’s response to large volumes of data
    • If the system is supposed to handle 1000 items, try it with 1001 items.
  • What is the amount of time spent in different use cases?
    • Are typical cases executed in a timely fashion?

Software Engineering CSE470: Cheng and McUmber

acceptance testing
Goal: Demonstrate system is ready for operational use

Choice of tests is made by client/sponsor

Many tests can be taken from integration testing

Acceptance test is performed by the client, not by the developer.

Majority of all bugs in software is typically found by the client after the system is in use, not by the developers or testers. Therefore two kinds of additional tests:

Alpha test:

Sponsor uses the software at the developer’s site.

Software used in a controlled setting, with the developer always ready to fix bugs.

Beta test:

Conducted at sponsor’s site (developer is not present)

Software gets a realistic workout in target environ- ment

Potential customer might get discouraged

Acceptance Testing

Software Engineering CSE470: Cheng and McUmber

testing has its own life cycle
Testing has its own Life Cycle

Establish the test objectives

Design the test cases

Write the test cases

Test the test cases

Execute the tests

Evaluate the test results

Change the system

Do regression testing

Software Engineering CSE470: Cheng and McUmber

test team

Professional

Tester

too familiar

Programmer

with code

Analyst

System

Designer

Test

User

Team

Configuration

Management

Specialist

Test Team

Software Engineering CSE470: Cheng and McUmber

summary3
Summary
  • Testing is still a black art, but many rules and heuristics are available
  • Testing consists ofcomponent-testing (unit testing, integration testing) and system testing
  • Design Patterns can be used for component-based testing
  • Testing has its own lifecycle

Software Engineering CSE470: Cheng and McUmber