cs314: course summary

12/2/2009

1

CS314: Course Summary

Prof. Robert B. France

Dept. of Computer Science

Colorado State University

Robert B. France 1

y

12/2/2009

2

Software Development Issues Explored - 1

• Software engineering basics– Why do we need to engineer software?

• Object-Oriented Programming review (OOP)– What is Object-Oriented Programming?

• Software development processes– Why do we need to pay attention to how we

develop software?

Robert B. France 2

12/2/2009

3

Software Development Issues Explored - 2

• Requirements modeling and analysis– Why do we need to model and analyze the problem?

• User-interface design– Why do we need to pay attention to usability and utility of software?

• Software designSoftware design – Why do we need to describe our designs in a non-programming

language such as the UML?

– Why do we need design principles?

• Systematic software testing– Why do we need systematic testing techniques?

– Why is ad-hoc testing not always good enough?

Robert B. France 3

12/2/2009

4

Course Overview

• Software engineering basics

• Object-Oriented Programming review (OOP)

• Software development processes

• Requirements modeling and analysis

• User-interface design

• Software design

• Systematic software testingSystematic software testing

Robert B. France 4

12/2/2009

5

Why engineer software?

• Many modern systems are complex.

• Consequences of software errors are more critical today.– Failures can lead to loss of lives, loss of investments and assets,

loss of reputation, loss of privacy.

– Organization survivability often dependent on “mission-critical” O ga at o su v vab ty o te depe de t o ss o c t casoftware systems

• It is not good enough that systems produce the correct result; they also have to be secure, highly-available, safe, fault-tolerant, evolvable, …

C l i f f f i d l

Robert B. France 5

• Complexity of software often requires developers to work in teams to develop software.

12/2/2009

6

Key Ideas

• Programming-in-the-large vs. Programming-in-the small– “programming-in-the-small” skills focus on how to put

together lines of code that correctly implement a well-understood solutionProgramming in the large focus on how to architect large– Programming-in-the-large focus on how to architect large systems so that they are evolvable, flexible, safe, secure, …

• Software engineering is all about problem solving• Software engineering focuses on controlling

essential complexity and reducing accidental complexity

Robert B. France 6

complexity

12/2/2009

7

Key Observations - 1

• Untrained people can hack something together that (apparently) works

• Software evolves (change is inevitable for useful systems).systems).

• The later errors are identified the more expensive they are to correct.

• The source of many errors can be traced back to l k f tt ti t tti th i ht i t

© Robert B. France 1-7

lack of attention to getting the right requirements.

• Programming is less error prone than design.

12/2/2009

8

Key Observations - 2

• Change is more difficult than it appears• Problem is not always well-defined

• A good software engineer is one who has the knowledge to choose the right tools for the task atknowledge to choose the right tools for the task at hand– There are many software engineering tools, techniques

and methods; each has its strengths and limitations; none are applicable in all situationspp

– There is no software development “silver bullet”

Robert B. France 8

12/2/2009

9

Course Overview






• Software design


Robert B. France 9

12/2/2009

10

Key Idea

• A good OO program is one in which object collaborate to accomplish functional goals– Everything is not done in main()

– Objects do more than just get() and set() attributes

– Guidelines for distributing responsibility are captured in patterns such as the GRASP p ppatterns

Robert B. France 10

12/2/2009

11

GRASP Patterns of Responsibility Assignment

• Cohesion

• Expert

• Creator

• Low Coupling

• Controller

12/2/2009

12

Course Overview






• Software design


Robert B. France 12

12/2/2009

13

Key Idea

• In order to improve as software developers we need to pay attention to the process we use– Allows us to learn from our mistake

– Brings us closer to an engineering discipline, where quality can be replicated through use of proven, repeatable processes

Robert B. France 13

12/2/2009

14

Process Models

• Code and Fix

• Waterfall

• Iterative/Incremental– Unified Process

• Software delivered in increments over a number of iterations

• Each iteration is timeboxedac te at o s t ebo ed

Robert B. France 14

12/2/2009

15

Course Overview






• Software design


Robert B. France 15

12/2/2009

16

Key Ideas

• Requirements activities focuses on the problem NOT a solution to the problem– The purpose is to develop a deep

d t di f th bl th tunderstanding of the problem so that we can build appropriate solutions

• Both functional and non-functional (system attributes) requirements must be elicited ) qand analyzed

Robert B. France 16

12/2/2009

17

Requirements Activities

• Elicitation: extracting requirements from customers and users

• Analysis: modeling and examining requirements to gain deeper understanding

• Specification: detailed documentation of requirements• Specification: detailed documentation of requirements• Validation: requirements are validated against

customer/user needs• Requirements management: activities related to

documenting, controlling and tracking requirements and h t i tchanges to requirements

Robert B. France 17

12/2/2009

18

Requirements Models

• Modeling required behavior (dynamic models)– Use Cases: Focus only on interactions between

system and direct userssystem and direct users

• Modeling problem concepts and their relationships (static models)– Class Model: Classes represent problem C ss ode : C sses ep ese p ob e

concepts, NOT programming language concepts

Robert B. France 18

12/2/2009

19

Course Overview






• Software design


Robert B. France 19

12/2/2009

20

Key Ideas

• Software development must focus on the needs of the customer

• Proper attention to both usability and utility is neededneeded– Utility: Does the system provide the raw capabilities

to allow the user to achieve their goal?

– Usability: Does the system allow the user to learn and to use the raw capabilities easily? p y

Robert B. France 20

12/2/2009

21

Key Principles

• Ensure that the user always knows what he or she can and should do next.

• Provide good feedback including effective error messages.

• Ensure that the user can always get out, go back or undo an action.

• Ensure that the UI’s appearance is uncluttered.

• Consider the needs of different groups of users.

• Provide all necessary help.

• Be consistent.

Robert B. France 21

12/2/2009

22

Course Overview






• Software design


Robert B. France 22

12/2/2009

23

Key Idea

• Describe solution in a language other than a programming language– UML

• Use techniques and tools that are based on proven principles

• Use patterns to help improve the flexibility f l tiof your solution

Robert B. France 23

12/2/2009

24

Key Principles

• Formality and Rigor

• Separation of concerns– Separation in time

– Separation of viewsSeparation of views

– Separation of parts

– Separation of qualities

– Abstraction

• Reusability• Reusability

• Generality

• Incrementality Robert B. France 24

12/2/2009

25

Key Concepts

• Abstraction– Functional abstraction

– Data abstraction

• Information hiding

• Encapsulation

• Cohesion

• Coupling

Robert B. France 25

12/2/2009

26

Design Models

• Static models– Design class models: Describe solution concepts and

their relationships

• Dynamic modelsDynamic models– Sequence models: Describes how objects interact to

accomplish a functional goal• Used to describe how requirements use cases are realized in a

design

– Other models not covered in this class: State and Activity models

Robert B. France 26

12/2/2009

27

Course Overview






• Software design


Robert B. France 27

12/2/2009

28

Key Ideas

• Use test criteria to determine whether your test cases adequately cover the program input space

• Separate testing concerns: unit vs. integration vs. system vs. alpha vs. beta vs acceptance testing

Robert B. France 28

12/2/2009

29

Testing TerminologyTesting terminology is not standardized.• Failure: invalid behavior

– A failure occurs when a program executing on input data produces incorrect output.

• Defect, error: cause of a failure– Some texts make a distinction between errors and defects

(e.g., see course text), where an error is a behavior by the programmer (e.g., a bad decision) that leads to a defect in software.

• Fault: an incorrect intermediate state that may be entered during program execution

29

during program execution– a failure occurs only if a fault happens during execution– A fault occurs only if an error exists in the program

12/2/2009

30

Testing Terminology (2)

• Analysis: a search for failures by experimentation (e.g., testing) or static analysis.

• Defect removal (debugging): search for errors and their repair.T t t f l f th i t i bl f• Test case: a set of values for the input variables of a program

• Test set: a finite set of test cases• Test oracle: determines whether a test produced

correct outputs.

30

correct outputs.

12/2/2009

31

Levels of Program Testing

Testing-in-the-small– Unit testing: testing a procedure, function,

or class.

Testing-in-the-largeTesting-in-the-large– Integration testing: testing connections

between units and components.– System testing: test entire system.

A t t ti t ti t d id

31

– Acceptance testing: testing to decide whether to purchase the software.

12/2/2009

32

Levels of Program Testing (2)

• Alpha testing: system testing by a user group within the developing organization.

• Beta testing: system testing by select customers.

• Regression testing: retesting after a software modification.

32

12/2/2009

33

White-box testing criteria

• Statement coverage

• Edge coverage

• Condition coverageg

• Path coverage

Robert B. France 33

12/2/2009

34

Wrap-up

• This course covers just the tip of the software engineering iceberg

– UML continues to evolve • current standard is 2.2 and work is ongoing on an updated version

• there will be a more formal version called fUML which provides support for executing UML

b d d l– Component-based development

– Service-oriented architectures

– User interface design

– Testing web-services, GUI applications, …

– Formally modeling and analyzing software using mathematical techniques

Robert B. France 34

12/2/2009

35

Future of Software Engineering?

• Model-driven software development – focus on raising the level of abstraction at which software is developed; support automated generation of code from models in particular domains

• Aspect-oriented development – focus on managing complexity that arises when software features interact

• [email protected] – focus on applying [email protected] focus on applying models at runtime to manage runtime adaptation of software

Robert B. France 35

12/2/2009

36

This is not the end …

Robert B. France 36

cs314: course summary

Documents