Midterm Review Summer 2003 1

ICS 52: Introduction to Software Engineering

Lecture Notes for Summer Quarter, 2003

Michele RousseauMidterm Review

Partially based on lecture notes written by Sommerville, Frost, Easterbrook & Tonne.. Duplication of course material for any commercial purpose without the

written permission of the lecturers is prohibited

Midterm Review Summer 2003 2

Exam Information

The exam will be given in lecture, so you’ll have 120 minutes.

The exam is closed book, closed notes, closed laptops and of course you can’t consult your classmates.

Try to space yourselves out

Midterm Review Summer 2003 3

Exam coverage

Lecture topics 1-8 Sommerville, chapters 1-3, 5-12, 14

Midterm Review Summer 2003 4

Software Engineering Basics (Topic 1)

What is Software Engineering? What is software (other than just

programs) What is the goal of software

engineering (Why do it?)• What is the software crisis

How does it differ from…• Programming• Architecture (how is it like this too?)

Midterm Review Summer 2003 5

The five P’s

People Product Project Process Professionalism

Midterm Review Summer 2003 6

Software Qualities (Topic 2)

Correctness Reliability Robustness Performance Usability Maintainability

• Corrective• Adaptive• Perfective

Repairability Evolvability Reusability Portability Safety Verifiability

Why not have them all?

Midterm Review Summer 2003 7

Software Process (Topic 2)

What is it? Fundamental Activities of a software

lifecycle• Requirements/Specification• Architecture/Design• Implementation• Integration• Operation/Maintenance

Midterm Review Summer 2003 8

Software Lifecycle Model

What are the Models?• Stepwise Development • Waterfall• Rapid Prototyping• Spiral• Incremental• Synchronize-and-Stabilize• Evolutionary – in book chpt 3 (pg 46)

What are the pros and cons of each

Midterm Review Summer 2003 9

Software Principles (Topic 3)

What are they?• Rigor & Formality – to be exact or precise• Separation of Concerns – “Divide &

Conquer”• Modularity – divide into smaller

pieces/modules• Abstraction – abstract away unnecessary

details• Anticipation of Change • Generality – focus on discovering a more

general problem• Incrementality – proceed in stepwise

fashion (incrementsUse more indepth definitions in lecture slides

Midterm Review Summer 2003 10

Software Principles

How do they apply to Requirements? How do they apply to Design? Know the benefits of them and why

they are necessary

Midterm Review Summer 2003 11

Requirements Engineering (Topic 4)

What is Requirements Engineering?• What is the process?

» Feasibility study» Requirements elicitation and analysis» Requirements specification» Requirements Validation

What is a feasibilty study? What are the problems with Requirements

Analysis? (What makes it hard?)• Domain issues• Communication issues

• Details in slides

Midterm Review Summer 2003 12

Requirements Specification

What does a requirements specification say about the system? What does is describe?

Why is it important to get them right? What is the difference between a

functional and non-functional requirement?

What is an acceptance test plan? How do we measure non-functional

requirements?

Midterm Review Summer 2003 13

Requirements continued

What are the different techniques we discussed?

What is wrong with Natural language documents?• What are our alternatives? (topic 5)

What are some of the problems we typically run into with requirements (topic 5)

What are enduring vs. volatile requirements?

What are some basic guidelines for writing requirements?

How can we verify them?

Midterm Review Summer 2003 14

Alternatives to NL

Structured Language Form-based Specifications PDL-Based Formal Specifications

• Abstract model• Algebraic• State Transition• Axiomatic

Midterm Review Summer 2003 15

Requirements

You should know how to interview a customer to elicit requirements.

You should know how to write a textual (non-formal) requirements document.

You should understand the structure of a requirements document and know the appropriate kinds of information in such a document.

Midterm Review Summer 2003 16

Alternatives to NL

For each you should know… What they are. Why we use them. When do we use them? Pros/Cons Can we only use one style for a

system?

Midterm Review Summer 2003 17

Software Architecture

Know the difference between Architectural Design and Module Design (Topic 6)

What is Architectural Design?• What is its purpose?• What does it describe

Why do we do it & advantages Know the different parts of the Architectural

Design Process• System Structuring• Control Modeling• Modular Decomposition

Differences between Subsystems and Modules

Midterm Review Summer 2003 18

More on S/w Arch (Topic 6)

Can one model work for everything? Should you only use 1 model for an

entire system? What does a model consist of?

• Components• Connectors• Constraints• Interfaces

Midterm Review Summer 2003 19

Know the Models (Topics 6 & 7)

General Models• Structural

» Repository MVC – Model View Controller (Good for UIs)

» Client-Server» Layered (or Abstract Machine) Model

• Control Models» Centralized Control Models

Call-return Model Real-Time system Control Model

» Event Driven Broadcast Model Interrupt-Driven Control

• Modular Decomposition» DataFlow

Pipe & Filter (DataFlow Model) Object Models

Domain Specific• Generic (Bottom-Up)• Reference (Top-Down)

Midterm Review Summer 2003 20

Models continued

Know what type of models they are• General

» System Structuring» Control Modeling» Modular Decomposition

• Domain Specific Pros/Cons

Midterm Review Summer 2003 21

Design (Topic 7&8)

What makes a good design?• How do the principles apply?

What is a Module? What is an Abstract Data type?

• What is the goal… why use them?• What is information hiding?

Interfaces• Why do we need them? – why are they

important?• What do they do?

Midterm Review Summer 2003 22

Module Basics (Topic 8)

Information Hiding Reusable Modules Designing for Program Families

• What is a program family?• Why should we design for it?

Why are these important? What are the Cons

Midterm Review Summer 2003 23

Design Continued (Topic 8)

Know Uses diagrams• What do they represent?• Is it the same as an invokes diagram?

» A diagram that shows all calls between modules

What is fan-in and fan out (with respect to diagrams)?• Which is more desirable and why?

Know what is-component-of relationship is• How does it relate to is-composed-of• Or Comprises diagram

Midterm Review Summer 2003 24

Design continued

What is Stepwise refinement?• Top-down, bottom-up• Pros/Cons

What are the tools of the trade or techniques for design?• Apply Information Hiding• Use the Requirements Document• Anticipate Change• Design for incrementality/generality

(Reuse)• Design for Program families• Determine usage patterns

Midterm Review Summer 2003 25

Architecture/Design

Are architectures reusable? What is coupling? What is cohesion?

Try to keep in mind what the underlying goals of software engineering are…• Why do we do this?

Remember there are pros & cons to everything

There are cost trade-offs.. What are they?

Midterm Review Summer 2003 26

Basic Format

Short Answer Long Answer Multiple choice Maybe some T/F

Some Tips• Don’t wait until the last minute to study• Study Groups

» Come prepared you’ll get more out of it.» Study on your own again after study group

• Get a good nights sleep and don’t starve yourself the day of the test» Good brain food – nuts.. Not so good – carbs

• If you don’t know the answer off the top of your head--- move on to the next question

• Go for the points – balance your time