Software Engineering

Lecture 1
Introduction to Software Engineering
Code of Conduct
 Software Engineering is a collaborative activity. You are
encouraged to work together, but ...
 Some ta...
Projects
 Project teams, about 3 to 5 peoples.
 Select your own project, any branch of software engineering
 Real proje...
Project Selection
 Some suggested projects
 Recitation section to suggest projects
Contact potential clients:
 Gain ide...
Previous Experience
Your background







Biggest program that you have written?
Biggest program that you have work...
Course Themes
1. Leadership of large software projects
 Software as a product
Clients and their needs
Quality
 Requireme...
Course Themes
2. Large and very large systems
 Software design
Software architecture
Object-oriented design
 Dependable ...
Characteristics of Software Products
General characteristics
Usability
Maintainability
Dependability
Efficiency
Good softw...
Software as a Product
Software is expensive!!
Every software project has a trade-off between:
Functionality
Resources (cos...
Client (a.k.a Customer)

 The client provides resources and expects some product in
return.
 Client satisfaction is the ...
Variety of Software Products
Examples?
-Operation System
-Database Management System
-Embedded System
-Games
-Application ...
Categories of Product

Categories of client and software product:
 Generic (e.g., Microsoft Excel)
 Bespoke (customized)...
Variety of Software Products
Software products are very varied
--> Client requirements are very different
--> There is no ...
Professional Responsibility
Organizations put trust in software developers:
 Competence: Software that does not work effe...
Software Engineering

Lecture 2
The Software Process
Books

 Frederick P. Brooks, Jr. The Mythical Man Month.
Addison-Wesley, 1972.
 Ian Sommerville, Software Engineering, 6...
Software Process

Fundamental Assumption:
Good processes lead to good software
Good processes reduce risk
Risk Management
What can go wrong in a software project?
How can the risk be reduced?
The Software Process (Simplified)
Feasibility and
Planning

Requirements

Design

Implementation

Operation and
Maintenanc...
The Waterfall Model
Requirements
Definition
System and
Software design
Programming
and Unit Testing
Integration and
System...
Requirements Analysis and Definition
The system's services, constraints and goals are established by
consultation with sys...
System and Software Design

System design: Partition the requirements to hardware or
software systems. Establishes an over...
Programming and Unit Testing

The software design is realized as a set of programs or
program units. (Written specifically...
Integration and System Testing

The individual program units are:
 integrated and tested as a complete system
 tested ag...
Operation and Maintenance
 Operation: The system is put into practical use.
 Maintenance: Errors and problems are identi...
Discussion of the Waterfall Model
Advantages:





Process visibility
Dependence on individuals
Quality control
Cost c...
Feedback in the Waterfall Model
Requirements
Definition
System and
Software design
Programming
and Unit Testing
Integratio...
Iterative Refinement
(Evolutionary Development)
Concept: Initial implementation for user comment, followed
by refinement u...
Iterative Refinement
Evaluation

Requirements

Implementation
(prototype)

Design
Iterative Refinement
Concurrent
Activities
Requirements
Outline
Description

Design

Implementation

Initial
Version
Inter...
Iterative Refinement & Software
Process
Concurrent
Activities
Outline
Description

Requirements
Design

Implementation

Fi...
Iterative Refinement
When is iterative refinement appropriate?
Iterative Refinement + Waterfall Model:
Graphics for Basic
Outline Description: Add vector graphics to
Dartmouth Basic.
Ph...
Iterative Refinement + Waterfall Model:
Graphics for Basic
Design Issues:
 Pictorial subprograms: coordinate systems, win...
Iterative Refinement + Waterfall Model:
Graphics for Basic
Phase 1: Implementation (Waterfall)
 When the final specificat...
Observations about Software Processes

Completed projects should look like the Waterfall Model
but ... the development pro...
Software Engineering

Lecture 3
(a) Feasibility Study
(b) Requirements Definition
Feasibility Study
Before beginning a project, a short, low-cost study to identify
•

Client

•

Scope

•

Potential benefi...
Feasibility Study
A feasibility study leads to a decision:
go ahead
do not go ahead
think again
In production projects, th...
CS 501: Client

In CS 501, you have two clients:
• The client for the project
• The professor for the course
Can you satis...
Scope
What are the boundaries of the project?
CS 501 Examples:
• Static web pages with open access on the Web [Web Profile...
Potential Benefits
Why are you doing this project?
Examples
• Create a marketable product
• Improve the efficiency of an o...
Resources
Examples: CS 501
Staff: 5 to 7 students, with some help. How many hours per week?
What skills do people have?
Ti...
Obstacles
CS 501 projects
Start-up time. Creating a team, scheduling meetings, acquiring
software, learning new systems, ....
How to Minimize Risk?
CS 501 Projects
• Several target levels of functionality:
required, desirable, optional
• Visible so...
Feasibility Report
A written document
• For a general audience: client, financial management,
technical management, etc.
•...
Requirements Definition and Analysis
Requirements
Definition
System and
Software design
Programming
and Unit Testing
Integ...
Example: Library of Congress
(A Partial Failure)

Outline Description
The Library of Congress requires a repository system...
Chronology
1993-94 CNRI carries out research on architectures for
digital libraries
1995-97 CNRI implements prototype repo...
The Repository
Repository

Users

Identification System

Search System
Storage and Representation of Complex
Objects
Data
Several representations:
thumbnail image
reference image
archival image...
Repository: Research Achievements
1. CORBA implementation of repository access protocol.
2. Integration of persistent nami...
Good Discoveries During Prototype

• Structuring complex information in digital libraries
• Data driven digital library in...
Bad Discoveries During Prototype

• Resistance to change within Library of Congress
• Technical weakness of Library of Con...
Mistakes

• Confusion of objectives (research and implementation)
• Failure to involve all stakeholders
• Over-ambitious (...
The Requirements Process
Feasibility
Study

Feasibility
Report

Requirements
Analysis
Requirements
Definition
System
Model...
Requirements Definition

High-level abstract description of requirements:
• Specifies external system behavior
• Comprehen...
Library of Congress Requirements Study

Team (all experienced): Librarian, Software Engineer (CNRI),
Computing Project Lea...
Functional Requirements

Example: Library of Congress repository
• Support for complex digital objects
• Access management...
DRAFT OVERVIEW OF ITS SUPPORT
FOR NDLP PRODUCTION AND DELIVERY OF AMERICAN MEMORY
NDLP collections
already released

Cooli...
Non-functional Requirements
Environment:
• Estimates of sizes, numbers of users, etc.
• Reliability and performance measur...
Evolution of Requirements
• If the requirements definition is wrong, the system will be
a failure.
• With complex systems,...
Software Engineering

Lecture 4
Management I: Project Management
The Aim of Project Management

To complete a project:
• On time
• On budget
• With required functionality
• To the satisfa...
The Project Manager
•
•
•
•

Create and maintain the schedule
Should track progress against schedule
Keep some slack in th...
Project Planning Methods
The Critical Path Method, Gantt charts, Activity bar charts, etc.
are roughly equivalent.
These m...
Example: An Open University Course
Deliverables:
16
8
8
4
1
4

Written texts (bound in pairs)
Television programs
Radio pr...
Flexibility

Schedule: Dates for broadcasting TV and radio programs are
fixed. Printing and mailings can be accelerated if...
Scheduling: Critical Path Method

An activity

A dummy activity

An event

A milestone
Critical Path Method

other
activities
START

Revise
Unit 3

Edit
Unit 3

Print
Unit 3

Mail
Unit 3
END
Critical Path Method

other
activities

Revise
Unit 3

Edit
Unit 3

START

other
activities

Revise
Unit 4

Edit
Unit 4

T...
Critical Path Method
Script
TV 2
START

Edit
Unit 3

Make
TV 2

Edit
Unit 4

Prototype Computer 1

Document
Computer 1

Ma...
Time Estimates for Activities (Weeks)

4
1

6
3

2

3
1

12
12

1

3

2

4
4

1

3
2

8
Earliest Start Dates

1
1
12

26

4
3

6
15

2

17

3

12
0

12
12

3

2

17

3
19

1

22

1

23
2

4
4

4

1

17

8

25
Latest Start Dates

11
1
12

4
3

6
15

1

2

17

3

12
0

12
14
4
13

3

26

2

17
4

3
20

23

1

24
2
17

1

8

25
Critical Path
1/11
12/12

26/26
15/15

17/17
22/23

0/0
12/14
4/13

17/17

19/20
17/17

23/24

25/25
Slack
1/11
10 12/12
0

0/0

26/26
10

3
15/15

0

0

0
1

22/23

0

2 12/14 2 17/17
9

17/17

4/13

19/20

1
0

9

23/24

...
Key Personnel

In computing, not all people are equal:
• The best are at least 5 times more productive
• Some tasks are to...
Key Personnel: Schedule for Editor
Earliest Start Date

Activity

Weeks 15-16
Weeks 17-18
Weeks 19-20
Weeks 21-22

Edit Un...
Start-up Time
On a big project, the start-up time is typically three to six
months:
• Personnel have to complete previous ...
Experience with Critical Path Method
Administrative computing department at Dartmouth used the
Critical Path Method for im...
CS 501: Software Engineering

Lecture 5
(a) Documentation
(b) Requirements Analysis
Assignments

September 13
October 4
October 16
November 8
Nov 29 - Dec 1
Exam week

Feasibility and plan
Requirements
Midt...
Assignment 1
Wednesday, September 13: Project plan due -- report.
Title of project
Client/customer
Team members
Outline de...
Documentation
• Reasons for documentation:
visibility (e.g., project plan, interim report)
user support (e.g., user manual...
Form of Documentation

External
• Printed
• Web site
Internal
• Program documentation
• Program context (e.g., copyright n...
Requirements Definition and Analysis
Requirements
Definition
System and
Software design
Programming
and Unit Testing
Integ...
The Requirements Process
Feasibility
Study

Feasibility
Report

Requirements
Analysis
Requirements
Definition
System
Model...
Requirements Analysis
1. Understand the requirements in depth:
• Domain understanding
Examples: science research, applicat...
Viewpoint Analysis
Example: University Admissions System
• Applicants
• University administration
Admissions office
Financ...
Interviews with Clients
Clients may have only a vague concept of requirements.
• Prepare before you meet with them
• Keep ...
Requirements Analysis

2. Organize the requirements:
• Classification into coherent clusters
(e.g., legal requirements)
• ...
Requirements Analysis

3. Model the requirements:
• Informal
Prose
• Systematic
Procedural models
Data-centric models
Obje...
Procedural Models: Flowchart

Operation
Decision
Manual operation
Report
Flowchart: University Admissions

Form
received

New?
T
Database
record
Notify
student

F

Update
database

Complete? T
F
...
Procedural Models: Pseudo-code
Example: Check project project plan
check_plan (report)
if report (date_time) > due_date_ti...
Data-Flow Models

External entities
Processing steps
Data stores or sources
Data flows
Example: University Admissions

Rejection
Application
Completed
form
Receive application
Evaluate
application
Applicant
Of...
Example: University Admissions
Assemble Application Stage
Acknowledgment
Application
form

Receive

Applicant

Completed
a...
Example: University Admissions
Process Completed Application Stage
Rejection
Evaluation
request

Evaluation

Acceptance

S...
Requirements Analysis v. System Design
Dilemma.
• Requirements analysis should make minimal assumptions
about the system d...
CS 501: Software Engineering

Lecture 6
(a) Requirements Analysis (continued)
(b) Requirements Specification
The Requirements Process
Feasibility
Study

Feasibility
Report

Requirements
Analysis
Requirements
Definition
System
Model...
Requirements Analysis
Methods for data modeling and design
• Data flow diagrams
• Entity-relation diagrams
• Data dictiona...
Entity-Relation Model

A Design Methodology for Relational Databases
• A database of entities and relations
• Tools for di...
Entity-Relation Diagram

An entity
A relation between
entities
An entity or relation
attribute
An inheritance
relation
Example: CS 501 Project
Major

Client
1

Student

Project
1

CS501
Student

5 to 7

Member of

0:n
Person

0:n

0:n
Tech c...
MARC Format for Monographs
(Books)
001
245
260
650
650
700

89-16879 r93
Campus strategies for libraries and electronic in...
Entity-Relation Diagram for MARC
Book

0:n

1

0:n

Describes
0:n
Catalog
record
Short title

1:n

Author of
Editor of

Is...
Data Dictionaries

A data dictionary is a list of names used by the system
• Brief definition (e.g., what is "date")
• Wha...
A Note on Object Models

This course teaches object models as a tool for design.
Some people recommend object models for r...
Non-Functional Requirements
Product requirements
performance, reliability, portability, etc...
Organizational requirements...
Examples of Non-Functional
Requirements
Privacy (Mercury digital library)
Functional requirement:
Usage data for managemen...
Unspoken Requirements

Example:
Resistance to change at XXX
Requirements Specification
What is the purpose of the Requirements Specification?
Requirements Specification: Purpose

1. It describes the requirements to the stakeholders
• Expressed in the terms that th...
Requirements Specification: Purpose
2. It describes the requirements to the implementers
• As precise and specific as poss...
Requirements Specification: Purpose
3. It records the requirements for the future
• An essential part of system evolution
...
Requirements Specification: Approaches

• Natural language
• Structured natural language
• Design description language
• R...
CS 501: Software Engineering

Lecture 7
Management II
Business and Legal Aspects of
Software Engineering
Legal Environment
Software is developed in a complex legal and
economic framework. Changes in laws follow
changes in techn...
Legal Topics
• International
• Intellectual property (copyright, patent, contract)
• Tort (e.g., liability of Internet ser...
Copyright
A copyright gives the owner the exclusive right to:
• reproduce
• distribute
• perform
• display
• license
Gradu...
Copyright
Copyright at creation
•
•
•
•
•

Works for hire
Contracts and licenses
First sale
Fair use
Infringement (contami...
Software Patents

• Should be: non-obvious, novel, useful
• 17 years from award (20 years from application)
• Poor quality...
Contracts and Licences
Contracts allow intellectual property to be sold or licensed
•
•
•
•
•
•
•

Promise in exchange for...
Derivative Works
When software is derived from other software:
• New code is owned by new developer
• Conditions that appl...
Privacy
Invasions of privacy:
•
•
•
•

intrusion
appropriation of name or likeness
unreasonable publicity
false light

Be ...
Software Business Questions
• You are employed for company X writing software.
When you leave, who owns your work? What us...
Your Next Job ...

• Employment contract may restrict your next job (not
working for competitors, etc.)
• Trade-secret inf...
Trade Secrets and Non-Disclosure
Agreements
Trade Secret
"... information, including a formula, pattern, compilation,
prog...
Some Business Models
• Software developed in-house
• Package licensed to customer, binary only (Microsoft
model)
• Package...
Free-Lance Software Development

You and a few friends create a company to develop software.
How much should you charge pe...
Free-Lance Software Development
Salary
Taxes and benefits
Rent, equipment, etc.
Fees, services, etc.
Travel and misc.
TOTA...
Fixed and Variable Cost: Packaged Software
Example:
• The initial development cost of a software product
is $10 million.
•...
Fixed and Variable Costs: Profit or Loss
$15M

$10M

$5M

2,500

5,000

7,500

Unit
sales
Community Development
• Shareware
• Open source (e.g., Linux, Apache, Perl, etc.)
-> Shared development
-> Market penetrat...
Open Source

• Free redistribution
• Source code
• Derived works
• Integrity of the author's source code
• No discriminati...
Open Source

• No discrimination against fields of endeavor
• Distribution of license
• License must not be specific to a ...
Practical Advice

Be aware of the law, but do not pretend to be a lawyer.
Use a professional for:
• Contracts and licenses...
Source Code Management
Or
Configuration Management: How I
learned to Stop Worrying and Hate My
Co-workers Less
Source Code Management
 Also known as Configuration Management
 Source Code Managers are tools that:
– Archive your deve...
Why You Want A Source Control
System
 Supports concurrent development
 Manage diverging source code bases
 Records file...
Source Code Management Tools Are
Not
 A substitute for project management
 A replacement for developer communication
How They Work
 Central database of source code, documentation, build
tools
 Each file stored only once - all other versi...
What should be in the database
 Source Code
 Documentation
 Build Tools
– Often need old versions of the tools to build...
Version Control
 Companies ship several products from the same source
base (i.e. Win NT and Windows 2000 versions of MS
O...
Code Sharing
 Multiple people can work on the same source base without
colliding
– (1) Locks individual files so only one...
Locking
 Only one person can work on a file at once
 Works fairly well if developers work on different areas of
the proj...
Merging
 Several people can work on a file at once
 Before committing changes, each user merges their copy
with the late...
Labeling
 Label all the files in the source base that make up a
product at each milestone
 Just before and just after a ...
Version Trees
 Each file in the database has a version tree
 Can branch off the version tree to allow separate
developme...
Branching
 When a new version ships, typically create a branch in the
version tree for maintenance
 Double update: fix a...
Examples
 RCS
– Solaris: man rcsintro
 CVS
– Solaris: man cvs
– www.cyclic.com/cvs/info.html
 Visual SourceSafe
– msdn....
RCS
 File management only
 Transaction model
– check out and lock
– edit
– check in and unlock
 Little support for bina...
CVS
 Built on top of RCS
– Therefore little support for binaries
 Database can be remote
 No locking: merge before comm...
SourceSafe
 Microsoft’s entry into the field
 Project-based
 Checkout-edit-checkin model
 Built-in web site creation t...
Clearcase
 Clearcase is configuration management on steroids
 You create a view of the database with a config spec,
whic...
Clearcase Features
 Distributed System
– Several groups at different locations can work on the same
database
 Can instal...
More Clearcase Features
 Integrates with MSDEV
 Build Management
– Knows to rebuild out-of-date files even if your makef...
Helpful Rules for Version Control Bliss
 Archived Files Should Always Compile
 Code Review Files Before Check-in
 Compi...
Software Engineering

Lecture 10
Formal Specification
Formal Specification

Why?
• Precise standard to define and validate software
Why not?
• May be time consuming
• Methods n...
Formal Specification
Ben Potter, Jane Sinclair, David Till,
An Introduction to Formal Specification and Z
(Prentice Hall) ...
Mathematical Specification
Example of specification
B1, B2, ... Bk is a sequence of m x m matrices

η1, η2, ... ηk is a se...
Specification of Programming Languages
<unsigned number> ::= <unsigned integer> | <unsigned real>
<unsigned integer> ::= <...
Formal Specification Using Diagrams
unsigned integer
digit

unsigned number
unsigned integer

+
.

digit

unsigned integer...
Two Rules

• Formal specification does not guarantee correctness
• Formal specification does not prescribe the implementat...
Example: Z Specification Language
Informal: The function intrt(a) returns the largest integer
whose square is less than or...
Example: Algorithm
1 + 3 + 5 + ... (2n - 1) = n2
Example: Program
int intrt (int a)
/* Calculate integer square root */
{
int i, term, sum;
term = 1; sum = 1;
for (i = 0; ...
Finite State Machine

A broadly used method of formal specification:
• Event driven systems (e.g., games)
• User interface...
Finite State Machine

Example:
Therapy control console
[informal description]
State Transition Diagram
Select field
Enter
Patients

Enter
Fields

Start

(ok)
Setup

Beam
on

Ready
Stop

(interlock)
Se...
State Transition Table
Select Select
Enter
Patient Field
Patients
Fields Patients
Setup Patients Fields
Ready Patients Fie...
Z Specification
STATE ::= patients | fields | setup | ready | beam_on
EVENT ::= select_patient | select_field | enter | st...
Z Specification (continued)
control = no_change

transitions

no_change = { s : STATE; e : EVENT • (s, e)
transitions = { ...
Schemas

Schema:
• The basic unit of formal specification.
• Describes admissible states and operations of a
system.
LibSys: An Example of Z
Library system:
• Stock of books
• Registered users.
• Each copy of a book has a unique identifier...
LibSys: Operations
• Issue a copy of a book to a reader.
• Reader return a book.
• Add a copy to the stock.
• Remove a cop...
LibSys

Level of Detail:
Assume given sets:
Copy, Book, Reader
Global constant:
maxloans
Schemas Describing Operations

Naming conventions for objects:
Before: plain variables, e.g., r
After: with appended dash,...
Operation: Issue a Book
• Inputs: copy c?, reader r?
• Copy must be shelved initially: c? ∈ shelved
• Reader must be regis...
Domain and Range

X

ran m
y

dom m
x
m:X

Y

Y

dom m = { x ∈ X : ∃ y ∈ Y ∧ x

y}

ran m = { y ∈ Y : ∃ x ∈ X ∧ x

y}
Operation: Issue a Book
Issue
stock, stock' : Copy
issued, issued' : Copy

Book
Reader

shelved, shelved': F Copy
readers,...
Operation: Issue a Book (continued)
Issue
[See previous slide]
shelved ∪ dom issued = dom stock
shelved' ∪ dom issued' = d...
LibSys: Schema for Abstract States
Library
stock : Copy
Book
issued : Copy
Reader
shelved : F Copy
readers: F Reader
shelv...
Schema Inclusion
LibDB
stock : Copy
Book
readers: F Reader
LibLoans
issued : Copy
Reader
shelved : F Copy
∀r : Reader • #(...
Schema Inclusion (continued)
Library
LibDB
LibLoans
dom stock = shelved ∪ dom issued
ran issued ⊆ readers
Schema Decoration
Issue
Library
Library'
c? : Copy; r? : Reader
c? ∈ shelved; r? ∈ readers
#(issued  {r?}) < maxloans
iss...
Schema Decoration
Issue
∆Library
c? : Copy; r? : Reader
c? ∈ shelved; r? ∈ readers
#(issued  {r?}) < maxloans
issued' = i...
The Schema Calculus
Schema inclusion
Schema decoration
Schema disjunction:
^
AddCopy = AddKnownTitle ∨ AddNewTitle
Schema ...
Software Engineering

Lecture 11
Object-Oriented Design I
What is in a Requirements Document?
Example (Web Butler and Web Site Profiler)
• Run web data collection in real time or b...
What is in a Requirements Document?

Remember
• The requirements document specifies the functionality that
you plan to del...
Assignment 2 -- Individual Parts
One approach:
With your document, include a list of who contributed what
part to the Requ...
The Waterfall Model
Requirements
Definition
System and
Software design
Implementation
and Unit Testing
Integration and
Sys...
Useful Texts

Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified
Modeling Language. Addison-Wesley 1999.
Grady Booch,...
The Importance of Modeling
• A model is a simplification of reality.
• We build models so that we can better understand th...
Principles of Modeling
• The choice of what models to create has a profound
influence on how a problem is attacked and how...
The Unified Modeling Language
UML is a standard language for modeling software systems.
• Serves as a bridge between the r...
Notation: Classes
Window
origin
size
open()
close()
move()
display()

name
attributes

operations

A class is a descriptio...
Notation: Interface

ISpelling
An interface is a collection of operations that specify a
service of a class or component, ...
Notation: Collaboration & Use Case

Chain of
responsibility
A collaboration defines an interaction, i.e., a society of
rol...
Notation: Active Class
EventManager
eventlist
suspend()
flush()
An active class is a class whose objects own one or
more p...
Notation: Component & Node
orderform.java

A component is a physical and replaceable
part of a system that conforms to and...
Notation: Behavioral Things:
Messages & States
display
An interaction is a behavior that comprises a set of messages
excha...
Notation: Grouping and Annotation

Business rules
A package is a general-purpose mechanism for organizing
elements into gr...
Notation: Relationships

A dependency is a semantic relationship between two things in
which a change to one may effect th...
Notation: Relationships (continued)
child

parent

A generalization is a specialization/generalization
relationship is whi...
Diagrams in UML
A diagram is the graphical representation of a set of
elements, usually rendered as a connected graph of v...
Diagrams in UML (continued)

• Interaction diagram shows an interaction, consisting
of a set of objects and the relationsh...
Diagrams in UML (continued)

• Statechart diagram shows a state machine consisting
of states, transitions, events, and act...
The HelloWorld Example
class
name

HelloWorld

operations paint()
Abstraction for HelloWorld
class
name

HelloWorld

operations paint()

annotation
g.drawString
("HelloWorld", 0, 10)"
The "Hello, World" Example

import java.awt.Graphics;
class HelloWorld extends java.applet.Applet {
public void paint (Gra...
Class Diagram

Applet
generalization

Note that the Applet
and Graphics classes
are shown elided.

HelloWorld

paint()

de...
Class Inheritance Diagram
Object
Panel

interface
Component
ImageObserver

Applet
Container
HelloWorld
Packaging Classes

java
HelloWorld

applet

Graphics

awt

lang

package
Notation for Classes and Objects
Classes
AnyClass
attribute1
attribute2
operation1()
operation2()
or
AnyClass

Objects
anO...
Software Engineering

Lecture 12
Object-Oriented Design II
Requirements: the Long Term
Believe that your software will be in use 5 years from now.
• What happens at end of semester?...
Requirements, Design and Implementation
Remember the definitions.
Example: Consistency between two players of a board game...
Modeling Classes
Given a real-life system, how do you decide what classes to
use?
• What terms do the users and implemente...
Noun Identification: A Library Example
The library contains books and journals. It may have
several copies of a given book...
Noun Identification: A Library Example
The library contains books and journals. It may have
several copies of a given book...
Candidate Classes
Library
Book
Journal
Copy
ShortTermLoan
LibraryMember
Week
MemberOfLibrary
Item
Time
MemberOfStaff
Syste...
Relations between Classes
Book
Journal
Copy
LibraryMember
Item
MemberOfStaff
Is Item needed?

is an
is an
is a copy of a

...
Operations
LibraryMember

borrows

Copy

LibraryMember

returns

Copy

MemberOfStaff

borrows

Journal

MemberOfStaff

ret...
Class Diagram
MemberOfStaff

LibraryMember

1

1
on loan

on loan
0..12
Journal

0..*
Copy

is a copy of
1..*

1

Book
Rough Sketch: Wholesale System
A wholesale merchant supplies retail stores from
stocks of goods in a warehouse.
What class...
Rough Sketch: Wholesale System

RetailStore
Order
Merchant
Product
Warehouse
Invoice

Shipment
Rough Sketch: Wholesale System
RetailStore
name
address
contactInfo
financialInfo

Merchant
Warehouse
Order
Product
Revers...
Expanding a Class:
Modeling Financial Information
RetailStore

association
1
* Transaction

Which class is
responsible for...
Modeling Invoice
Shipment

???

RetailStore
invoiceRecord

goodsShipped

Invoice
invoiceNumber

adornments
+goodsShipped()...
Lessons Learned

Design is empirical. There is no single correct design.
During the design process:
• Eliding: Elements ar...
Levels of Abstraction

The complexity of a model depends on its level of abstraction:
• High-levels of abstraction show th...
Component Diagram

hello.hml

executable
component
HelloWorld.class

hello.jpg

hello.java
Actor and Use Case Diagram

BookBorrower

Borrow book

• An actor is a user of a system in a
particular role.
An actor can...
Use Cases and Actors
• A scenario is an instance of a use case
• Actor is role, not an individual
(e.g., librarian can hav...
Use Cases for Borrowing Books

Borrow copy
of book
BookBorrower

Extend
loan

Return copy
of book
Reserve
book
Relationships Between Use Cases:
<<uses>>

Extend
loan
BookBorrower

Borrow copy
of book

<<uses>>

<<uses>>

Check for
re...
Relationships Between Use Cases:
<<extends>>

BookBorrower

<<extends>>
Borrow copy
of book

Refuse
loan
Use Cases in the Development Cycle
• Use cases are a tool in requirements analysis
• Intuitive -- easy to discuss with cli...
Software Engineering

Lecture 13
Object-Oriented Design III
Comments on Presentations
Presentation
• Standard of graphics has been high
• Some text too small (diagrams, screen dumps)...
Modeling Dynamic Aspects of Systems

Interaction diagrams: set of objects and their relationships
including messages that ...
Bouncing Ball Diagrams
Example: http://www.cs.cornell.edu/
domain
name
TCP
connection
HTTP get

Client

Servers
Actions on Objects
call

returnCopy(c)
okToBorrow()

return
send
create
destroy

local

status
notifyReturn(b)

asynchrono...
Links
LibraryMember

1

on loan

0..*

Copy

association
+borrowCopy()
+returnCopy()
class
libMem:LibraryMember
object

me...
Sequence Diagram: Change in Cornell
Program
:MEngStudent
Cornellian
1 : getName()
1.1 : name
2: new PhDStudent(name)

:PhD...
Sequence Diagram: Borrow copy of a
Book
libMem:
LibraryMember
BookBorrower

theBook:Book
theCopy:Copy

borrow(theCopy)
okT...
Class Inheritance Diagram
Object
Panel

interface
Component
ImageObserver

Applet
Container
HelloWorld
Sequence Diagram:Painting Mechanism

:Thread
run

:Toolkit
run

:ComponentPeer

callbackLoop

handleExpose
paint

target:H...
Activity Diagram: Process Modeling
Release work
order
branch
[materials not ready]
[materials ready]
Assign tasks

Resched...
Activity Diagram: Parallel Activities
start state
Decompress
fork
Stream video
join
stop state

Stream audio
State Diagram
returned()

not
borrowable

returned()
borrowable
borrowed()[last copy]

guard expression

borrowed()[not la...
Implementation Modeling
Subsystem
A grouping of elements that specifies what a part of a system
should do.
Component (UML ...
Component Diagram

hello.hml

executable
component
HelloWorld.class

hello.jpg

hello.java
Components and Classes

agent.dll

AgentAction

PatternSearch
Policy
Components and Classes

agent.dll
Realizes
AgentAction
PatternSearch
Policy
extended component
Components and Classes

Classes represent logical abstractions. Components represent
physical things.
Components may live ...
Interfaces

render.java

simulation.exe
IRender
dependency

realization
interface
Application Programming Interface
(API)
API is an interface that is realized by one or more components.
simulation.exe
IRe...
Components and Replaceability

Components allow system to be assembled from binary
replaceable elements.
• A component is ...
Software Engineering

Lecture 14
System Architecture I
Data Intensive Systems
System Architecture

The overall design of a system:
•
•
•
•
•
•

Computers and networks (e.g., monolithic, distributed)
I...
Data Intensive Systems

Examples
• Electricity utility customer billing
• Telephone company call recording and billing
• C...
Example 1: Electricity Utility Billing
First attempt:

Transaction

Data input

Master file

Each transaction handled as i...
Criticisms of First Attempt
Where is this first attempt weak?

The requirements have not been specified!!!
Transaction Types
•
•
•
•
•
•
•
•

Create account / close account
Meter reading
Payment received
Other credits / debits
Ch...
Typical Requirements

• All payments to be credited on day received
• Customers must be able to query account by telephone...
Batch Processing: Validation

errors
Edit &
validation

Incoming
transactions
Data input

read only

Master file

Validate...
Batch Processing: Master File Update

Validated
transactions
in batches

errors

Reports

Sort by
account
Master file
upda...
Benefits of Batch Updating

• All transactions for an account are processed together
• Backup and recovery have fixed chec...
Online Inquiry
Customer
service
read only

Transactions

Data input

Master file

Bills
Example 2: A Small-town Stockbroker

• Transactions
Received by mail or over telephone
For immediate or later action
• Com...
A Database Architecture

Database(s):
• Customer and account database
• Financial products (e.g., account types, pension p...
Database Architecture

Products &
services database

Customer &
account database

External
services
Real-time Transaction
Real-time
transactions

Products &
services database

Customer &
account database

External
services
Real-time Transactions & Batch
Processing
Real-time
transactions

Products &
services database

Data
input

Batch
processi...
Architectural considerations
• Real-time service during scheduled hours + batch
processing overnight
• Combine information...
Example: Merger of Two Banks

Each bank has a database with its customer accounts. The
databases are used by staff at many...
Merger of Two Banks: Options

A

???

???

B
Merger of Two Banks: Architectural
Options
I. Convert everything to System A.
convert databases
retrain staff
enhance Syst...
Distributed Computing: General
Problem
An application that is running on one computer wishes to
use data or services provi...
Network Choices
Public Internet:
Ubiquitous -- worldwide
Low cost
Private network:
Security
Predictable performance
Choice...
Quality of Network Services

Performance
Maximum throughput
Variations in throughput
Real-time media (e.g., audio)
Busines...
Firewall
Public
network

Private
network
Firewall

A firewall is a computer at the junction of two network
segments that:
...
Software Engineering

Lecture 15
System Architecture II
Distributed and Real Time Systems
Comments on Requirements Report

Audience
•
•

Client and design team
Will be updated over time

Content
•
•
•

Level of d...
Sequence Diagram: Notation
libMem:
LibraryMember
BookBorrower

theBook:Book
theCopy:Copy

borrow(theCopy)
okToBorrow
borro...
Sequence Diagram: Branching
libMem:
LibraryMember

theCopy:Copy

BookBorrower
1:borrow(theCopy)

[not ok]3:noborrow

branc...
Example: Distributed Database

two copies of the
same data
Distributed Data and Replication
Distributed Data
Data is held on several computer systems. A transaction may need
to asse...
Example: Broadcast Search

User

User interface
server

Databases
Example: UseNet
Stateless Protocol v. Stateful

Stateless protocol
Example: http
Open connection
Send message
Return reply
Close connectio...
Stateless Protocol v. Stateful
Stateful (session) protocol
Example: Z39.50
Open connection
Begin session
Interactive sessi...
Firewall
Public
network

Private
network
Firewall

A firewall is a computer at the junction of two network
segments that:
...
The Domain Name System
First attempt to resolve
www.cs.cornell.edu

.edu
server

1
2
3

cornell.edu
server
cs.cornell.edu
...
Discussion of the First Attempt
Problems?
The Domain Name System
Better method

local DNS
server
1

almaden.ibm.com
cornell.edu
Local ece.cmu.edu
cache ibm.com
acm....
Real Time System

A real time system is a software system whose correct
functioning depends upon the results produced and
...
Example: Web Server

http message
daemon
TCP port 80

spawned processes

The daemon listens at port 80.
When a message arr...
Embedded Systems

Software and hardware are combined to provide an
integrated unit, usually dedicated to a specific task:
...
Example: Autonomous Land Vehicle

GPS
Steer
Sonar
Model
Laser

Control
signals

Throttle
Controls

Sensors

Signal
process...
Other Applications
Response critical
•

Network router

•

Telephone switch

•

Seat bag controller

Shared systems
•

Mul...
Techniques

•

Special purpose hardware

•

Multi-threading and multi-tasking

•

Parallel processing
=> digital signal pr...
Multi-Threading

Several similar threads operating concurrently:
• Re-entrant code -- separation of pure code from
data fo...
Real Time Executive

Schedules and dispatches tasks in a real time system
•

Real time clock

•

Interrupt handler

•

Sch...
Timing
Timing mechanisms
•

Synchronous (clocked) -- periodic stimuli

•

Asynchronous -- wait for next signal

Example: C...
Hardware v. Software

Design of embedded systems requires close
understanding of hardware characteristics
• Special purpos...
Example: Dartmouth Time Shared
System
master
processor
Communications
processor
Communications
processor

I/O
Mulitplexor
...
Software Considerations
Resource considerations may dictate software design and
implementation:
• Low level language (e.g....
Example: CD Controller

4
Input
block
7

3
2

5
6

Circular buffer

1
Output
block
Continuous Operation

Many systems must operate continuously
•

Software update while operating

•

Hardware monitoring an...
Routers and Other Network Computing

•

Interoperation with third party devices

•

Support for several versions of protoc...
Software Engineering

Lecture 15
System Architecture II
Distributed and Real Time Systems
Administration

Assignment 2: Requirements
•
•
•

Grades -- presentation, report, individual
Comments at presentation
Comm...
Comments on Requirements Report

Audience
•
•

Client and design team
Will be updated over time

Content
•
•
•

Level of d...
Sequence Diagram: Notation
libMem:
LibraryMember
BookBorrower

theBook:Book
theCopy:Copy

borrow(theCopy)
okToBorrow
borro...
Sequence Diagram: Branching
libMem:
LibraryMember

theCopy:Copy

BookBorrower
1:borrow(theCopy)

[not ok]3:noborrow

branc...
Example: Distributed Database

two copies of the
same data
Distributed Data and Replication
Distributed Data
Data is held on several computer systems. A transaction may need
to asse...
Example: Broadcast Search

User

User interface
server

Databases
Example: UseNet
Stateless Protocol v. Stateful

Stateless protocol
Example: http
Open connection
Send message
Return reply
Close connectio...
Stateless Protocol v. Stateful
Stateful (session) protocol
Example: Z39.50
Open connection
Begin session
Interactive sessi...
Firewall
Public
network

Private
network
Firewall

A firewall is a computer at the junction of two network
segments that:
...
The Domain Name System
First attempt to resolve
www.cs.cornell.edu

.edu
server

1
2
3

cornell.edu
server
cs.cornell.edu
...
Discussion of the First Attempt
Problems?
The Domain Name System
Better method

local DNS
server
1

almaden.ibm.com
cornell.edu
Local ece.cmu.edu
cache ibm.com
acm....
Real Time System

A real time system is a software system whose correct
functioning depends upon the results produced and
...
Example: Web Server

http message
daemon
TCP port 80

spawned processes

The daemon listens at port 80.
When a message arr...
Embedded Systems

Software and hardware are combined to provide an
integrated unit, usually dedicated to a specific task:
...
Example: Autonomous Land Vehicle

GPS
Steer
Sonar
Model
Laser

Control
signals

Throttle
Controls

Sensors

Signal
process...
Other Applications
Response critical
•

Network router

•

Telephone switch

•

Seat bag controller

Shared systems
•

Mul...
Techniques

•

Special purpose hardware

•

Multi-threading and multi-tasking

•

Parallel processing
=> digital signal pr...
Multi-Threading

Several similar threads operating concurrently:
• Re-entrant code -- separation of pure code from
data fo...
Real Time Executive

Schedules and dispatches tasks in a real time system
•

Real time clock

•

Interrupt handler

•

Sch...
Timing
Timing mechanisms
•

Synchronous (clocked) -- periodic stimuli

•

Asynchronous -- wait for next signal

Example: C...
Hardware v. Software

Design of embedded systems requires close
understanding of hardware characteristics
• Special purpos...
Example: Dartmouth Time Shared
System
master
processor
Communications
processor
Communications
processor

I/O
Mulitplexor
...
Software Considerations
Resource considerations may dictate software design and
implementation:
• Low level language (e.g....
Example: CD Controller

4
Input
block
7

3
2

5
6

Circular buffer

1
Output
block
Continuous Operation

Many systems must operate continuously
•

Software update while operating

•

Hardware monitoring an...
Routers and Other Network Computing

•

Interoperation with third party devices

•

Support for several versions of protoc...
Software Engineering

Lecture 16
System Architecture III
Distributed Objects
Real-Time: Software Considerations
Resource considerations may dictate software design and
implementation:
• Low level lan...
Buffering Example: CD Controller

4
Input
block
7

3
2

5
6

Circular buffer

1
Output
block
Continuous Operation

Many systems must operate continuously
•

Software update while operating

•

Hardware monitoring an...
Example: Routers and Other Network
Computing
•

Interoperation with third party devices

•

Support for several versions o...
Example: Transaction Monitor

messages

Transaction
monitor

processes

A transaction monitor: monitors transactions, rout...
Software Reuse: Application Packages

• Package supports a standard application (e.g., payroll, user
interface to Internet...
Reuse: Object Object Oriented
Languages
Example:
Java is a relatively straightforward language with a very rich set
of cla...
Reuse: Objects - Basic Definitions

• An object is a piece of code that owns attributes and
provides services through meth...
Reuse: Objects - Characteristics
• Encapsulation. An object has a public interface
that defines how other objects or appli...
Reuse: Objects - Object Binding
Binding is the linking of the software interface between two
objects.
• Static binding: Th...
Reuse: Objects - Distributed Objects

Objects on separate computers interact through method calls
and instance data.
Major...
Desirable Properties of Distributed
Objects
• Different languages and operating environments
• Reusable code: components
•...
Example: Fedora IDL

A research project to explore extensibility:
-- very simple Interface Definition Language
-- powerful...
Object Request Broker (ORB)

C

C++

Cobol Objects

IDL

IDL

IDL Interface IDL

Java

Client

Other
IDL

Server

Object R...
Interface Definition Language
module <identifier>
{
<type declarations>;
<constant declarations>;
<exception declarations>...
Interface Definition Language
(continued)
interface <identifier> [:<inheritance>]
{
<type declarations>;
<constant declara...
ORB: Programmer's View
Client
Invoke a
on
object X

Server
Invoke a
on
object Y

Object X

Object Y

a

a

Object Request ...
Object Request Broker (ORB)
An ORB lets objects make requests to and receive response
from other objects located locally o...
ORB: System View

Interface
repository

Client

Dynamic Client IDL ORB
invocation stubs
interface

Object
Implementation
i...
CORBA Services
•
•
•
•
•
•
•
•
•
•
•
•
•

Naming service
Event service
Concurrency control service
Transaction service
Rel...
Distributed Objects and the System
Life-Cycle
All large systems change with time.
• Dynamic binding of objects combined wi...
Software Engineering

Lecture 17
Design for Usability I
Q2: Finite State Machine
The cruise control system on an automobile is controlled by a
master switch and three buttons. In...
State Transition Diagram
A

C

MS-On
Off

Standby

A

A
Engaged

C
B-Brake

MS-Off

Standby1
State Transition Table
MS
on

MS
off

A

Standby

Off

Engaged

Engaged

Off

Engaged Standby1 Engaged

Standby1

Off

Eng...
Question 4
When software is written, who owns the copyright?

How can somebody else be permitted to use the software?

How...
Question 4
When software is written, who owns the copyright?
The person who writes the software
Except work for hire -- th...
Question 4
You are employed for company X writing software.
When you leave, who owns your work?

What use can you make of ...
Question 4
You are employed for company X writing software.
When you leave, who owns your work?
The company (work for hire...
Question 4
You work free-lance for company X.
When you finish, who owns your work?

What use can you make of the work?
Question 4
You work free-lance for company X.
When you finish, who owns your work?
It depends on the circumstances
Have a ...
Distributed Objects and the System LifeCycle
All large systems change with time.
• Dynamic binding of objects combined wit...
Design for Usability
Usability of a computer system is a combination of factors:
• User interface design
• Functionality
•...
Iterative Design
Evaluation

Requirements

Implementation
(prototype)

Design
Methods for Evaluation of Usability
• Observing users (user protocols)
• Focus groups
• Measurements
effectiveness in carr...
Levels of Usability

interface design
conceptual
model

functional design
data and metadata
computer systems and networks
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Upcoming SlideShare
Loading in...5
×

Cnpm bkdn

1,811

Published on

Published in: Education, Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,811
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Cnpm bkdn

  1. 1. Software Engineering Lecture 1 Introduction to Software Engineering
  2. 2. Code of Conduct  Software Engineering is a collaborative activity. You are encouraged to work together, but ...  Some tasks may require individual work.  Always give credit to your sources and collaborators. Good professional practice: To make use of the expertise of others and to build on previous work, with proper attribution. Unethical and academic plagiarism: To use the efforts of others without attribution.
  3. 3. Projects  Project teams, about 3 to 5 peoples.  Select your own project, any branch of software engineering  Real project for real client who intends to use the software in production.  Feasibility study and plan: during semester  Presentations: • requirements • design • final
  4. 4. Project Selection  Some suggested projects  Recitation section to suggest projects Contact potential clients:  Gain idea of their expectations  Estimate scope and complexity of the project  Discuss business decisions Assemble project team  Advertise on the web site
  5. 5. Previous Experience Your background       Biggest program that you have written? Biggest program that you have worked on? Biggest project team that you have been part of? Longest project that you have worked on? Most people who have used your work? Longest that your project has been in production? My background
  6. 6. Course Themes 1. Leadership of large software projects  Software as a product Clients and their needs Quality  Requirements and specification Usability Evolution  Project management Personnel management Economic, legal, and social factors
  7. 7. Course Themes 2. Large and very large systems  Software design Software architecture Object-oriented design  Dependable systems Reliability Verification  Legacy systems
  8. 8. Characteristics of Software Products General characteristics Usability Maintainability Dependability Efficiency Good software products require good programming, but ... Programming quality is the means to the end, not the end itself.
  9. 9. Software as a Product Software is expensive!! Every software project has a trade-off between: Functionality Resources (cost) Timeliness Example: Accounting Management System
  10. 10. Client (a.k.a Customer)  The client provides resources and expects some product in return.  Client satisfaction is the primary measurement of success. Question: Who is the client for Microsoft Excel?
  11. 11. Variety of Software Products Examples? -Operation System -Database Management System -Embedded System -Games -Application Software -…
  12. 12. Categories of Product Categories of client and software product:  Generic (e.g., Microsoft Excel)  Bespoke (customized) (e.g., IRS internal system) Many systems are customized versions of generic packages (e.g., Cornell's payroll system)
  13. 13. Variety of Software Products Software products are very varied --> Client requirements are very different --> There is no standard process for software engineering --> There is no best language, operating system, platform, database system, development environment, etc. A skilled software developer knows about a wide variety of approaches, methods, tools. The craft of software engineering is to select appropriate methods for each project and apply them effectively.
  14. 14. Professional Responsibility Organizations put trust in software developers:  Competence: Software that does not work effectively can destroy an organization.  Confidentiality: Software developers and systems administrators may have access to highly confidential information (e.g., trade secrets, personal data).  Legal environment: Software exists in a complex legal environment (e.g., intellectual property, obscenity).  Acceptable use and misuse: Computer abuse can paralyze an organization (e.g., the Internet worm).
  15. 15. Software Engineering Lecture 2 The Software Process
  16. 16. Books  Frederick P. Brooks, Jr. The Mythical Man Month. Addison-Wesley, 1972.  Ian Sommerville, Software Engineering, 6th edition. Addison-Wesley, 2000.  Grady Booch, James Rumbach, Ivar Jacobson, The Unified Modeling Language. Addison-Wesley 1999.
  17. 17. Software Process Fundamental Assumption: Good processes lead to good software Good processes reduce risk
  18. 18. Risk Management What can go wrong in a software project? How can the risk be reduced?
  19. 19. The Software Process (Simplified) Feasibility and Planning Requirements Design Implementation Operation and Maintenance
  20. 20. The Waterfall Model Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance
  21. 21. Requirements Analysis and Definition The system's services, constraints and goals are established by consultation with system users. They are then defined in a manner that is understandable by both users and development staff. This phase can be divided into:     Feasibility study (often carried out separately) Requirements analysis Requirements definition Requirements specification
  22. 22. System and Software Design System design: Partition the requirements to hardware or software systems. Establishes an overall system architecture Software design: Represent the software system functions in a form that can be transformed into one or more executable programs  Unified Modeling Language (UML)
  23. 23. Programming and Unit Testing The software design is realized as a set of programs or program units. (Written specifically, acquired from elsewhere, or modified.) Individual components are tested against specifications.
  24. 24. Integration and System Testing The individual program units are:  integrated and tested as a complete system  tested against the requirements as specified  delivered to the client
  25. 25. Operation and Maintenance  Operation: The system is put into practical use.  Maintenance: Errors and problems are identified and fixed.  Evolution: The system evolves over time as requirements change, to add new functions or adapt the technical environment.  Phase out: The system is withdrawn from service.
  26. 26. Discussion of the Waterfall Model Advantages:     Process visibility Dependence on individuals Quality control Cost control Disadvantages: Each stage in the process reveals new understanding of the previous stages, that requires the earlier stages to be revised.
  27. 27. Feedback in the Waterfall Model Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance
  28. 28. Iterative Refinement (Evolutionary Development) Concept: Initial implementation for user comment, followed by refinement until system is complete.  Vaporware: user interface mock-up  Throw-away software components  Dummy modules  Rapid prototyping  Successive refinement
  29. 29. Iterative Refinement Evaluation Requirements Implementation (prototype) Design
  30. 30. Iterative Refinement Concurrent Activities Requirements Outline Description Design Implementation Initial Version Intermediate Versions Final Version
  31. 31. Iterative Refinement & Software Process Concurrent Activities Outline Description Requirements Design Implementation Final Version
  32. 32. Iterative Refinement When is iterative refinement appropriate?
  33. 33. Iterative Refinement + Waterfall Model: Graphics for Basic Outline Description: Add vector graphics to Dartmouth Basic. Phase 1: Extend current language with a preprocessor and run-time support package. (1976/77) Phase 2: Write new compiler and run-time system incorporating graphics elements. (1978/80)
  34. 34. Iterative Refinement + Waterfall Model: Graphics for Basic Design Issues:  Pictorial subprograms: coordinate systems, window/viewport  User specification of perspective Design Strategy: (Iterative Refinement)  Write a series of prototypes with various proposed semantics  Evaluate with a set of programming tasks
  35. 35. Iterative Refinement + Waterfall Model: Graphics for Basic Phase 1: Implementation (Waterfall)  When the final specification was agreed, the entire preprocessor and run-time support were recoded.  The system was almost entirely bug-free. Phase 2: New compiler (Waterfall) Phase 1 was used as the requirements definition for the final version.
  36. 36. Observations about Software Processes Completed projects should look like the Waterfall Model but ... the development process is always partly evolutionary. Risk is lowered by:  Prototyping key components  Dividing into phases  Following a visible software process  Making use of reusable components
  37. 37. Software Engineering Lecture 3 (a) Feasibility Study (b) Requirements Definition
  38. 38. Feasibility Study Before beginning a project, a short, low-cost study to identify • Client • Scope • Potential benefits • Resources needed: staff, time, equipment, etc. • Potential obstacles Where are the risks? How can they be minimized?
  39. 39. Feasibility Study A feasibility study leads to a decision: go ahead do not go ahead think again In production projects, the feasibility study often leads to a budget request. In research, a feasibility study is often in the form of a proposal.
  40. 40. CS 501: Client In CS 501, you have two clients: • The client for the project • The professor for the course Can you satisfy them both?
  41. 41. Scope What are the boundaries of the project? CS 501 Examples: • Static web pages with open access on the Web [Web Profiler] • Used by the general public [Digital Collections] • Varying data formats [Legal Information] • Thousands of sensors [Data mining] • Support for Windows, Mac, Unix [SALSA]
  42. 42. Potential Benefits Why are you doing this project? Examples • Create a marketable product • Improve the efficiency of an organization • Control a system that is too complex to control manually • New or improved service • Safety or security • Get a good grade on CS 501
  43. 43. Resources Examples: CS 501 Staff: 5 to 7 students, with some help. How many hours per week? What skills do people have? Time: Must be completed by end of semester, including operational system, documentation, presentation Equipment and software: What special needs are there? Client: Will the client be sufficiently available and helpful?
  44. 44. Obstacles CS 501 projects Start-up time. Creating a team, scheduling meetings, acquiring software, learning new systems, ... Business considerations. Licenses, trade-secrets, ... Too ambitious. Nothing to show at the end of the semester. Changing circumstances. Client leaves the university, ... What else?
  45. 45. How to Minimize Risk? CS 501 Projects • Several target levels of functionality: required, desirable, optional • Visible software process: intermediate deliverables • Good communication within team and with Teaching Assistant Good processes lead to good software Good processes reduce risk
  46. 46. Feasibility Report A written document • For a general audience: client, financial management, technical management, etc. • Short enough that everybody reads it • Long enough that no important topics are skipped In CS 501, I am looking for a well written, well presented document.
  47. 47. Requirements Definition and Analysis Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance
  48. 48. Example: Library of Congress (A Partial Failure) Outline Description The Library of Congress requires a repository system to store and make accessible very large amounts of highly varied material over long periods of time.
  49. 49. Chronology 1993-94 CNRI carries out research on architectures for digital libraries 1995-97 CNRI implements prototype repository for Library of Congress 1998 CNRI and Library of Congress carry out requirements definition
  50. 50. The Repository Repository Users Identification System Search System
  51. 51. Storage and Representation of Complex Objects Data Several representations: thumbnail image reference image archival image Metadata Each representation may have its own metadata
  52. 52. Repository: Research Achievements 1. CORBA implementation of repository access protocol. 2. Integration of persistent naming through handle system. 3. Use of structural metadata to describe complex objects, elementary typology. 4. Access management framework and implementation. 5. Applet-based middleware for user interfaces. 6. Information visualization program to view the structure of large collections.
  53. 53. Good Discoveries During Prototype • Structuring complex information in digital libraries • Data driven digital library interfaces • Comparison of object-oriented, relational, and file based storage systems • Naming and identification of library objects • Boundaries of required repository system
  54. 54. Bad Discoveries During Prototype • Resistance to change within Library of Congress • Technical weakness of Library of Congress • Gaps in CNRI architecture
  55. 55. Mistakes • Confusion of objectives (research and implementation) • Failure to involve all stakeholders • Over-ambitious (no proper feasibility study)
  56. 56. The Requirements Process Feasibility Study Feasibility Report Requirements Analysis Requirements Definition System Models Requirements Specification Definition of Requirements Requirements Document Specification of Requirements
  57. 57. Requirements Definition High-level abstract description of requirements: • Specifies external system behavior • Comprehensible by customer, management and users Should reflect accurately what the customer wants: • Services that the system will provide • Constraints under which it will operate
  58. 58. Library of Congress Requirements Study Team (all experienced): Librarian, Software Engineer (CNRI), Computing Project Leader (Library of Congress), + 2 others Advisors: Mailing list of about 20 knowledgeable stakeholders. Timetable: Preliminary report (2 months). Final report (1 month).
  59. 59. Functional Requirements Example: Library of Congress repository • Support for complex digital objects • Access management • Identification • Information hiding • Open protocols and formats • Integration with other systems (scope)
  60. 60. DRAFT OVERVIEW OF ITS SUPPORT FOR NDLP PRODUCTION AND DELIVERY OF AMERICAN MEMORY NDLP collections already released Coolidge collection (for repository test) NDLP collections in conversion Future NDLP collections Other applications and materials NDLP Workflow Tracking Support Current Storage Structure (in Unix files, by aggregate) Object Administration System ILS Repository Index Generation (including pre-processing) American Memory User Interface (retrieval, navigation, & display) AM user interface plus access management for objects/collections Other User Interfaces (e.g. RLG, OCLC, DLF partners) ILS OPAC Interface Supporting infrastructure Handle assignment & registration Handle-server NOW Handle resolution FUTURE
  61. 61. Non-functional Requirements Environment: • Estimates of sizes, numbers of users, etc. • Reliability and performance measures and targets Preferred: Example: Library of Congress repository • Hardware and software systems (e.g., IBM/Unix) • Database systems (e.g., Oracle) • Programming languages (e.g., C and C++)
  62. 62. Evolution of Requirements • If the requirements definition is wrong, the system will be a failure. • With complex systems, understanding of requirements always continues to improve. Therefore... • The requirements definition must evolve. • Its documentation must be kept current (but clearly identify versions).
  63. 63. Software Engineering Lecture 4 Management I: Project Management
  64. 64. The Aim of Project Management To complete a project: • On time • On budget • With required functionality • To the satisfaction of the client • Without exhausting the team
  65. 65. The Project Manager • • • • Create and maintain the schedule Should track progress against schedule Keep some slack in the schedule Be continually making adjustments: Start activities before previous activity complete Sub-contract activities Renegotiate deliverables • Keep senior management informed
  66. 66. Project Planning Methods The Critical Path Method, Gantt charts, Activity bar charts, etc. are roughly equivalent. These methods are best when: • Model is updated regularly (e.g., monthly) • The structure of the project is well understood • The time estimates are reliable • Activities do not share resources [Critical Path Method is excellent for large construction projects.]
  67. 67. Example: An Open University Course Deliverables: 16 8 8 4 1 4 Written texts (bound in pairs) Television programs Radio programs Computer programs Home experimental kit (scientific calculator) Assignments and sample solutions
  68. 68. Flexibility Schedule: Dates for broadcasting TV and radio programs are fixed. Printing and mailings can be accelerated if overtime is used. Functionality: The course team can decide what goes into the components of the course. Resources: The size of the course team can be increased slightly.
  69. 69. Scheduling: Critical Path Method An activity A dummy activity An event A milestone
  70. 70. Critical Path Method other activities START Revise Unit 3 Edit Unit 3 Print Unit 3 Mail Unit 3 END
  71. 71. Critical Path Method other activities Revise Unit 3 Edit Unit 3 START other activities Revise Unit 4 Edit Unit 4 Typeset Unit 3 Print Units 3/4 Typeset Unit 4 Mail Units 3/4
  72. 72. Critical Path Method Script TV 2 START Edit Unit 3 Make TV 2 Edit Unit 4 Prototype Computer 1 Document Computer 1 Mail Delivery Program Computer 1
  73. 73. Time Estimates for Activities (Weeks) 4 1 6 3 2 3 1 12 12 1 3 2 4 4 1 3 2 8
  74. 74. Earliest Start Dates 1 1 12 26 4 3 6 15 2 17 3 12 0 12 12 3 2 17 3 19 1 22 1 23 2 4 4 4 1 17 8 25
  75. 75. Latest Start Dates 11 1 12 4 3 6 15 1 2 17 3 12 0 12 14 4 13 3 26 2 17 4 3 20 23 1 24 2 17 1 8 25
  76. 76. Critical Path 1/11 12/12 26/26 15/15 17/17 22/23 0/0 12/14 4/13 17/17 19/20 17/17 23/24 25/25
  77. 77. Slack 1/11 10 12/12 0 0/0 26/26 10 3 15/15 0 0 0 1 22/23 0 2 12/14 2 17/17 9 17/17 4/13 19/20 1 0 9 23/24 25/25 1 1 5 17/17 0
  78. 78. Key Personnel In computing, not all people are equal: • The best are at least 5 times more productive • Some tasks are too difficult for everybody Adding more people adds communications complexity • Some activities need a single mind • Sometimes, the elapsed time for an activity can not be shortened. What happens to the project if a key person is sick or quits?
  79. 79. Key Personnel: Schedule for Editor Earliest Start Date Activity Weeks 15-16 Weeks 17-18 Weeks 19-20 Weeks 21-22 Edit Unit 3 Edit Unit 4 Edit Unit 5 Edit Unit 6 Week 15 Week 17 Week 19 Week 21 Review draft of Unit 7 Review draft of Unit 8 Check proofs of Unit 3 Check proofs of Unit 4 Weeks 18-19 Week 22 Vacation Out sick
  80. 80. Start-up Time On a big project, the start-up time is typically three to six months: • Personnel have to complete previous projects (fatigue) or recruited. • Hardware and software has to be acquired and installed. • Staff have to learn new domain areas and software (slow while learning) • Clients may not be ready.
  81. 81. Experience with Critical Path Method Administrative computing department at Dartmouth used the Critical Path Method for implementation phase of major projects. Experience: Elapsed time to complete projects was consistently 25% to 40% longer than predicted by model. Analysis: • Some tasks not anticipated (incomplete understanding) • Some tasks had to be redone (change of requirements, technical changes) • Key personnel on many activities (schedule conflicts) • System ZZZ (non-billable hours)
  82. 82. CS 501: Software Engineering Lecture 5 (a) Documentation (b) Requirements Analysis
  83. 83. Assignments September 13 October 4 October 16 November 8 Nov 29 - Dec 1 Exam week Feasibility and plan Requirements Midterm exam Design Project presentations Final examination Details are subject to change. Group Group/individual Individual Group/individual Group Individual
  84. 84. Assignment 1 Wednesday, September 13: Project plan due -- report. Title of project Client/customer Team members Outline description Current status (e.g., previous work) Plan (e.g., major stages, assignment to tasks, technical environment, schedule, etc.) Any other relevant information
  85. 85. Documentation • Reasons for documentation: visibility (e.g., project plan, interim report) user support (e.g., user manual) team communication (e.g., interface specifications) maintenance and evolution (e.g., requirements) • Characteristics of documentation: accurate and kept current appropriate for audience maintained online (usually) simple but professional in style and appearance Documentation is expensive --> Quality not volume
  86. 86. Form of Documentation External • Printed • Web site Internal • Program documentation • Program context (e.g., copyright notices)
  87. 87. Requirements Definition and Analysis Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance
  88. 88. The Requirements Process Feasibility Study Feasibility Report Requirements Analysis Requirements Definition System Models Requirements Specification Definition of Requirements Requirements Document Specification of Requirements
  89. 89. Requirements Analysis 1. Understand the requirements in depth: • Domain understanding Examples: science research, application… • Stakeholders Example: companies, ministries, Danang City…
  90. 90. Viewpoint Analysis Example: University Admissions System • Applicants • University administration Admissions office Financial aid office Special offices (e.g., athletics, development) • Computing staff Operations Software development and maintenance • Academic departments
  91. 91. Interviews with Clients Clients may have only a vague concept of requirements. • Prepare before you meet with them • Keep full notes • If you don't understand, delve further • Small group meetings are often most effective Clients often confuse the current system with the underlying requirement.
  92. 92. Requirements Analysis 2. Organize the requirements: • Classification into coherent clusters (e.g., legal requirements) • Recognize and resolve conflicts (e.g., functionality v. cost v. timeliness) Example: Dartmouth general ledger system
  93. 93. Requirements Analysis 3. Model the requirements: • Informal Prose • Systematic Procedural models Data-centric models Object models • Formal models
  94. 94. Procedural Models: Flowchart Operation Decision Manual operation Report
  95. 95. Flowchart: University Admissions Form received New? T Database record Notify student F Update database Complete? T F Notify student Evaluate
  96. 96. Procedural Models: Pseudo-code Example: Check project project plan check_plan (report) if report (date_time) > due_date_time then error (too_late) if report (client) = none then error (no_client) if report (team) < min_team or > max_team then error (bad_team) if error() = none then comments = read_report (report) return (comments (text), comments (grade)) else return error()
  97. 97. Data-Flow Models External entities Processing steps Data stores or sources Data flows
  98. 98. Example: University Admissions Rejection Application Completed form Receive application Evaluate application Applicant Offer
  99. 99. Example: University Admissions Assemble Application Stage Acknowledgment Application form Receive Applicant Completed application Acknowledgment AND Initiate evaluation Evaluation request AND Supporting information Pending database Applicant database
  100. 100. Example: University Admissions Process Completed Application Stage Rejection Evaluation request Evaluation Acceptance Special request Applicant database Financial aid Offer
  101. 101. Requirements Analysis v. System Design Dilemma. • Requirements analysis should make minimal assumptions about the system design. • But the requirements definition must be consistent with computing technology and the resources available. In practice, analysis and design are interwoven. However, do not to allow the analysis tools to prejudge the system design.
  102. 102. CS 501: Software Engineering Lecture 6 (a) Requirements Analysis (continued) (b) Requirements Specification
  103. 103. The Requirements Process Feasibility Study Feasibility Report Requirements Analysis Requirements Definition System Models Requirements Specification Definition of Requirements Requirements Document Specification of Requirements
  104. 104. Requirements Analysis Methods for data modeling and design • Data flow diagrams • Entity-relation diagrams • Data dictionaries • Object models Many of these methods blur the distinction between analysis and design.
  105. 105. Entity-Relation Model A Design Methodology for Relational Databases • A database of entities and relations • Tools for displaying and manipulating entityrelation diagrams • Tools for manipulating the database (e.g., as input to database design) Warning: There is much confusion about definitions and notation
  106. 106. Entity-Relation Diagram An entity A relation between entities An entity or relation attribute An inheritance relation
  107. 107. Example: CS 501 Project Major Client 1 Student Project 1 CS501 Student 5 to 7 Member of 0:n Person 0:n 0:n Tech contact
  108. 108. MARC Format for Monographs (Books) 001 245 260 650 650 700 89-16879 r93 Campus strategies for libraries and electronic information {Bedford, Mass.} : Digital Press, c1990. Academic libraries--United States--Automation. Libraries and electronic publishing--United States. Arms, Caroline R. (Caroline Ruth)
  109. 109. Entity-Relation Diagram for MARC Book 0:n 1 0:n Describes 0:n Catalog record Short title 1:n Author of Editor of Is about Control numb 0:n Creator 0:n 0:n Subject heading
  110. 110. Data Dictionaries A data dictionary is a list of names used by the system • Brief definition (e.g., what is "date") • What is it (e.g., number, relation) • Where is it used (e.g., source, used by, etc.) • May be combined with a glossary As the system is implemented, the data dictionary in the requirements is input to the system data dictionary, which is a formal part of the system specification.
  111. 111. A Note on Object Models This course teaches object models as a tool for design. Some people recommend object models for requirements analysis, but it is difficult to use them without constraining the system design.
  112. 112. Non-Functional Requirements Product requirements performance, reliability, portability, etc... Organizational requirements delivery, training, standards, etc... External requirements legal, interoperability, etc...
  113. 113. Examples of Non-Functional Requirements Privacy (Mercury digital library) Functional requirement: Usage data for management of system Non-functional requirement: Usage data must not identify individuals Minimizing records (NeXT) Functional requirement: Retain all required records Non-functional requirement: Discard all other records
  114. 114. Unspoken Requirements Example: Resistance to change at XXX
  115. 115. Requirements Specification What is the purpose of the Requirements Specification?
  116. 116. Requirements Specification: Purpose 1. It describes the requirements to the stakeholders • Expressed in the terms that the stakeholders understand • Comprehensible from many viewpoints • Reviewed by stakeholders so that they understand implications • Must be clear about assumptions (things left out)
  117. 117. Requirements Specification: Purpose 2. It describes the requirements to the implementers • As precise and specific as possible • Expressed in terms that they understand • Comprehensible to new team members
  118. 118. Requirements Specification: Purpose 3. It records the requirements for the future • An essential part of system evolution 4. If may be a contractual document • See you in court!
  119. 119. Requirements Specification: Approaches • Natural language • Structured natural language • Design description language • Requirements specification language • Graphical notation • Formal specification See Sommerville, Chapter 7.
  120. 120. CS 501: Software Engineering Lecture 7 Management II Business and Legal Aspects of Software Engineering
  121. 121. Legal Environment Software is developed in a complex legal and economic framework. Changes in laws follow changes in technical world. Jurisdictions: • • • • • • Vietnamese laws International treaties Federal and state statues Precedents Supreme Court Cost of establishing precedent
  122. 122. Legal Topics • International • Intellectual property (copyright, patent, contract) • Tort (e.g., liability of Internet service provider) • Privacy • Free speech and its limitations (government secrets, obscenity, blasphemy, hate) Legal Information Institute: http://www.law.cornell.edu/
  123. 123. Copyright A copyright gives the owner the exclusive right to: • reproduce • distribute • perform • display • license Gradually extended to cover text, music, photographs, designs, software, ...
  124. 124. Copyright Copyright at creation • • • • • Works for hire Contracts and licenses First sale Fair use Infringement (contamination) International differences • Moral rights • Copyright registration
  125. 125. Software Patents • Should be: non-obvious, novel, useful • 17 years from award (20 years from application) • Poor quality of examining can lead to broad patents for routine computing concepts • International differences Copyright applies to the expression of ideas, patents to the ideas themselves.
  126. 126. Contracts and Licences Contracts allow intellectual property to be sold or licensed • • • • • • • Promise in exchange for adequate consideration Written document with signature Permanent or temporary, whole or part Exclusive or non-exclusive Termination, problems and difficulties Terms and conditions as agreed Enforceable by courts
  127. 127. Derivative Works When software is derived from other software: • New code is owned by new developer • Conditions that apply to old code apply to derived work If you write S, which is derived from A, B, C and D, you can not distribute or licenses S unless you have right to distribute each of A, B, C and D. To create a software product, you must have documented rights to use every component.
  128. 128. Privacy Invasions of privacy: • • • • intrusion appropriation of name or likeness unreasonable publicity false light Be very careful about collecting personal data without the knowledge of the individual
  129. 129. Software Business Questions • You are employed for company X writing software. When you leave, who owns your work? What use can you make of the work? • You work free-lance for company X. When you finish, who owns your work? What use can you make of the work? • Read the contract!
  130. 130. Your Next Job ... • Employment contract may restrict your next job (not working for competitors, etc.) • Trade-secret information (non-disclosure agreement) Ask when you are interviewed!
  131. 131. Trade Secrets and Non-Disclosure Agreements Trade Secret "... information, including a formula, pattern, compilation, program, device, method, technique, or process that derives independent economic value from not being generally known and not being readily ascertainable and is subject to reasonable efforts to maintain secrecy." Uniform Trade Secrets Act Non-Disclosure Agreement Legal agreement not to disclose trade secrets.
  132. 132. Some Business Models • Software developed in-house • Package licensed to customer, binary only (Microsoft model) • Package licensed to customer, source code for customer's modifications • Bespoke software for customer (may be owned by supplier or customer) • Software bundled with hardware product (PalmPilot)
  133. 133. Free-Lance Software Development You and a few friends create a company to develop software. How much should you charge per hour? You plan to work 40 hours a week for 50 weeks of the year and want to earn $50,000. Hourly rate = $50,000 / (40 x 50) = $25 But ...
  134. 134. Free-Lance Software Development Salary Taxes and benefits Rent, equipment, etc. Fees, services, etc. Travel and misc. TOTAL EXPENSE Hours worked less administration less marketing BILLABLE HOURS $50,000 $15,000 $10,000 $15,000 $10,000 $100,000 2,000 400 350 1,250 Hourly rate = $100,000 /1,250 = $80
  135. 135. Fixed and Variable Cost: Packaged Software Example: • The initial development cost of a software product is $10 million. • The cost of packaging and distribution of each copy is $5. • Technical support costs average $15 per copy. • The package sells for $200 per copy. Fixed cost = $10 million Variable cost = $20
  136. 136. Fixed and Variable Costs: Profit or Loss $15M $10M $5M 2,500 5,000 7,500 Unit sales
  137. 137. Community Development • Shareware • Open source (e.g., Linux, Apache, Perl, etc.) -> Shared development -> Market penetration Example: TCP/IP for Vax/VMS Software may be open source, but packaging and services can be profitable businesses
  138. 138. Open Source • Free redistribution • Source code • Derived works • Integrity of the author's source code • No discrimination against persons or groups
  139. 139. Open Source • No discrimination against fields of endeavor • Distribution of license • License must not be specific to a product • License must not contaminate other software http://www.opensource.org/osd.html
  140. 140. Practical Advice Be aware of the law, but do not pretend to be a lawyer. Use a professional for: • Contracts and licenses • Troubles (complaints, injunctions, subpoenas, etc.) • Personnel issues • When in doubt, ask help!
  141. 141. Source Code Management Or Configuration Management: How I learned to Stop Worrying and Hate My Co-workers Less
  142. 142. Source Code Management  Also known as Configuration Management  Source Code Managers are tools that: – Archive your development files – Serve as a single point of entry/exit when adding or updating development files
  143. 143. Why You Want A Source Control System  Supports concurrent development  Manage diverging source code bases  Records file/release versions  Easy access to all previous revisions  Can record why a revision was made  Optimal disk space usage  You’ll end up doing something equivalent anyway so it may as well be automated
  144. 144. Source Code Management Tools Are Not  A substitute for project management  A replacement for developer communication
  145. 145. How They Work  Central database of source code, documentation, build tools  Each file stored only once - all other versions are diffs of that one copy  To Make a Change – Check out the latest version of a file – Make the changes – Update the database
  146. 146. What should be in the database  Source Code  Documentation  Build Tools – Often need old versions of the tools to build old versions of the software – Ensures software is rebuilt exactly as the customer received it  Test Suites  Anything else you might want later
  147. 147. Version Control  Companies ship several products from the same source base (i.e. Win NT and Windows 2000 versions of MS Office)  When tracking down bugs you want to examine the code as it was when the product shipped
  148. 148. Code Sharing  Multiple people can work on the same source base without colliding – (1) Locks individual files so only one person at a time can modify it *OR* – (2) Allows multiple people to modify a source file and the system will automatically merge the changes (usually)
  149. 149. Locking  Only one person can work on a file at once  Works fairly well if developers work on different areas of the project and don’t conflict often  Problem 1: People forget to unlock files when they are done  Problem 2: People work around locking by editing a private copy and checking in when the file is finally unlocked - easy to goof and lose changes
  150. 150. Merging  Several people can work on a file at once  Before committing changes, each user merges their copy with the latest copy in the database – This is normally done automatically by the system and usually works, but you should not blindly accept the result of the merge
  151. 151. Labeling  Label all the files in the source base that make up a product at each milestone  Just before and just after a major change (e.g.. changing several interfaces)  When a new version ships
  152. 152. Version Trees  Each file in the database has a version tree  Can branch off the version tree to allow separate development paths  Typically a main path (trunk) for the next major version and branches off of shipped versions for maintenance
  153. 153. Branching  When a new version ships, typically create a branch in the version tree for maintenance  Double update: fix a defect in the latest version and then merge the changes (often by hand) into the maintenance version  Also create personal versions so you can make a change against a stable source base and then merge in the latest version later
  154. 154. Examples  RCS – Solaris: man rcsintro  CVS – Solaris: man cvs – www.cyclic.com/cvs/info.html  Visual SourceSafe – msdn.microsoft.com/SSAFE  ClearCase – www.rational.com
  155. 155. RCS  File management only  Transaction model – check out and lock – edit – check in and unlock  Little support for binaries
  156. 156. CVS  Built on top of RCS – Therefore little support for binaries  Database can be remote  No locking: merge before commit  Fast  Integrates with emacs
  157. 157. SourceSafe  Microsoft’s entry into the field  Project-based  Checkout-edit-checkin model  Built-in web site creation tools  Integrates with MSDEV
  158. 158. Clearcase  Clearcase is configuration management on steroids  You create a view of the database with a config spec, which describes how to select files from the database.  When you set a view, Clearcase creates a virtual filesystem containing only those versions of the files selected by the config spec
  159. 159. Clearcase Features  Distributed System – Several groups at different locations can work on the same database  Can install triggers – Example: e-mail the author of a file when some one makes a change to it  Uses merging model like CVS, but can also lock files
  160. 160. More Clearcase Features  Integrates with MSDEV  Build Management – Knows to rebuild out-of-date files even if your makefile doesn’t  Slow and a bit buggy
  161. 161. Helpful Rules for Version Control Bliss  Archived Files Should Always Compile  Code Review Files Before Check-in  Compile and run latest archived files *as a set* before Check-in  No Cheating (even “simple bug fixes” need to undergo this process)
  162. 162. Software Engineering Lecture 10 Formal Specification
  163. 163. Formal Specification Why? • Precise standard to define and validate software Why not? • May be time consuming • Methods not suitable for all applications
  164. 164. Formal Specification Ben Potter, Jane Sinclair, David Till, An Introduction to Formal Specification and Z (Prentice Hall) 1991 Jonathan Jacky The Way of Z (Cambridge University Press) 1997
  165. 165. Mathematical Specification Example of specification B1, B2, ... Bk is a sequence of m x m matrices η1, η2, ... ηk is a sequence of m x m elementary matrices B1-1 = η1 B2-1 = η2η1 Bk-1 = ηk ... η2η1 The numerical accuracy must be such that, for all k, BkBk-1 - I < ∆
  166. 166. Specification of Programming Languages <unsigned number> ::= <unsigned integer> | <unsigned real> <unsigned integer> ::= <digit> {<digit>} <unsigned real> ::= <unsigned integer> . <digit> {<digit>} | <unsigned integer> . <digit> {<digit>} E <scale factor> | <unsigned integer> E <scale factor> <scale factor> ::= <unsigned integer> | <sign> <unsigned integer> <sign> ::= + | Pascal number syntax
  167. 167. Formal Specification Using Diagrams unsigned integer digit unsigned number unsigned integer + . digit unsigned integer E -
  168. 168. Two Rules • Formal specification does not guarantee correctness • Formal specification does not prescribe the implementation
  169. 169. Example: Z Specification Language Informal: The function intrt(a) returns the largest integer whose square is less than or equal to a. Formal (Z): intrt: N N a : N• intrt(a) * intrt(a) < a < (intrt(a) + 1) * (intrt(a) + 1)
  170. 170. Example: Algorithm 1 + 3 + 5 + ... (2n - 1) = n2
  171. 171. Example: Program int intrt (int a) /* Calculate integer square root */ { int i, term, sum; term = 1; sum = 1; for (i = 0; sum <= a; i++) { term = term + 2; sum = sum + term; } return i; }
  172. 172. Finite State Machine A broadly used method of formal specification: • Event driven systems (e.g., games) • User interfaces • Protocol specification etc., etc., ...
  173. 173. Finite State Machine Example: Therapy control console [informal description]
  174. 174. State Transition Diagram Select field Enter Patients Enter Fields Start (ok) Setup Beam on Ready Stop (interlock) Select patient
  175. 175. State Transition Table Select Select Enter Patient Field Patients Fields Patients Setup Patients Fields Ready Patients Fields Beam on ok Start Stop interlock Fields Setup Ready Beam on Setup Ready Setup
  176. 176. Z Specification STATE ::= patients | fields | setup | ready | beam_on EVENT ::= select_patient | select_field | enter | start | stop | ok | interlock FSM == (STATE X EVENT) STATE no_change, transitions, control : FSM Continued on next slide
  177. 177. Z Specification (continued) control = no_change transitions no_change = { s : STATE; e : EVENT • (s, e) transitions = { (patients, enter) (fields, select_patient) s} fields, patients, (fields, enter) setup, (setup, select_patient) patients, (setup, select_field) (setup, ok) ready, fields, (ready, select_patient) patients, (ready, select_field) fields, (ready, start) beam_on, (ready, interlock) setup, (beam_on, stop) ready, (beam_on, interlock) setup }
  178. 178. Schemas Schema: • The basic unit of formal specification. • Describes admissible states and operations of a system.
  179. 179. LibSys: An Example of Z Library system: • Stock of books • Registered users. • Each copy of a book has a unique identifier. • Some books on loan; other books on shelves available for loan. • Maximum number of books that any user may have on loan.
  180. 180. LibSys: Operations • Issue a copy of a book to a reader. • Reader return a book. • Add a copy to the stock. • Remove a copy from the stock. • Inquire which books are on loan to a reader. • Inquire which readers has a particular copy of a book. • Register a new reader. • Cancel a reader's registration.
  181. 181. LibSys Level of Detail: Assume given sets: Copy, Book, Reader Global constant: maxloans
  182. 182. Schemas Describing Operations Naming conventions for objects: Before: plain variables, e.g., r After: with appended dash, e.g., r' Input: with appended ?, e.g., r? Output: with appended !, e.g., r!
  183. 183. Operation: Issue a Book • Inputs: copy c?, reader r? • Copy must be shelved initially: c? ∈ shelved • Reader must be registered: r? ∈ readers • Reader must have less than maximum number of books on loan: #(issued  {r?}) < maxloans • Copy must be recorded as issued to the reader: issued' = issued ⊕ {c? r?} • The stock and the set of registered readers are unchanged: stock' = stock; readers' = readers
  184. 184. Domain and Range X ran m y dom m x m:X Y Y dom m = { x ∈ X : ∃ y ∈ Y ∧ x y} ran m = { y ∈ Y : ∃ x ∈ X ∧ x y}
  185. 185. Operation: Issue a Book Issue stock, stock' : Copy issued, issued' : Copy Book Reader shelved, shelved': F Copy readers, readers' : F Reader c?: Copy; r? :Reader [See next slide]
  186. 186. Operation: Issue a Book (continued) Issue [See previous slide] shelved ∪ dom issued = dom stock shelved' ∪ dom issued' = dom stock' shelved ∩ dom issued = Ø; shelved' ∩ dom issued' = Ø ran issued ⊆ readers; ran issued' ⊆ readers' ∀r : readers • #(issued  {r}) < maxloans ∀r : readers' • #(issued'  {r}) < maxloans c? ∈ shelved; r? ∈ readers; #(issued  {r?}) < maxloans issued' = issued ⊕ {c? r?} stock' = stock; readers' = readers
  187. 187. LibSys: Schema for Abstract States Library stock : Copy Book issued : Copy Reader shelved : F Copy readers: F Reader shelved ∪ dom issued = dom stock shelved ∩ dom issued = Ø ran issued ⊆ readers ∀r : readers • #(issued  {r}) < maxloans
  188. 188. Schema Inclusion LibDB stock : Copy Book readers: F Reader LibLoans issued : Copy Reader shelved : F Copy ∀r : Reader • #(issued  {r}) < maxloans shelved ∩ dom issued = Ø
  189. 189. Schema Inclusion (continued) Library LibDB LibLoans dom stock = shelved ∪ dom issued ran issued ⊆ readers
  190. 190. Schema Decoration Issue Library Library' c? : Copy; r? : Reader c? ∈ shelved; r? ∈ readers #(issued  {r?}) < maxloans issued' = issued ⊕ {c? r?} stock' = stock; readers' = readers
  191. 191. Schema Decoration Issue ∆Library c? : Copy; r? : Reader c? ∈ shelved; r? ∈ readers #(issued  {r?}) < maxloans issued' = issued ⊕ {c? r?} stock' = stock; readers' = readers
  192. 192. The Schema Calculus Schema inclusion Schema decoration Schema disjunction: ^ AddCopy = AddKnownTitle ∨ AddNewTitle Schema conjunction: ^ AddCopy = EnterNewCopy ∧ AddCopyAdmin Schema negation Schema composition
  193. 193. Software Engineering Lecture 11 Object-Oriented Design I
  194. 194. What is in a Requirements Document? Example (Web Butler and Web Site Profiler) • Run web data collection in real time or batch mode How are jobs started? • Job parameters How are the parameters set up (interactive, edit file, ...)? What are the parameters (specify)? Can job parameters be stored and used again? If so, how? • Job monitoring What feedback is given while job is running? Can the user pause or break a job? If so, are the results retained?
  195. 195. What is in a Requirements Document? Remember • The requirements document specifies the functionality that you plan to deliver to the client • It must be comprehensive and detailed. Everything must be written out -- no hand waving! The requirements document is likely to be several times as long as Assignment 1.
  196. 196. Assignment 2 -- Individual Parts One approach: With your document, include a list of who contributed what part to the Requirements study, e.g., Person A Requirements analysis for database design (member of team of 3), wrote Section 3.1 of document, worked with client to identify software needs. Person B Prepared visual aids for presentation, edited entire document, specified the security needs and wrote Section 4.2.
  197. 197. The Waterfall Model Requirements Definition System and Software design Implementation and Unit Testing Integration and System Testing Operation and Maintenance
  198. 198. Useful Texts Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language. Addison-Wesley 1999. Grady Booch, Object-Oriented Analysis and Design with Applications, second edition. Benjamin/Cummings 1994. Rob Pooley, Perdita Stevens, Using UML Software Engineering with Objects and Components. Addison-Wesley 1999.
  199. 199. The Importance of Modeling • A model is a simplification of reality. • We build models so that we can better understand the system we are developing. • We build models of complex system because we cannot comprehend such a system in its entirety. Models can be informal or formal. The more complex the project the more valuable a formal model becomes. BRJ
  200. 200. Principles of Modeling • The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped. • Every model can be expressed at different levels of precision. • The best models are connected to reality. • No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models. BRJ
  201. 201. The Unified Modeling Language UML is a standard language for modeling software systems. • Serves as a bridge between the requirements specification and the implementation. • Provides a means to specify and document the design of a software system. • Is process and programming language independent. • Is particularly suited to object-oriented program development.
  202. 202. Notation: Classes Window origin size open() close() move() display() name attributes operations A class is a description of a set of objects that share the same attributes, operations, relationships and semantics.
  203. 203. Notation: Interface ISpelling An interface is a collection of operations that specify a service of a class or component, i.e., the externally visible behavior of that element.
  204. 204. Notation: Collaboration & Use Case Chain of responsibility A collaboration defines an interaction, i.e., a society of roles and other elements that work together to provide some cooperative behavior. Place order A use case is a description of a set of sequence of actions that a system performs that yields an observable result.
  205. 205. Notation: Active Class EventManager eventlist suspend() flush() An active class is a class whose objects own one or more processes or threads and therefore can initiate control activity.
  206. 206. Notation: Component & Node orderform.java A component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. Server A node is a physical element that exists at run time and represents a computational resource.
  207. 207. Notation: Behavioral Things: Messages & States display An interaction is a behavior that comprises a set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose. Waiting A state machine is a behavior that specifies the sequence of states an object or an interaction goes through during its lifetime in response to events.
  208. 208. Notation: Grouping and Annotation Business rules A package is a general-purpose mechanism for organizing elements into groups. return copy of self A note is a symbol for rendering constraints and comments attached to an element or a collection of elements.
  209. 209. Notation: Relationships A dependency is a semantic relationship between two things in which a change to one may effect the semantics of the other. 0..1 employer * employee An association is a structural relationship that describes a set of links, a link being a connection among objects.
  210. 210. Notation: Relationships (continued) child parent A generalization is a specialization/generalization relationship is which objects of the specialized element (child) are substitutable for objects of the generalized element (parent). A realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out.
  211. 211. Diagrams in UML A diagram is the graphical representation of a set of elements, usually rendered as a connected graph of vertices (things) and arcs (relationships). • Class diagram shows a set of classes, interfaces, and collaborations with their relationships. • Object diagram shows a set of objects and their relationships. • Use case diagram shows a set of use cases and actors (a special kind of class) and their relationships.
  212. 212. Diagrams in UML (continued) • Interaction diagram shows an interaction, consisting of a set of objects and the relationships, including the messages that may be dispatched among them. => A sequence diagram emphasizes the time ordering. => A collaboration diagram emphasizes the structural organization of the objects that send and receive messages.
  213. 213. Diagrams in UML (continued) • Statechart diagram shows a state machine consisting of states, transitions, events, and activities. • Activity diagram is a statechart diagram that shows the flow from activity to activity within a system. • Component diagram shows the organization and dependencies among a set of components. • Deployment diagram shows the configuration of processing nodes and the components that live on them.
  214. 214. The HelloWorld Example class name HelloWorld operations paint()
  215. 215. Abstraction for HelloWorld class name HelloWorld operations paint() annotation g.drawString ("HelloWorld", 0, 10)"
  216. 216. The "Hello, World" Example import java.awt.Graphics; class HelloWorld extends java.applet.Applet { public void paint (Graphics g) { g.drawString ("Hello, World!", 10, 10); } } Example from: BJR
  217. 217. Class Diagram Applet generalization Note that the Applet and Graphics classes are shown elided. HelloWorld paint() dependency Graphics
  218. 218. Class Inheritance Diagram Object Panel interface Component ImageObserver Applet Container HelloWorld
  219. 219. Packaging Classes java HelloWorld applet Graphics awt lang package
  220. 220. Notation for Classes and Objects Classes AnyClass attribute1 attribute2 operation1() operation2() or AnyClass Objects anObject:AnyClass or :AnyClass or anObject The names of objects are underlined.
  221. 221. Software Engineering Lecture 12 Object-Oriented Design II
  222. 222. Requirements: the Long Term Believe that your software will be in use 5 years from now. • What happens at end of semester? Packaging and hand-over Client's technical preferences (C++, Java) • Some system decisions based on short-term considerations • Which formats, protocols, etc. do you think will last? (IIOP, RMI, SNMP, ...)
  223. 223. Requirements, Design and Implementation Remember the definitions. Example: Consistency between two players of a board game • The requirement is ..... • The design is ..... What is a requirements specification?
  224. 224. Modeling Classes Given a real-life system, how do you decide what classes to use? • What terms do the users and implementers use to describe the system? They are candidates for classes. • Is each candidate class crisply defined? • For each class, what is its set of responsibilities? Are the responsibilities evenly balanced among the classes? • What attributes and operations does each class need to carry out its responsibilities?
  225. 225. Noun Identification: A Library Example The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals. The system must keep track of when books and journals are borrowed and returned and enforce the rules.
  226. 226. Noun Identification: A Library Example The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals. The system must keep track of when books and journals are borrowed and returned and enforce the rules.
  227. 227. Candidate Classes Library Book Journal Copy ShortTermLoan LibraryMember Week MemberOfLibrary Item Time MemberOfStaff System Rule the name of the system event measure repeat book or journal abstract term general term general term
  228. 228. Relations between Classes Book Journal Copy LibraryMember Item MemberOfStaff Is Item needed? is an is an is a copy of a Item Item Book is a LibraryMember
  229. 229. Operations LibraryMember borrows Copy LibraryMember returns Copy MemberOfStaff borrows Journal MemberOfStaff returns Journal Item not needed yet.
  230. 230. Class Diagram MemberOfStaff LibraryMember 1 1 on loan on loan 0..12 Journal 0..* Copy is a copy of 1..* 1 Book
  231. 231. Rough Sketch: Wholesale System A wholesale merchant supplies retail stores from stocks of goods in a warehouse. What classes would you use to model this business?
  232. 232. Rough Sketch: Wholesale System RetailStore Order Merchant Product Warehouse Invoice Shipment
  233. 233. Rough Sketch: Wholesale System RetailStore name address contactInfo financialInfo Merchant Warehouse Order Product Reversals Invoice Shipment damaged() return() wrongItem() Responsibilities -track status of shipped products responsibility (text field)
  234. 234. Expanding a Class: Modeling Financial Information RetailStore association 1 * Transaction Which class is responsible for the financial records for a store? Payment Invoice
  235. 235. Modeling Invoice Shipment ??? RetailStore invoiceRecord goodsShipped Invoice invoiceNumber adornments +goodsShipped() + public -sendInvoice() - private PartsList
  236. 236. Lessons Learned Design is empirical. There is no single correct design. During the design process: • Eliding: Elements are hidden to simplify the diagram • Incomplete: Elements may be missing. • Inconsistency: The model may not be consistent The diagram is not the whole design. Diagrams must be backed up with specifications.
  237. 237. Levels of Abstraction The complexity of a model depends on its level of abstraction: • High-levels of abstraction show the overall system. • Low-levels of abstraction are needed for implementation. Two approaches: • Model entire system at same level of abstraction, but present diagrams with different levels of detail. • Model parts of system at different levels of abstraction.
  238. 238. Component Diagram hello.hml executable component HelloWorld.class hello.jpg hello.java
  239. 239. Actor and Use Case Diagram BookBorrower Borrow book • An actor is a user of a system in a particular role. An actor can be human or an external system. • A use case is a a task that an actor needs to perform with the help of the system.
  240. 240. Use Cases and Actors • A scenario is an instance of a use case • Actor is role, not an individual (e.g., librarian can have many roles) • Actor must be a "beneficiary" of the use case (e.g., not librarian who processes book when borrowed) In UML, the system boundary is the set of use cases.
  241. 241. Use Cases for Borrowing Books Borrow copy of book BookBorrower Extend loan Return copy of book Reserve book
  242. 242. Relationships Between Use Cases: <<uses>> Extend loan BookBorrower Borrow copy of book <<uses>> <<uses>> Check for reservation
  243. 243. Relationships Between Use Cases: <<extends>> BookBorrower <<extends>> Borrow copy of book Refuse loan
  244. 244. Use Cases in the Development Cycle • Use cases are a tool in requirements analysis • Intuitive -- easy to discuss with clients • Use cases are often hard to translate into class models • Scenarios are useful to validate design
  245. 245. Software Engineering Lecture 13 Object-Oriented Design III
  246. 246. Comments on Presentations Presentation • Standard of graphics has been high • Some text too small (diagrams, screen dumps) Content • Level of detail • Requirements v. design The client defines the requirements Well done, but time is short. What is your critical path?
  247. 247. Modeling Dynamic Aspects of Systems Interaction diagrams: set of objects and their relationships including messages that may be dispatched among them • Sequence diagrams: time ordering of messages • Collaboration diagrams: structural organization of objects that send and receive messages Activity diagram: flow chart showing flow of control from activity to activity Statechart diagram: models a state machine
  248. 248. Bouncing Ball Diagrams Example: http://www.cs.cornell.edu/ domain name TCP connection HTTP get Client Servers
  249. 249. Actions on Objects call returnCopy(c) okToBorrow() return send create destroy local status notifyReturn(b) asynchronous signal <<create>> <<destroy>> stereotypes
  250. 250. Links LibraryMember 1 on loan 0..* Copy association +borrowCopy() +returnCopy() class libMem:LibraryMember object message borrowCopy(c) link c:Copy
  251. 251. Sequence Diagram: Change in Cornell Program :MEngStudent Cornellian 1 : getName() 1.1 : name 2: new PhDStudent(name) :PhDStudent 3: <<destroy>> sequence numbers added to messages
  252. 252. Sequence Diagram: Borrow copy of a Book libMem: LibraryMember BookBorrower theBook:Book theCopy:Copy borrow(theCopy) okToBorrow borrow borrow
  253. 253. Class Inheritance Diagram Object Panel interface Component ImageObserver Applet Container HelloWorld
  254. 254. Sequence Diagram:Painting Mechanism :Thread run :Toolkit run :ComponentPeer callbackLoop handleExpose paint target:HelloWorld
  255. 255. Activity Diagram: Process Modeling Release work order branch [materials not ready] [materials ready] Assign tasks Reschedule guard expression
  256. 256. Activity Diagram: Parallel Activities start state Decompress fork Stream video join stop state Stream audio
  257. 257. State Diagram returned() not borrowable returned() borrowable borrowed()[last copy] guard expression borrowed()[not last copy] State diagram for class Book
  258. 258. Implementation Modeling Subsystem A grouping of elements that specifies what a part of a system should do. Component (UML definition) "A distributable piece of implementation of a system, including software code (source, binary, or executable) but also including business documents, etc., in a human system." A component can be thought of as an implementation of a subsystem.
  259. 259. Component Diagram hello.hml executable component HelloWorld.class hello.jpg hello.java
  260. 260. Components and Classes agent.dll AgentAction PatternSearch Policy
  261. 261. Components and Classes agent.dll Realizes AgentAction PatternSearch Policy extended component
  262. 262. Components and Classes Classes represent logical abstractions. Components represent physical things. Components may live on nodes. Classes have attributes and operations directly. Components have operations that are reachable only through interfaces.
  263. 263. Interfaces render.java simulation.exe IRender dependency realization interface
  264. 264. Application Programming Interface (API) API is an interface that is realized by one or more components. simulation.exe IRender IModels ILighting
  265. 265. Components and Replaceability Components allow system to be assembled from binary replaceable elements. • A component is physical -- bits not concepts • A component can be replaced by any other component(s) that conforms to the interfaces. • A component is part of a system. • A component provides the realization of a set of interfaces.
  266. 266. Software Engineering Lecture 14 System Architecture I Data Intensive Systems
  267. 267. System Architecture The overall design of a system: • • • • • • Computers and networks (e.g., monolithic, distributed) Interfaces and protocols (e.g., http, CORBA) Databases (e.g., relational, distributed) Security (e.g., smart card authentication, SSL) Operations (e.g., backup, archiving, audit trails) Software environments (e.g., languages, source control tools)
  268. 268. Data Intensive Systems Examples • Electricity utility customer billing • Telephone company call recording and billing • Car rental reservations (e.g., Hertz) • Stock market brokerage (e.g., Charles Schwab) • Web sales (e.g., Amazon.com)
  269. 269. Example 1: Electricity Utility Billing First attempt: Transaction Data input Master file Each transaction handled as it arrives. Bill
  270. 270. Criticisms of First Attempt Where is this first attempt weak? The requirements have not been specified!!!
  271. 271. Transaction Types • • • • • • • • Create account / close account Meter reading Payment received Other credits / debits Check cleared / check bounced Account query Correction of error etc., etc., etc.,
  272. 272. Typical Requirements • All payments to be credited on day received • Customers must be able to query account by telephone • Cutting off service for non-payment requires management authorization • Data input staff should process n transactions per day per person • Error rate must be below 0.01% • System available 99.9% of business hours
  273. 273. Batch Processing: Validation errors Edit & validation Incoming transactions Data input read only Master file Validated transactions
  274. 274. Batch Processing: Master File Update Validated transactions in batches errors Reports Sort by account Master file update Bills Instructions
  275. 275. Benefits of Batch Updating • All transactions for an account are processed together • Backup and recovery have fixed checkpoints • Better management control of operations • Efficient use of staff and hardware
  276. 276. Online Inquiry Customer service read only Transactions Data input Master file Bills
  277. 277. Example 2: A Small-town Stockbroker • Transactions Received by mail or over telephone For immediate or later action • Complex customer inquiries • Highly competitive market
  278. 278. A Database Architecture Database(s): • Customer and account database • Financial products (e.g., account types, pension plans, savings schemes) • External databases (e.g., stock markets, mutual funds, insurance companies)
  279. 279. Database Architecture Products & services database Customer & account database External services
  280. 280. Real-time Transaction Real-time transactions Products & services database Customer & account database External services
  281. 281. Real-time Transactions & Batch Processing Real-time transactions Products & services database Data input Batch processing Customer & account database External services
  282. 282. Architectural considerations • Real-time service during scheduled hours + batch processing overnight • Combine information from several databases • Database consistency after any type of failure two-phase commit reload from checkpoint + log detailed audit trail • How will transaction errors be avoided? • How will transaction errors be corrected?
  283. 283. Example: Merger of Two Banks Each bank has a database with its customer accounts. The databases are used by staff at many branches and for back-office processing. The requirement is to integrate the two banks so that they appear to the customers to be a single organization and to provide integrated service from all branches.
  284. 284. Merger of Two Banks: Options A ??? ??? B
  285. 285. Merger of Two Banks: Architectural Options I. Convert everything to System A. convert databases retrain staff enhance System A (software and hardware) discard System B II. Build an interface between the databases in System A and System B. III. Extend client software so that it can interact with either System A or System B database.
  286. 286. Distributed Computing: General Problem An application that is running on one computer wishes to use data or services provided by another: • Network connection private, public, or virtual private network location of firewalls • Protocols point-to-point, multicast, broadcast message passing, RPC, distributed objects stateful or stateless • Quality of service
  287. 287. Network Choices Public Internet: Ubiquitous -- worldwide Low cost Private network: Security Predictable performance Choice of protocols (e.g., IBM's SNA)
  288. 288. Quality of Network Services Performance Maximum throughput Variations in throughput Real-time media (e.g., audio) Business Suppliers Trouble shooting and maintenance Upgrades
  289. 289. Firewall Public network Private network Firewall A firewall is a computer at the junction of two network segments that: • Inspects every packet that attempts to cross the boundary • Rejects any packet that does not satisfy certain criteria, e.g., an incoming request to open a TCP connection an unknown packet type
  290. 290. Software Engineering Lecture 15 System Architecture II Distributed and Real Time Systems
  291. 291. Comments on Requirements Report Audience • • Client and design team Will be updated over time Content • • • Level of detail -- will be used to validate the implementation Requirements, not design Precise, but not legalistic
  292. 292. Sequence Diagram: Notation libMem: LibraryMember BookBorrower theBook:Book theCopy:Copy borrow(theCopy) okToBorrow borrow borrow dotted line shows object lifetime rectangle shows focus of control
  293. 293. Sequence Diagram: Branching libMem: LibraryMember theCopy:Copy BookBorrower 1:borrow(theCopy) [not ok]3:noborrow branch theBook:Book 2:okToBorrow [ok]3:borrow 4:borrow
  294. 294. Example: Distributed Database two copies of the same data
  295. 295. Distributed Data and Replication Distributed Data Data is held on several computer systems. A transaction may need to assemble data from several sources. Replication Several copies of the data are held in different locations. Mirror: Complete data set is replicated Cache: Dynamic set of data is replicated (e.g., most recently used) With replicated data, the biggest problem is consistency.
  296. 296. Example: Broadcast Search User User interface server Databases
  297. 297. Example: UseNet
  298. 298. Stateless Protocol v. Stateful Stateless protocol Example: http Open connection Send message Return reply Close connection State in http must be sent with every message (e.g., as parameter string or in a cookie)
  299. 299. Stateless Protocol v. Stateful Stateful (session) protocol Example: Z39.50 Open connection Begin session Interactive session End session Close connection Server remembers the results of previous transactions (e.g., authentication, partial results) until session is closed.
  300. 300. Firewall Public network Private network Firewall A firewall is a computer at the junction of two network segments that: • Inspects every packet that attempts to cross the boundary • Rejects any packet that does not satisfy certain criteria, e.g., an incoming request to open a TCP connection an unknown packet type
  301. 301. The Domain Name System First attempt to resolve www.cs.cornell.edu .edu server 1 2 3 cornell.edu server cs.cornell.edu server
  302. 302. Discussion of the First Attempt Problems?
  303. 303. The Domain Name System Better method local DNS server 1 almaden.ibm.com cornell.edu Local ece.cmu.edu cache ibm.com acm.org .edu .edu server 2 cornell.edu server 3 cs.cornell.edu server
  304. 304. Real Time System A real time system is a software system whose correct functioning depends upon the results produced and the time at which they are produced. • A soft real time system is degraded if the results are not produced within required time constraints • A hard real time system fails if the results are not produced within required time constraints
  305. 305. Example: Web Server http message daemon TCP port 80 spawned processes The daemon listens at port 80. When a message arrives it: spawns a processes to handle the message returns to listening at port 80
  306. 306. Embedded Systems Software and hardware are combined to provide an integrated unit, usually dedicated to a specific task: • Digital telephone • Automobile engine control • GPS • Scientific instruments The software may be embedded in the device in a manner that can not be altered after manufacture.
  307. 307. Example: Autonomous Land Vehicle GPS Steer Sonar Model Laser Control signals Throttle Controls Sensors Signal processing
  308. 308. Other Applications Response critical • Network router • Telephone switch • Seat bag controller Shared systems • Multi-user data processing • Time sharing
  309. 309. Techniques • Special purpose hardware • Multi-threading and multi-tasking • Parallel processing => digital signal processing • Interrupts => levels and priorities
  310. 310. Multi-Threading Several similar threads operating concurrently: • Re-entrant code -- separation of pure code from data for each thread • Testing -- single thread and multi thread May be real time (e.g., telephone switch) or nontime critical
  311. 311. Real Time Executive Schedules and dispatches tasks in a real time system • Real time clock • Interrupt handler • Scheduler • Resource manager • Dispatcher Must be extremely reliable
  312. 312. Timing Timing mechanisms • Synchronous (clocked) -- periodic stimuli • Asynchronous -- wait for next signal Example: Communications protocols may be synchronous or asynchronous
  313. 313. Hardware v. Software Design of embedded systems requires close understanding of hardware characteristics • Special purpose hardware requires special tools and expertise. • Some functions may be implemented in either hardware of software (e.g., floating point unit) • Design requires separation of functions Distinction between hardware and software may be blurred.
  314. 314. Example: Dartmouth Time Shared System master processor Communications processor Communications processor I/O Mulitplexor Central processor Central processor Central processor
  315. 315. Software Considerations Resource considerations may dictate software design and implementation: • Low level language (e.g., C) where programmer has close link to machine • Inter-process communication may be too slow (e.g., C fork). • May implement special buffering, etc., to control timings
  316. 316. Example: CD Controller 4 Input block 7 3 2 5 6 Circular buffer 1 Output block
  317. 317. Continuous Operation Many systems must operate continuously • Software update while operating • Hardware monitoring and repair • Alternative power supplies, networks, etc. • Remote operation These functions must be designed into the fundamental architecture.
  318. 318. Routers and Other Network Computing • Interoperation with third party devices • Support for several versions of protocols • Restart after total failure • Defensive programming -- must survive => erroneous or malicious messages => extreme loads • Time outs, dropped packets, etc. • Evolution of network systems
  319. 319. Software Engineering Lecture 15 System Architecture II Distributed and Real Time Systems
  320. 320. Administration Assignment 2: Requirements • • • Grades -- presentation, report, individual Comments at presentation Comments from teaching assistant Assignment 3: Design
  321. 321. Comments on Requirements Report Audience • • Client and design team Will be updated over time Content • • • Level of detail -- will be used to validate the implementation Requirements, not design Precise, but not legalistic
  322. 322. Sequence Diagram: Notation libMem: LibraryMember BookBorrower theBook:Book theCopy:Copy borrow(theCopy) okToBorrow borrow borrow dotted line shows object lifetime rectangle shows focus of control
  323. 323. Sequence Diagram: Branching libMem: LibraryMember theCopy:Copy BookBorrower 1:borrow(theCopy) [not ok]3:noborrow branch theBook:Book 2:okToBorrow [ok]3:borrow 4:borrow
  324. 324. Example: Distributed Database two copies of the same data
  325. 325. Distributed Data and Replication Distributed Data Data is held on several computer systems. A transaction may need to assemble data from several sources. Replication Several copies of the data are held in different locations. Mirror: Complete data set is replicated Cache: Dynamic set of data is replicated (e.g., most recently used) With replicated data, the biggest problem is consistency.
  326. 326. Example: Broadcast Search User User interface server Databases
  327. 327. Example: UseNet
  328. 328. Stateless Protocol v. Stateful Stateless protocol Example: http Open connection Send message Return reply Close connection State in http must be sent with every message (e.g., as parameter string or in a cookie)
  329. 329. Stateless Protocol v. Stateful Stateful (session) protocol Example: Z39.50 Open connection Begin session Interactive session End session Close connection Server remembers the results of previous transactions (e.g., authentication, partial results) until session is closed.
  330. 330. Firewall Public network Private network Firewall A firewall is a computer at the junction of two network segments that: • Inspects every packet that attempts to cross the boundary • Rejects any packet that does not satisfy certain criteria, e.g., an incoming request to open a TCP connection an unknown packet type
  331. 331. The Domain Name System First attempt to resolve www.cs.cornell.edu .edu server 1 2 3 cornell.edu server cs.cornell.edu server
  332. 332. Discussion of the First Attempt Problems?
  333. 333. The Domain Name System Better method local DNS server 1 almaden.ibm.com cornell.edu Local ece.cmu.edu cache ibm.com acm.org .edu .edu server 2 cornell.edu server 3 cs.cornell.edu server
  334. 334. Real Time System A real time system is a software system whose correct functioning depends upon the results produced and the time at which they are produced. • A soft real time system is degraded if the results are not produced within required time constraints • A hard real time system fails if the results are not produced within required time constraints
  335. 335. Example: Web Server http message daemon TCP port 80 spawned processes The daemon listens at port 80. When a message arrives it: spawns a processes to handle the message returns to listening at port 80
  336. 336. Embedded Systems Software and hardware are combined to provide an integrated unit, usually dedicated to a specific task: • Digital telephone • Automobile engine control • GPS • Scientific instruments The software may be embedded in the device in a manner that can not be altered after manufacture.
  337. 337. Example: Autonomous Land Vehicle GPS Steer Sonar Model Laser Control signals Throttle Controls Sensors Signal processing
  338. 338. Other Applications Response critical • Network router • Telephone switch • Seat bag controller Shared systems • Multi-user data processing • Time sharing
  339. 339. Techniques • Special purpose hardware • Multi-threading and multi-tasking • Parallel processing => digital signal processing • Interrupts => levels and priorities
  340. 340. Multi-Threading Several similar threads operating concurrently: • Re-entrant code -- separation of pure code from data for each thread • Testing -- single thread and multi thread May be real time (e.g., telephone switch) or nontime critical
  341. 341. Real Time Executive Schedules and dispatches tasks in a real time system • Real time clock • Interrupt handler • Scheduler • Resource manager • Dispatcher Must be extremely reliable
  342. 342. Timing Timing mechanisms • Synchronous (clocked) -- periodic stimuli • Asynchronous -- wait for next signal Example: Communications protocols may be synchronous or asynchronous
  343. 343. Hardware v. Software Design of embedded systems requires close understanding of hardware characteristics • Special purpose hardware requires special tools and expertise. • Some functions may be implemented in either hardware of software (e.g., floating point unit) • Design requires separation of functions Distinction between hardware and software may be blurred.
  344. 344. Example: Dartmouth Time Shared System master processor Communications processor Communications processor I/O Mulitplexor Central processor Central processor Central processor
  345. 345. Software Considerations Resource considerations may dictate software design and implementation: • Low level language (e.g., C) where programmer has close link to machine • Inter-process communication may be too slow (e.g., C fork). • May implement special buffering, etc., to control timings
  346. 346. Example: CD Controller 4 Input block 7 3 2 5 6 Circular buffer 1 Output block
  347. 347. Continuous Operation Many systems must operate continuously • Software update while operating • Hardware monitoring and repair • Alternative power supplies, networks, etc. • Remote operation These functions must be designed into the fundamental architecture.
  348. 348. Routers and Other Network Computing • Interoperation with third party devices • Support for several versions of protocols • Restart after total failure • Defensive programming -- must survive => erroneous or malicious messages => extreme loads • Time outs, dropped packets, etc. • Evolution of network systems
  349. 349. Software Engineering Lecture 16 System Architecture III Distributed Objects
  350. 350. Real-Time: Software Considerations Resource considerations may dictate software design and implementation: • Low level language (e.g., C) where programmer has close link to machine • Inter-process communication may be too slow (e.g., C fork). • May implement special buffering, etc., to control timings
  351. 351. Buffering Example: CD Controller 4 Input block 7 3 2 5 6 Circular buffer 1 Output block
  352. 352. Continuous Operation Many systems must operate continuously • Software update while operating • Hardware monitoring and repair • Alternative power supplies, networks, etc. • Remote operation These functions must be designed into the fundamental architecture.
  353. 353. Example: Routers and Other Network Computing • Interoperation with third party devices • Support for several versions of protocols • Restart after total failure • Defensive programming -- must survive => erroneous or malicious messages => extreme loads • Time outs, dropped packets, etc. • Evolution of network systems
  354. 354. Example: Transaction Monitor messages Transaction monitor processes A transaction monitor: monitors transactions, routes them across services, balances the load, restarts transactions after failure.
  355. 355. Software Reuse: Application Packages • Package supports a standard application (e.g., payroll, user interface to Internet information, mathematical algorithms) • Functionality can be enhanced by: => configuration parameters (e.g., table driven) => extensibility at defined interfaces => custom written source code extensions
  356. 356. Reuse: Object Object Oriented Languages Example: Java is a relatively straightforward language with a very rich set of class hierarchies. • Java programs derive much of their functionality from standard classes • Learning and understanding the classes is difficult. => Java experts can write complex systems quickly => Inexperienced Java programmers write inelegant and buggy programs
  357. 357. Reuse: Objects - Basic Definitions • An object is a piece of code that owns attributes and provides services through methods. • The methods operate on instance data owned by the object. • A class is a collection of like objects.
  358. 358. Reuse: Objects - Characteristics • Encapsulation. An object has a public interface that defines how other objects or applications can interact with it. methods public instance data • Inheritance. Subclasses can be derived from parent classes. They inherit or override the parents' methods and instance data. • Polymorphism. The effect of a method can vary depending on the class that implements it (e.g., display_object)
  359. 359. Reuse: Objects - Object Binding Binding is the linking of the software interface between two objects. • Static binding: The interface is determined at compile or build time. Straightforward Allows type checking • Dynamic binding or late binding: The link is established at run time. Flexible and extensible Complex
  360. 360. Reuse: Objects - Distributed Objects Objects on separate computers interact through method calls and instance data. Major systems: • CORBA (Common Object Request Broker Architecture) • Microsoft family: OLE, COM, DCOM, Active X ...
  361. 361. Desirable Properties of Distributed Objects • Different languages and operating environments • Reusable code: components • Architecture can be extensible • Future changes can be localized • Standard tools used for client/server interactions
  362. 362. Example: Fedora IDL A research project to explore extensibility: -- very simple Interface Definition Language -- powerful tools for extensions -- interoperability, Cornell and CNRI http://www.cs.cornell.edu/cdlrg/fedora.html
  363. 363. Object Request Broker (ORB) C C++ Cobol Objects IDL IDL IDL Interface IDL Java Client Other IDL Server Object Request Broker
  364. 364. Interface Definition Language module <identifier> { <type declarations>; <constant declarations>; <exception declarations>; Naming context interface <identifier> [:<inheritance>] { See next slide } interface <identifier> [:<inheritance>] { ..... } { Define a class Define a class
  365. 365. Interface Definition Language (continued) interface <identifier> [:<inheritance>] { <type declarations>; <constant declarations>; <exception declarations>; Define a class [<op_type] <identifier>(<parameters>) Define a method [raises exception] [context]; .... [<op_type] <identifier>(<parameters>) Define a method [raises exception] [context]; .... }
  366. 366. ORB: Programmer's View Client Invoke a on object X Server Invoke a on object Y Object X Object Y a a Object Request Broker
  367. 367. Object Request Broker (ORB) An ORB lets objects make requests to and receive response from other objects located locally or remotely. • Static and dynamic method invocations • High-level language bindings • Self-describing system • Local/remote transparency • Inter-ORB protocols Internet Inter-ORB Protocol (IIOP)
  368. 368. ORB: System View Interface repository Client Dynamic Client IDL ORB invocation stubs interface Object Implementation implementation repository Static Dynamic Object skeletons invocation adapter Object Request Broker
  369. 369. CORBA Services • • • • • • • • • • • • • Naming service Event service Concurrency control service Transaction service Relationship service Externalization service Query service Life cycle service Persistence service Licensing service Properties service Security service Time service
  370. 370. Distributed Objects and the System Life-Cycle All large systems change with time. • Dynamic binding of objects combined with polymorphism permits the addition of extra object types, incremental changes, etc. to be localized. Development environments change with time. • Language bindings and IIOP permit changes. Production environments changes with time. • Code can be reused in different environments.
  371. 371. Software Engineering Lecture 17 Design for Usability I
  372. 372. Q2: Finite State Machine The cruise control system on an automobile is controlled by a master switch and three buttons. Initially, it is turned on by the master switch. The master switch can be turned off at any time. When first turned on, the system enters stand-by mode. When the system is in stand-by mode, the driver of the automobile can press Button A to engage the cruise control at the current speed of the automobile. When the cruise control is engaged, if the driver presses the brake or presses Button B the system will be disengaged and return to stand-by mode. After returning to standby mode, the driver can press Button C to engage the cruise control at the speed that it was set at previously. (After the system is first turned on, Button C has no effect.) When the cruise control is engaged, the driver can press Button A to increase speed by one mile per hour or Button C to decrease speed by one mile per hour.
  373. 373. State Transition Diagram A C MS-On Off Standby A A Engaged C B-Brake MS-Off Standby1
  374. 374. State Transition Table MS on MS off A Standby Off Engaged Engaged Off Engaged Standby1 Engaged Standby1 Off Engaged Off B Brake C Standby Engaged
  375. 375. Question 4 When software is written, who owns the copyright? How can somebody else be permitted to use the software? How can copyright be transferred to somebody else?
  376. 376. Question 4 When software is written, who owns the copyright? The person who writes the software Except work for hire -- the employer How can somebody else be permitted to use the software? By permission from the copyright owner (usually a license) How can copyright be transferred to somebody else? Copyright is property that can be sold or given away (usually a contract)
  377. 377. Question 4 You are employed for company X writing software. When you leave, who owns your work? What use can you make of the work?
  378. 378. Question 4 You are employed for company X writing software. When you leave, who owns your work? The company (work for hire) What use can you make of the work? None without permission of the copyright owner
  379. 379. Question 4 You work free-lance for company X. When you finish, who owns your work? What use can you make of the work?
  380. 380. Question 4 You work free-lance for company X. When you finish, who owns your work? It depends on the circumstances Have a written contract What use can you make of the work? If you hold the copyright -- unrestricted Otherwise -- none without agreement
  381. 381. Distributed Objects and the System LifeCycle All large systems change with time. • Dynamic binding of objects combined with polymorphism permits the addition of extra object types, incremental changes, etc. to be localized. Development environments change with time. • Language bindings and IIOP permit changes. Production environments changes with time. • Code can be reused in different environments.
  382. 382. Design for Usability Usability of a computer system is a combination of factors: • User interface design • Functionality • Performance • Help systems and documentation • Freedom from errors Anything else?
  383. 383. Iterative Design Evaluation Requirements Implementation (prototype) Design
  384. 384. Methods for Evaluation of Usability • Observing users (user protocols) • Focus groups • Measurements effectiveness in carrying out tasks speed • Expert review • Client's opinions • Competitive analysis
  385. 385. Levels of Usability interface design conceptual model functional design data and metadata computer systems and networks
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×