Software Engineering New

Software Engineering
Lecture 1 Introduction to Software Engineering
Code of Conduct
v Software Engineering is a collaborative activity. You are encouraged to work together, but ... v Some tasks may require individual work. v 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.
2
Projects
v Project teams, about 3 to 5 peoples. v Select your own project, any branch of software engineering v Real project for real client who intends to use the software in production. v Feasibility study and plan: during semester v Presentations: requirements design final
Project Selection
v Some suggested projects v Recitation section to suggest projects Contact potential clients: v Gain idea of their expectations v Estimate scope and complexity of the project v Discuss business decisions Assemble project team v Advertise on the web site
4
Previous Experience
Your background v v v v v v 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
5
Course Themes
1. Leadership of large software projects v Software as a product Clients and their needs Quality v Requirements and specification Usability Evolution v Project management Personnel management Economic, legal, and social factors
6
Course Themes
2. Large and very large systems v Software design Software architecture Object-oriented design v Dependable systems Reliability Verification v Legacy systems
7
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.
8
Software as a Product
Software is expensive!! Every software project has a trade-off between: Functionality Resources (cost) Timeliness Example: Accounting Management System
Client (a.k.a Customer)
v The client provides resources and expects some product in return. v Client satisfaction is the primary measurement of success. Question: Who is the client for Microsoft Excel?
10
Variety of Software Products

Examples? -Operation System -Database Management System -Embedded System -Games -Application Software -
11
Categories of Product
Categories of client and software product: v Generic (e.g., Microsoft Excel) v Bespoke (customized) (e.g., IRS internal system) Many systems are customized versions of generic packages (e.g., Cornell's payroll system)
12
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.
13
Professional Responsibility
Organizations put trust in software developers: v Competence: Software that does not work effectively can destroy an organization. v Confidentiality: Software developers and systems administrators may have access to highly confidential information (e.g., trade secrets, personal data). v Legal environment: Software exists in a complex legal environment (e.g., intellectual property, obscenity). v Acceptable use and misuse: Computer abuse can paralyze an organization (e.g., the Internet worm). 14
Lecture 2 The Software Process
Books
v Frederick P. Brooks, Jr. The Mythical Man Month. Addison-Wesley, 1972. v Ian Sommerville, Software Engineering, 6th edition. Addison-Wesley, 2000. v Grady Booch, James Rumbach, Ivar Jacobson, The Unified Modeling Language. Addison-Wesley 1999.
16
Software Process
Fundamental Assumption: Good processes lead to good software Good processes reduce risk
17
Risk Management
What can go wrong in a software project? How can the risk be reduced?
18
The Software Process (Simplified)
Feasibility and Planning
Requirements
Design
Implementation
Operation and Maintenance

19
The Waterfall Model

Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance 20
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: v v v v Feasibility study (often carried out separately) Requirements analysis Requirements definition Requirements specification
21
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 v Unified Modeling Language (UML)
22
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.
23
Integration and System Testing
The individual program units are: v integrated and tested as a complete system v tested against the requirements as specified v delivered to the client
24
Operation and Maintenance

v Operation: The system is put into practical use. v Maintenance: Errors and problems are identified and fixed. v Evolution: The system evolves over time as requirements change, to add new functions or adapt the technical environment. v Phase out: The system is withdrawn from service.
25
Discussion of the Waterfall Model
Advantages: v v v v 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.
26
Feedback in the Waterfall Model

Iterative Refinement (Evolutionary Development)

Concept: Initial implementation for user comment, followed by refinement until system is complete. v Vaporware: user interface mock-up v Throw-away software components v Dummy modules v Rapid prototyping v Successive refinement
28
Iterative Refinement
Evaluation Requirements
Implementation (prototype)
Design
29
Concurrent Activities Requirements Outline Description Design Initial Version Intermediate Versions Final Version
Implementation
30
Iterative Refinement & Software Process

Concurrent Activities Outline Description Requirements Design
Implementation
Final Version
31
When is iterative refinement appropriate?
32
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)
33
Design Issues: v Pictorial subprograms: coordinate systems, window/viewport v User specification of perspective Design Strategy: (Iterative Refinement) v Write a series of prototypes with various proposed semantics v Evaluate with a set of programming tasks
34

Phase 1: Implementation (Waterfall) v When the final specification was agreed, the entire preprocessor and run-time support were recoded. v The system was almost entirely bug-free. Phase 2: New compiler (Waterfall) Phase 1 was used as the requirements definition for the final version.
35
Observations about Software Processes
Completed projects should look like the Waterfall Model but ... the development process is always partly evolutionary. Risk is lowered by: v Prototyping key components v Dividing into phases v Following a visible software process v Making use of reusable components
36
Lecture 3
(a) Feasibility Study (b) Requirements Definition
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
38
Where are the risks? How can they be minimized?
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.
39
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?
40
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]
41
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

42
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?
43
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?
44
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
45
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.
46
Requirements Definition and Analysis

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.
48
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
49
The Repository
Repository
Users
Identification System
Search System
50
Storage and Representation of Complex Objects

Data Several representations: thumbnail image reference image archival image Metadata Each representation may have its own metadata
51
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.
52
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

53
Bad Discoveries During Prototype
Resistance to change within Library of Congress Technical weakness of Library of Congress Gaps in CNRI architecture
54
Mistakes
Confusion of objectives (research and implementation) Failure to involve all stakeholders Over-ambitious (no proper feasibility study)
55
The Requirements Process

Feasibility Study Requirements Analysis Requirements Definition Feasibility Report System Models Definition of Requirements Requirements Specification
Requirements Document
Specification of Requirements 56
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
57
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).
58
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)
59
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 Handle resolution
60
NOW
FUTURE
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++)
61
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).
62
Lecture 4
Management I: Project Management
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
64
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
65
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.]
66
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
67
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.
68
Scheduling: Critical Path Method
An activity
A dummy activity
An event
A milestone
69
Critical Path Method
other activities
START
Revise Unit 3
Edit Unit 3
Print Unit 3
Mail Unit 3
END
70
other activities
START
Revise Unit 3
Edit Unit 3
Typeset Unit 3
Print Units 3/4
Mail Units 3/4
other activities
Revise Unit 4
Edit Unit 4
Typeset Unit 4
71
Script TV 2
START
Edit Unit 3 Edit Unit 4
Make TV 2 Mail Delivery
Document Computer 1
Program Computer 1
72
Prototype Computer 1
Time Estimates for Activities (Weeks)
4 6 1 12 12 4 4
73
1 3 1 3 1 2
Earliest Start Dates
1 1 12 12 0 4 4 12 12 3
4 15 2 17 3 3 17 4 2 19 3
26 6 1 22 1 2 17
74
23
25
Latest Start Dates
11 1 12 12 0 12 14 4 13 3
4 15 2 17 3 3 17 4 2 20 3
26 6 1 23 1 2 17
75
24
25
Critical Path
1/11 12/12 0/0 12/14 4/13 17/17 19/20 17/17
76
26/26 15/15 17/17 22/23 23/24 25/25
Slack
1/11 10 10 12/12 0/0 0 0 15/15 0 0 19/20 1 0 9 17/17
77
26/26 3 17/17 1 22/23 1 5 0 23/24 0 25/25 1
2 12/14 2 17/17 9 4/13
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?
78
Key Personnel: Schedule for Editor

Earliest Start Date Weeks 15-16 Weeks 17-18 Weeks 19-20 Weeks 21-22 Week 15 Week 17 Week 19 Week 21 Weeks 18-19 Week 22 Activity Edit Unit 3 Edit Unit 4 Edit Unit 5 Edit Unit 6 Review draft of Unit 7 Review draft of Unit 8 Check proofs of Unit 3 Check proofs of Unit 4 Vacation Out sick
79
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.
80
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)
81
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 Midterm exam Design Project presentations Final examination
Group Group/individual Individual Group/individual Group Individual
Details are subject to change.

83
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
84
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
85
Form of Documentation
External Printed Web site Internal Program documentation Program context (e.g., copyright notices)
86
Requirements Definition and Analysis


Specification of Requirements 88
Requirements Analysis
1. Understand the requirements in depth: Domain understanding Examples: science research, application Stakeholders Example: companies, ministries, Danang City
89
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
90
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.
91
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
92
3. Model the requirements: Informal Prose Systematic Procedural models Data-centric models Object models Formal models
93
Procedural Models: Flowchart
Operation Decision Manual operation Report

94
Flowchart: University Admissions
Form received
New? T Database record Notify student
Update database
Complete? T F Notify student
Evaluate
95
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()
96
Data-Flow Models
External entities Processing steps Data stores or sources Data flows

97
Example: University Admissions
Rejection Application Completed form Receive application Evaluate application Applicant Offer
98
Example: University Admissions Assemble Application Stage

Acknowledgment Application form Applicant Supporting information Pending database Applicant database
99
Acknowledgment
AND
Receive
Completed application
Initiate evaluation
Evaluation request
AND
Example: University Admissions Process Completed Application Stage

Rejection Evaluation request Evaluation Special request Applicant database
Acceptance
Financial aid
Offer
100
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.
101
Lecture 6
(a) Requirements Analysis (continued) (b) Requirements Specification

Specification of 103 Requirements
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.
104
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
105
Entity-Relation Diagram
An entity A relation between entities An entity or relation attribute An inheritance relation

106
Example: CS 501 Project

Major 1 Student Project 0:n 1 CS501 Student 5 to 7 Member of
107
Client 0:n Person 0:n Tech contact
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)
108
Entity-Relation Diagram for MARC

0:n 0:n Editor of 0:n 0:n
Book 1 Describes 0:n Catalog record
Author of 0:n Creator
1:n
Is about
Subject heading
Short title
Control numb
109
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.
110
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.
111
Non-Functional Requirements
Product requirements performance, reliability, portability, etc... Organizational requirements delivery, training, standards, etc... External requirements legal, interoperability, etc...
112
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
113
Unspoken Requirements
Example: Resistance to change at XXX
114
Requirements Specification
What is the purpose of the Requirements Specification?
115
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)
116
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
117
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!
118
Requirements Specification: Approaches
Natural language Structured natural language Design description language Requirements specification language Graphical notation Formal specification See Sommerville, Chapter 7.
119
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 technical world. Jurisdictions: Vietnamese laws International treaties Federal and state statues Precedents Supreme Court Cost of establishing precedent
121
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/
122
Copyright
A copyright gives the owner the exclusive right to: reproduce distribute perform display license Gradually extended to cover text, music, photographs, designs, software, ...
123
Copyright
Copyright at creation Works for hire Contracts and licenses First sale Fair use Infringement (contamination)
International differences Moral rights Copyright registration
124
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.
125
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
126
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.
127
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
128
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!
129
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!
130
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.
131
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)
132
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 ...
133
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
134
Hourly rate = $100,000 /1,250 = $80
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
135
Fixed and Variable Costs: Profit or Loss

$15M
$10M
$5M
2,500
5,000
7,500
Unit sales 136
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
137
Open Source
Free redistribution Source code Derived works Integrity of the author's source code No discrimination against persons or groups
138
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
139
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!
140
Source Code Management Or Configuration Management: How I learned to Stop Worrying and Hate My Co-workers Less
141
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
142
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 Youll end up doing something equivalent anyway so it may as well be automated
143
Source Code Management Tools Are Not

A substitute for project management A replacement for developer communication
144
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
145
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
146
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
147
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)
148
Locking
Only one person can work on a file at once Works fairly well if developers work on different areas of the project and dont 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
149
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
150
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
151
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
152
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
153
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
154
RCS
File management only Transaction model check out and lock edit check in and unlock Little support for binaries
155
CVS
Built on top of RCS Therefore little support for binaries Database can be remote No locking: merge before commit Fast Integrates with emacs
156
SourceSafe
Microsofts entry into the field Project-based Checkout-edit-checkin model Built-in web site creation tools Integrates with MSDEV
157
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
158
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
159
More Clearcase Features

Integrates with MSDEV Build Management Knows to rebuild out-of-date files even if your makefile doesnt Slow and a bit buggy
160
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)
161
Lecture 10
Formal Specification
Why? Precise standard to define and validate software Why not? May be time consuming Methods not suitable for all applications
163
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
164
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 = 21 Bk-1 = k ... 21 The numerical accuracy must be such that, for all k, BkBk-1 - I <
165
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
166
Formal Specification Using Diagrams

unsigned integer digit
unsigned number unsigned integer . digit E
+ unsigned integer 167
Two Rules
Formal specification does not guarantee correctness Formal specification does not prescribe the implementation
168
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 a : N
intrt(a) * intrt(a) < a < (intrt(a) + 1) * (intrt(a) + 1)

169
Example: Algorithm
1 + 3 + 5 + ... (2n - 1) = n2
170
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; }
171
Finite State Machine
A broadly used method of formal specification: Event driven systems (e.g., games) User interfaces Protocol specification etc., etc., ...
172
Finite State Machine
Example: Therapy control console [informal description]
173
State Transition Diagram

Select field Enter Patients Fields Enter Setup (ok) Ready Stop (interlock) Select patient
174
Start Beam on
State Transition Table
Select Select Enter Patient Field Patients Fields Patients Setup Patients Fields Ready Patients Fields Beam on Fields Setup
ok
Start
Stop interlock
Ready Beam on Setup Ready Setup 175
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

176
Z Specification (continued)
control = no_change transitions s}
no_change = { s : STATE; e : EVENT (s, e) transitions = { (patients, enter) (fields, select_patient) fields,
patients, (fields, enter)
setup, fields,
(setup, select_patient) patients, (setup, select_field) (setup, ok) ready,
(ready, select_patient) patients, (ready, select_field) fields, (ready, start) beam_on, (ready, interlock) setup, (beam_on, stop) ready, (beam_on, interlock) setup }
177
Schemas
Schema: The basic unit of formal specification. Describes admissible states and operations of a system.
178
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.
179
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.
180
LibSys
Level of Detail: Assume given sets: Copy, Book, Reader Global constant: maxloans
181
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!
182
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
183
Domain and Range
dom m x
ran m y
m:X
Y y} y}
184
dom m = { x X : y Y x ran m = { y Y : x X x
Operation: Issue a Book

Issue stock, stock' : Copy Book issued, issued' : Copy Reader shelved, shelved': F Copy readers, readers' : F Reader c?: Copy; r? :Reader [See next slide]
185
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?} 186 stock' = stock; readers' = readers
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
187
Schema Inclusion
LibDB stock : Copy Book readers: F Reader
LibLoans issued : Copy Reader shelved : F Copy r : Reader #(issued > {r}) < maxloans shelved dom issued =
188
Schema Inclusion (continued)

Library LibDB LibLoans dom stock = shelved dom issued ran issued readers
189
Schema Decoration
Issue Library Library' c? : Copy; r? : Reader c? shelved; r? readers #(issued > {r?}) < maxloans issued' = issued {c? r?} stock' = stock; readers' = readers
190
Schema Decoration
Issue Library c? : Copy; r? : Reader c? shelved; r? readers #(issued > {r?}) < maxloans issued' = issued {c? r?} stock' = stock; readers' = readers
191
The Schema Calculus

Schema inclusion Schema decoration Schema disjunction: ^ AddCopy = AddKnownTitle AddNewTitle Schema conjunction: ^ AddCopy = EnterNewCopy AddCopyAdmin Schema negation Schema composition
192
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 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? 194
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.
195
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.
196
The Waterfall Model

Requirements Definition System and Software design Implementation and Unit Testing Integration and System Testing Operation and Maintenance 197
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.
198
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
199
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
200
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.
201
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.
202
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.
203
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.
204
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.
205
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.
206
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.
207
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.
208
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.
209
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.
210
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.
211
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.
212
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.
213
The HelloWorld Example
class name HelloWorld
operations paint()
214
Abstraction for HelloWorld
class name HelloWorld annotation operations paint() g.drawString ("HelloWorld", 0, 10)"
215
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
216
Class Diagram
Applet generalization HelloWorld
Note that the Applet and Graphics classes are shown elided.
paint()
dependency Graphics
217
Class Inheritance Diagram

Object Panel interface Component ImageObserver Applet Container HelloWorld
218
Packaging Classes
java HelloWorld applet package
Graphics
awt
lang
219
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. 220
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? 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, ...)
222
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?
223
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?
224
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.
225

226
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
227
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
228
Operations
LibraryMember LibraryMember MemberOfStaff MemberOfStaff Item not needed yet.
borrows returns borrows returns
Copy Copy Journal Journal
229
Class Diagram
MemberOfStaff LibraryMember
1 on loan 0..12 Journal Copy
1 on loan 0..* is a copy of 1..* 1

230
Book
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?
231
RetailStore Order Merchant Product Warehouse Invoice Shipment

232

RetailStore name address contactInfo financialInfo Merchant Warehouse Order Product Reversals Invoice damaged() return() wrongItem() Responsibilities -track status of shipped products responsibility (text field)
Shipment
233
Expanding a Class: Modeling Financial Information
RetailStore
association 1 * Transaction
Which class is responsible for the financial records for a store?
Payment Invoice
234
Modeling Invoice
Shipment
???
RetailStore invoiceRecord
goodsShipped
Invoice invoiceNumber PartsList
adornments +goodsShipped() + public -sendInvoice() - private

235
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.
236
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.
237
Component Diagram
executable component hello.hml HelloWorld.class
hello.java
hello.jpg
238
Actor and Use Case Diagram
BookBorrower
An actor is a user of a system in a particular role. An actor can be human or an external system.
Borrow book
A use case is a a task that an actor needs to perform with the help of the system.
239
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.
240
Use Cases for Borrowing Books
Borrow copy of book BookBorrower Return copy of book Reserve book Extend loan
241
Relationships Between Use Cases: <<uses>>
Extend loan BookBorrower Borrow copy of book
<<uses>> Check for reservation <<uses>>
242
Relationships Between Use Cases: <<extends>>
BookBorrower
<<extends>> Borrow copy of book
Refuse loan
243
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
244
Lecture 13
Object-Oriented Design III
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?
246
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
247
Bouncing Ball Diagrams

Example: http://www.cs.cornell.edu/ domain name TCP connection HTTP get
248
Client
Servers
Actions on Objects
returnCopy(c) call okToBorrow() return send create destroy status notifyReturn(b) <<create>> <<destroy>> stereotypes
249
local
asynchronous signal
Links
LibraryMember 1 Copy
on loan association
0..*
+borrowCopy() +returnCopy() class
message borrowCopy(c) c:Copy link

250
libMem:LibraryMember object
Sequence Diagram: Change in Cornell Program

:MEngStudent Cornellian 1 : getName() 1.1 : name 2: new PhDStudent(name) 3: <<destroy>> sequence numbers added to messages :PhDStudent
251
Sequence Diagram: Borrow copy of a Book

libMem: LibraryMember BookBorrower borrow(theCopy) okToBorrow borrow borrow theCopy:Copy theBook:Book
252
Class Inheritance Diagram

Object Panel interface Component ImageObserver Applet Container HelloWorld
253
Sequence Diagram:Painting Mechanism
:Thread run run
:Toolkit
:ComponentPeer
target:HelloWorld
callbackLoop
handleExpose paint
254
Activity Diagram: Process Modeling

Release work order branch [materials not ready] Reschedule [materials ready] Assign tasks
255
guard expression
Activity Diagram: Parallel Activities

start state Decompress fork
Stream video join stop state
Stream audio
256
State Diagram
returned()
not borrowable
returned() borrowable borrowed()[last copy] borrowed()[not last copy]
guard expression
State diagram for class Book

257
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.
258
Component Diagram
executable component hello.hml HelloWorld.class
hello.java
hello.jpg
259
Components and Classes
agent.dll
AgentAction Policy
PatternSearch
260
agent.dll Realizes AgentAction PatternSearch Policy extended component

261
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.
262
Interfaces
simulation.exe IRender dependency interface
render.java
realization
263
Application Programming Interface (API)

API is an interface that is realized by one or more components. simulation.exe IRender
IModels
ILighting
264
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.
265
Lecture 14
System Architecture I Data Intensive Systems
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)
267
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)
268
Example 1: Electricity Utility Billing

First attempt:
Transaction
Data input
Master file
Bill
Each transaction handled as it arrives.

269
Criticisms of First Attempt

Where is this first attempt weak?
The requirements have not been specified!!!
270
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.,
271
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
272
Batch Processing: Validation
errors Incoming transactions Data input read only Edit & validation Validated transactions
Master file
273
Batch Processing: Master File Update
Validated transactions in batches
errors Sort by account Master file update
Reports
Bills
Instructions 274
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
275
Online Inquiry
Customer service read only
Transactions
Data input
Master file
Bills
276
Example 2: A Small-town Stockbroker
Transactions Received by mail or over telephone For immediate or later action Complex customer inquiries Highly competitive market
277
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)
278
Database Architecture
Products & services database
Customer & account database
External services
279
Real-time Transaction
Real-time transactions
External services
280
Real-time Transactions & Batch Processing

Real-time transactions Data input Batch processing
External services
281
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?
282
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.
283
Merger of Two Banks: Options
???
???
284
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.
285
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
286
Network Choices
Public Internet: Ubiquitous -- worldwide Low cost Private network: Security Predictable performance Choice of protocols (e.g., IBM's SNA)
287
Quality of Network Services
Performance Maximum throughput Variations in throughput Real-time media (e.g., audio) Business Suppliers Trouble shooting and maintenance Upgrades
288
Firewall
Public 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
289
Private network
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 detail -- will be used to validate the implementation Requirements, not design Precise, but not legalistic
291
Sequence Diagram: Notation

libMem: LibraryMember BookBorrower borrow(theCopy) okToBorrow borrow borrow theCopy:Copy theBook:Book dotted line shows object lifetime
rectangle shows focus of control

292
Sequence Diagram: Branching

libMem: LibraryMember BookBorrower 1:borrow(theCopy) 2:okToBorrow [not ok]3:noborrow [ok]3:borrow 4:borrow branch
293
theBook:Book theCopy:Copy
Example: Distributed Database
two copies of the same data
294
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.
295
Example: Broadcast Search

Databases
User
User interface server
296
Example: UseNet
297
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)
298
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.
299
Firewall
300
Private network
The Domain Name System

First attempt to resolve www.cs.cornell.edu 1 2 3 cornell.edu server cs.cornell.edu server
301
.edu server
Discussion of the First Attempt

Problems?
302

Better method
local DNS server 1 2 3
.edu server cornell.edu server cs.cornell.edu server

303
almaden.ibm.com cornell.edu Local ece.cmu.edu cache ibm.com acm.org .edu
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
304
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
305
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.
306
Example: Autonomous Land Vehicle
GPS Steer Sonar Model Laser Sensors Signal processing Control signals Throttle Controls
307
Other Applications
Response critical Network router Telephone switch Seat bag controller
Shared systems Multi-user data processing Time sharing

308
Techniques
Special purpose hardware Multi-threading and multi-tasking Parallel processing => digital signal processing
Interrupts => levels and priorities
309
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
310
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

311
Timing
Timing mechanisms Synchronous (clocked) -- periodic stimuli Asynchronous -- wait for next signal
Example: Communications protocols may be synchronous or asynchronous
312
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
313
Distinction between hardware and software may be blurred.
Example: Dartmouth Time Shared System

master processor Communications processor Communications processor Central processor Central processor Central processor
314
I/O Mulitplexor
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
315
Example: CD Controller
4 Input block 7 6 5
3 2
1 Output block
Circular buffer
316
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.

317
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
318
Lecture 15
System Architecture II Distributed and Real Time Systems
Administration
Assignment 2: Requirements Grades -- presentation, report, individual Comments at presentation Comments from teaching assistant
Assignment 3: Design
320
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
321
Sequence Diagram: Notation

libMem: LibraryMember BookBorrower borrow(theCopy) okToBorrow borrow borrow theCopy:Copy theBook:Book dotted line shows object lifetime
rectangle shows focus of control

322
Sequence Diagram: Branching

libMem: LibraryMember BookBorrower 1:borrow(theCopy) 2:okToBorrow [not ok]3:noborrow [ok]3:borrow 4:borrow branch
323
theBook:Book theCopy:Copy
Example: Distributed Database
two copies of the same data
324
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.
325
Example: Broadcast Search

Databases
User
User interface server
326
Example: UseNet
327
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)
328
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.
329
Firewall
330
Private network

First attempt to resolve www.cs.cornell.edu 1 2 3 cornell.edu server cs.cornell.edu server
331
.edu server
Discussion of the First Attempt

Problems?
332

Better method
local DNS server 1 2 3
.edu server cornell.edu server cs.cornell.edu server

333
almaden.ibm.com cornell.edu Local ece.cmu.edu cache ibm.com acm.org .edu
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
334
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
335
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.
336
Example: Autonomous Land Vehicle
GPS Steer Sonar Model Laser Sensors Signal processing Control signals Throttle Controls
337
Other Applications
Response critical Network router Telephone switch Seat bag controller
Shared systems Multi-user data processing Time sharing

338
Techniques
Special purpose hardware Multi-threading and multi-tasking Parallel processing => digital signal processing
Interrupts => levels and priorities
339
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
340
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

341
Timing
Timing mechanisms Synchronous (clocked) -- periodic stimuli Asynchronous -- wait for next signal
Example: Communications protocols may be synchronous or asynchronous
342
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
343
Distinction between hardware and software may be blurred.
Example: Dartmouth Time Shared System

master processor Communications processor Communications processor Central processor Central processor Central processor
344
I/O Mulitplexor
Software Considerations
345
Example: CD Controller
4 Input block 7 6 5
3 2
1 Output block
Circular buffer
346

347
Routers and Other Network Computing
348
Lecture 16
System Architecture III Distributed Objects
Real-Time: Software Considerations
350
Buffering Example: CD Controller
4 Input block 7 6 5
3 2
1 Output block
Circular buffer
351

352
Example: Routers and Other Network Computing

353
Example: Transaction Monitor
messages
Transaction monitor
processes
A transaction monitor: monitors transactions, routes them across services, balances the load, restarts transactions after failure.
354
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
355
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 356
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.
357
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)
358
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
359
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 ...
360
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
361
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
362
Object Request Broker (ORB)
C IDL
C++ IDL Client
Cobol Objects
Java
Other IDL
IDL Interface IDL
Server
Object Request Broker

363
Interface Definition Language

module <identifier> { <type declarations>; <constant declarations>; <exception declarations>; interface <identifier> [:<inheritance>] { See next slide } interface <identifier> [:<inheritance>] { ..... } { Naming context
Define a class
Define a class
364
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]; .... }
365
ORB: Programmer's View

Client Invoke a on object X Invoke a on object Y Server Object X a Object Y a

366
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)
367
ORB: System View
Interface repository
Client
Object Implementation implementation repository
Dynamic Client IDL ORB invocation stubs interface
Static Dynamic Object skeletons invocation adapter

368
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
369
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.
370
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. 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 372 speed by one mile per hour.
State Transition Diagram

A MS-On A Off Standby A Engaged C B-Brake MS-Off
373
Standby1
State Transition Table
MS on Off Standby Engaged Standby1 Standby
MS off
B Brake
Off Off Off
Engaged Engaged Standby1 Engaged Engaged Engaged

374
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?
375
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)
376
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?
377
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
378
Question 4
You work free-lance for company X. When you finish, who owns your work?
What use can you make of the work?
379
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
380
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.
381
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?
382
Iterative Design
Evaluation Requirements
Implementation (prototype)
Design
383
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
384
Levels of Usability
interface design conceptual model functional design data and metadata computer systems and networks
385
The Conceptual Model
The conceptual model is the user's internal model of what the system provides: The desk top metaphor -- files and folders The web model -- click on hyperlinks The library model -- search and retrieve The form filling model -- fill form, submit Example: The Mercury page turner
386
Interface Design
The interface design is the appearance on the screen and the actual manipulation by the user Fonts, colors, logos, key board controls, menus, buttons Mouse control or keyboard control? Conventions (e.g., "back", "help") Example: Screen space utilization in the Mercury page turner
387
Principles of Interface Design

Interface design is partly an art; there are general principles: Consistency -- in appearance, controls, and function. Feedback -- what is the computer system is doing? why does the user see certain results? Users should be able to interrupt or reverse actions Error handling should be simple and easy to comprehend Skilled users offered shortcuts; beginners have simple, well-defined options The user should feel in control
388
Disabilities
What if the user: is visually impaired or color blind? does not speak English? is a poor typist? There is a tradition of blind programmers Navigation of web sites need not be only visual You may have a legal requirement to support people with disabilities
389
Functional Design
The functional design, determines the functions that are offered to the user Selection of parts of a digital object Searching a list or sorting the results Help information Manipulation of objects on a screen Pan or zoom
390
Same Functions, Different Interface
Example: The desk top metaphor Mouse -- 1 button (Macintosh), 2 button (Windows) or 3 button (Unix) Close button -- left of window (Macintosh) right of window (Windows)
391
Data and Metadata

Data and metadata stored by the computer system enable the functions and the interface The desktop metaphor has the concept of associating a file with an application. This requires a file type to be stored with each file: -- extension to filename (Windows and Unix) -- resource fork (Macintosh) Data validation often requires that a user interface has access to a database (e.g., names and addresses)
392
Computer Systems and Networks

The performance, reliability and predictability of computer systems and networks is crucial to usability Response time instantaneous for mouse tracking and echo of key stroke 5 seconds for simple transactions Example: Pipelined algorithm for the Mercury page turner Quality of Service for real time information
393
Design Tensions in Networked Systems
Client computers and network connections vary greatly in capacity Client software may run on various operating systems; it may be current or an earlier version System designers wish to control clients; users wish to configure their own environments
394
Usability and Cost

Performance may be expensive in hardware or special software development User interface development may be a major part of a software development project Costs are multiplied if a user interface has to be used on different computers or migrate to different versions of systems Web browsers provide a general purpose user interface that others maintain
395
Extensibility in Web Browsers

Data types: helper applications, plug-ins Protocols HTTP, WAIS, Gopher, FTP, etc. proxies Executable code CGI scripts at server JavaScript at client Java applets Style sheets
396
Lecture 18
Design for Usability II
Q5: Object Oriented Design
A system generates weather maps using data collected from unattended weather stations. Each weather station collects meteorological data and produces summaries of the data. On request, it sends the summary information to an area computer. The area computer uses a database of digitized maps to generate a set of local weather maps.
398

399
Q5: Noun Identification
A system generates weather maps using data collected from unattended weather stations. Each weather station collects meteorological data and produces summaries of the data. On request, it sends the summary information to an area computer. The area computer uses a database of digitized maps to generate a set of local weather maps.
400
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
401
Q5: Candidate Classes

System WeatherMap Data WeatherStation MeteorologicalData DataSummary AreaComputer Database DigitizedMap same as MeteorologicalData is this a general term? how does this relate to WeatherStation? how does this relate to DataSummary? hardware general term
402
general term
Q5: Observations about the Candidate Classes

WeatherMap WeatherStation MeteorologicalData DataSummary DigitizedMap Can Meteorological Data be an attribute of WeatherStation? Can DataSummary be combined with WeatherMap?
403
is a DigitizedMap is derived from 1...* DataSummary has a set of MeteorologicalData
is derived from MeteorologicalData
Q5: Attributes and operations

WeatherStation location metereologicalData collectData() getSummary() DigitizedMap location geographicData printMap() WeatherMap location date-time geographicData weather gatherData() printMap() Or should MetereologicalData be a separate object?
404
Class Diagram
MemberOfStaff LibraryMember
1 on loan 0..12 Journal Copy
1 on loan 0..* is a copy of 1..* 1

405
Book
Q5: Class Diagram

DigitizedMap
WeatherStation location metereologicalData collectData() getSummary() 1 summary
WeatherMap location date-time geographicData weather gatherData() printMap()

406
1...*
Command Line Interfaces

User interacts with computer by typing commands Allows complex instructions to be given to computer Facilitates formal methods of specification & implementation Skilled users can input commands quickly Requires learning or training Can be adapted for people with disabilities Can be multi-lingual Suitable for scripting / non-human clients
407
Direct Interaction
User interacts with computer by manipulating objects on screen Can be intuitive and easy to learn Users get immediate feedback Not suitable for complex interactions Does not require typing skills Straightforward for casual users, slow for skilled users Icons can be language-independent Difficult to build scripts Only suitable for human users
408
Design for Direct Manipulation
Conceptual models, metaphors, icons => there may not be an intuitive model Navigation around large space
Conventions are growing over the years => scroll bars, buttons, help systems, sliders => good for users, good for designers
409
Menus
Easy for users to learn and use Certain categories of error are avoided Enables context-sensitive help Major difficulty is structure of large menus Scrolling menus (e.g., states of USA) Hierarchical Associated control panels Menus plus command line Users prefer broad and shallow to deep menu systems
410
Information Presentation
Information to be displayed Presentation software
Display
411
Information Presentation
Text precise, unambiguous fast to compute and transmit Graphics simple to comprehend uses of color shows variations
412
Help System Design

Help system design is difficult! Must prototype with mixed users Categories of help: => Overview and general information => Specific or context information => Tutorials (general) => Cook books and wizards => Emergency ("I am in trouble ...") Must have many routes to same information Never blame the user!
413
System Considerations of User Interfaces

Personal computer cycles are there to be used Any network transfer involves delay
Shared systems have unpredictable performance Data validation often requires access to shared data
Mobile code poses security risks
414
Usability and Cost

Performance may be expensive in hardware or special software development User interface development may be a major part of a software development project
Costs are multiplied if a user interface has to be used on different computers or migrate to different versions of systems Web browsers provide a general purpose user interface that others maintain
415
Extensibility in Web Browsers

Data types: helper applications, plug-ins Protocols HTTP, WAIS, Gopher, FTP, etc. proxies Executable code CGI scripts at server JavaScript at client Java applets Style sheets
416
Web User Interface: Basic
Web browser Static pages from server
Web servers
All interaction requires communication with server

417
Web User Interface: CGI Script
User interface tables CGI Scripts Web browser Web servers
Scripts can configure pages Scripts can validate information All interaction requires communication with server
418
Web User Interface: JavaScript
html Java Script Web browser
User interface tables CGI Scripts Web servers
JavaScripts can validate information as typed Some interactions are local Server interaction constrained by web protocols
419
Web User Interface: Applet
Any server Applets Web browser Web servers
Any executable code can run on client Client can connect to any server
420
Device-Aware User Interfaces

Examples of devices: desk-top computer, fast network connection laptop computer, intermittent connectivity PalmPilot, intermittent use of cradle Smart telephone Digital camera, camcorder Device-aware user interfaces are aware of: => Performance of device => Connectivity
421
The Importance of Design

Good support for users is more than a cosmetic flourish Elegant design, appropriate functionality, & responsive system: => a measurable difference to their effectiveness A system that is hard to use: => users may fail to find important results, or mis-interpret what they do find => user may give up in disgust
A computer system is only as good as the interface it provides to its users

422
Lecture 19
Performance of Computer Systems
Moore's Law
Original version: The density of transistors in an integrated circuit will double every year. (Gordon Moore, Intel, 1965) Current version: Cost/performance of silicon chips doubles every 18 months.
424
Moore's Law and System Design
Design system: Production use: Withdrawn from production: Processor speeds: Memory sizes: Disk capacity: System cost:
2000 2003 2013 1 1 1 1 1.9 1.9 2.2 0.4 28 28 51 0.01
425
Moore's Law: Rules of Thumb

Planning assumptions: Every year: cost/performance of silicon chips improves 25% cost/performance of magnetic media improves 30% 10 years = 100:1 20 years = 10,000:1
426
Parkinson's Law
Original: Work expands to fill the time available. (C. Northcote Parkinson) Planning assumptions: (a) Demand will expand to use all the hardware available. (b) Low prices will create new demands. (c) Your software will be used on equipment that you have not envisioned.
427
False Assumptions
Unix file system will never exceed 2 Gbytes (232 bytes). AppleTalk networks will never have more than 256 hosts (28 bits). GPS software will not last 1024 weeks. Nobody at Dartmouth will ever earn more than $10,000 per month. etc., etc., .....
428
Moore's Law and the Long Term

What level? Within your working life?
1965
2000?
When?
429
Predicting System Performance
Mathematical models Simulation Direct measurement All require detailed understanding of the interaction between software and systems.
430
Queues
arrive
wait in line
service
depart
Single server queue
431
Queues
service arrive wait in line depart
Multi-server queue
432
Mathematical Models
Queueing theory Good estimates of congestion can be made for singleserver queues with: arrivals that are independent, random events (Poisson process) service times that follow families of distributions (e.g., negative exponential, gamma) Many of the results can be extended to multi-server queues.
433
Utilization: Rule of Thumb
mean service time utilization = mean inter-arrival time When the utilization of any system component exceeds 30%, be prepared for congestion.
434
Behavior of Queues: Utilization
mean delay
utilization 0 1
435
Simulation
Model the system as set of states and events advance simulated time determine which events occurred update state and event list repeat Discrete time simulation: Time is advanced in fixed steps (e.g., 1 millisecond) Next event simulation: Time is advanced to next event Events can be simulated by random variables (e.g., arrival of next customer, completion of disk latency) 436
Timescale
Operations per second CPU instruction: Disk latency: read: Network LAN: dial-up modem: 400,000,000 60 25,000,000 bytes 10,000,000 bytes 6,000 bytes
437
Measurements on Operational Systems
Benchmarks: Run system on standard problem sets, sample inputs, or a simulated load on the system. Instrumentation: Clock specific events.
438
Serial and Parallel Processing
Single thread v. multi-thread e.g., Unix fork Granularity of locks on data e.g., record locking Network congestion e.g., back-off algorithms
439
Example: Performance of Disk Array
Each transaction must: wait for specific disk platter wait for I/O channel signal to move heads on disk platter wait for I/O channel pause for disk rotation read data Close agreement between: results from queueing theory, simulation, and direct measurement (within 15%).
440
The Software Process

Lecture 20 Coding Standards Tools for Debugging 1

442
Coding Standards
Or How to Pound all of your odd-shaped programmers into a one size fits all hole
I think there may be a bug in Joes Code - Please Fix

func GreenEggsNHam(Not SamIAm, Green EggsNHam) foreach Green TryThem in SamIAm do EatThem(TryThem) = false NotInACarNotOnABus(EggsNHam) func NotInACarNotOnABus(Green EggsNHam) EatThem(EggsNHam) = true NotOnAPlane(EggsNHam) foreach NotLikeThem SamIAm of EggsNHam do if not EatThem(SamIAm) then NotInACarNotOnABus(SamIAm) IDoNotLikeThem(EggsNHam)
444
Joes Code Following a Sane Coding Standard . . .

func DepthFirstSearch(graph G, vertex v) foreach vertex w in G do Encountered(w) = false RecursiveDFS(v) func RecursiveDFS(vertex v) Encountered(v) = true PreVisit(v) foreach neighbor w of v do if not Encountered(w) then RecursiveDFS(w) PostVisit(v)
445
What are Coding Standards

Coding standards are guidelines for code style and documentation.
The dream is that any developer familiar with the guidelines can work on any code that followed them. Standards range from a simple series of statements to involved documents.
446
Areas Typically Covered

Program Design Naming Conventions Formatting Conventions Documentation Possibly Even Licensing
447
Why Have Coding Standards

Greater consistency between developers Easier to develop and maintain Saves time and money
448
Prime Directive
Document every time you violate a standard. No standard is perfect for every application, but failure to comply with your standards requires a comment
449
Amblers Law of Standards

Industry Standards > organizational standards > project standards > no standards The more commonly accepted a standard the easier it is for team members to communicate Invent standards when necessary, but dont waste time creating something that you wont be able to use later. All languages have recommended coding standards available. It is well worth your effort to find and use industry standards Push for organizational standards whenever possible
450
Good Coding Style

Names Use full English descriptors Use mixed case to make names readable Use abbreviations sparingly and consistently Avoid long names Avoid leading/trailing underscores Documentation Document the purpose of every variable Document why something is done not just what
451
Accessors
use getVar() and setVar() functions on all class variable unless class is being used solely as a data structure (OOP) Member Functions Documentation What and why member function does what it does Parameters / return value How function modifies object Preconditions /Postconditions Concurrency issues Restrictions Internal Documentation Control Structures Why as well as what the code does Difficult or complex code Processing order
452
Three Rules
Coding standards neednt be onerous - find a standard that works for your team. Standardize early - the effort to bring your old work into the standard will be too great otherwise. Encourage a culture where standards are followed.
453
Examples of Coding Standards

http://www.ambysoft.com/javaCodingStandards.html http://www.swtech.com/java/codestd/ http://ccs.hst.nasa.gov/ccspages/policies/standards/coding_standar ds.html http://www.scriptics.com/doc/styleGuide.pdf
454
Lecture 21
Dependable Systems I Reliability
Software Reliability
Failure: Software does not deliver the service expected by the user (e.g., mistake in requirements) Fault: Programming or design error whereby the delivered system does not conform to specification Reliability: Probability of a failure occurring in operational use. Perceived reliability: Depends upon: user behavior set of inputs pain of failure
456
Reliability Metrics
Probability of failure on demand Rate of failure occurrence (failure intensity) Mean time between failures Availability (up time) Mean time to repair Distribution of failures
Hypothetical example: Cars are safer than airplane in accidents (failures) per hour, but less safe in failures per mile.
457
Reliability Metrics for Distributed Systems
Traditional metrics are hard to apply in multi-component systems: In a big network, at a given moment something will be giving trouble, but very few users will see it. A system that has excellent average reliability may give terrible service to certain users.
There are so many components that system administrators rely on automatic reporting systems to identify problem areas.
458
User Perception of Reliability
1. A personal computer that crashes frequently v. a machine that is out of service for two days. 2. A database system that crashes frequently but comes back quickly with no loss of data v. a system that fails once in three years but data has to be restored from backup. 3. A system that does not fail but has unpredictable periods when it runs very slowly.
459
Cost of Improved Reliability

$
Up time 99% 100%
Will you spend your money on new functionality or improved reliability?

460
Specification of System Reliability

Example: ATM card reader Failure class Example Metric 1 per 1,000 days 1 in 1,000 transactions Never
Permanent System fails to operate non-corrupting with any card -- reboot Transient System can not read non-corrupting an undamaged card Corrupting A pattern of transactions corrupts database
461
Principles for Dependable Systems
The human mind can encompass only limited complexity: => Comprehensibility => Simplicity => Partitioning of complexity
462
Principles for Dependable Systems
High-quality has to be built-in => Each stage of development must be done well => Testing and correction does not lead to quality => Changes should be incorporated into the structure
463
Quality Management Processes
Assumption: Good processes lead to good software The importance of routine: Standard terminology (requirements, specification, design, etc.) Software standards (naming conventions, etc.) Internal and external documentation Reporting procedures
464
Quality Management Processes
Change management: Source code management and version control Tracking of change requests and bug reports Procedures for changing requirements specifications, designs and other documentation Release control
465
Design and Code Reviews
Colleagues review each other's work: can be applied to any stage of software development can be formal or informal The developer provides colleagues with: documentation (e.g., specification or design), or code listing talks through the work while answering questions Most effective when developer and reviewers prepare well
466
Benefits of Design and Code Reviews

Benefits: Extra eyes spot mistakes, suggest improvements Colleagues share expertise; helps with training An occasion to tidy loose ends Incompatibilities between modules can be identified Helps scheduling and management control Fundamental requirements: Senior team members must show leadership Must be helpful, not threatening
467
Process (Plan) Reviews

Objectives: To review progress against plan (formal or informal) To adjust plan (schedule, team assignments, functionality, etc.) Impact on quality: Good quality systems usually result from plans that are demanding but realistic Good people like to be stretched and to work hard, but must not be pressed beyond their capabilities.
468
Statistical Testing
Determine the operational profile of the software
Select or generate a profile of test data Apply test data to system, record failure patterns
Compute statistical values of metrics under test conditions
469
Statistical Testing
Advantages: Can test with very large numbers of transactions Can test with extreme cases (high loads, restarts, disruptions) Can repeat after system modifications Disadvantages: Uncertainty in operational profile (unlikely inputs) Expensive Can never prove high reliability
470
Example: Dartmouth Time Sharing (1980)

A central computer serves the entire campus. Any failure is serious. Step 1. Gather data on every failure 10 years of data in a simple data base Every failure analyzed: hardware software (default) environment (e.g., power, air conditioning) human (e.g., operator error)
471

Step 2. Analyze the data. Weekly, monthly, and annual statistics Number of failures and interruptions Mean time to repair Graphs of trends by component, e.g., Failure rates of disk drives Hardware failures after power failures Crashes caused by software bugs in each module
472
Step 3. Invest resources where benefit will be maximum, e.g., Orderly shut down after power failure
Priority order for software improvements Changed procedures for operators Replacement hardware
473
Factors for Fault Free Software

Precise, unambiguous specification Organization culture that expects quality
Approach to software design and implementation that hides complexity (e.g., structured design, object-oriented programming) Use of software tools that restrict or detect errors (e.g., strongly typed languages, source control systems, debuggers) Programming style that emphasizes simplicity, readability, and avoidance of dangerous constructs Incremental validation
474
Error Avoidance
Risky programming constructs Pointers Dynamic memory allocation Floating-point numbers Parallelism Recursion Interrupts
All are valuable in certain circumstances, but should be used with discretion
475
Defensive Programming
Murphy's Law: If anything can go wrong, it will.
Defensive Programming: Redundant code is incorporated to check system state after modifications Implicit assumptions are tested explicitly
476
Defensive Programming Examples
Use boolean variable not integer
Test i <= n not i = = n Assertion checking
Build debugging code into program with a switch to display values at interfaces Error checking codes in data, e.g., checksum or hash
477
Some Notable Bugs

Built-in function in Fortran compiler (e0 = 0) Japanese microcode for Honeywell DPS virtual memory The microfilm plotter with the missing byte (1:1023) The Sun 3 page fault that IBM paid to fix Left handed rotation in the graphics package Good people work around problems. The best people track them down and fix them!
478
Lecture 22
Dependable Systems II Validation and Verification
Defensive Programming
Murphy's Law: If anything can go wrong, it will.
Defensive Programming: Redundant code is incorporated to check system state after modifications Implicit assumptions are tested explicitly
480
Defensive Programming Examples
Use boolean variable not integer
Test i <= n not i = = n Assertion checking
Build debugging code into program with a switch to display values at interfaces Error checking codes in data, e.g., checksum or hash
481
Terminology
Fault avoidance Build systems with the objective of creating faultfree systems Fault tolerance Build systems that continue to operate when faults occur Fault detection (testing and validation) Detect faults before the system is put into operation.
482
Fault Tolerance
Basic Techniques: After error continue with next transaction Timers and timeout in networked systems Error correcting codes in data Bad block tables on disk drives Forward and backward pointers Report all errors for quality control
483
Fault Tolerance
Backward Recovery: Record system state at specific events (checkpoints). After failure, recreate state at last checkpoint. Combine checkpoints with system log that allows transactions from last checkpoint to be repeated automatically.
484
Fault Tolerance
General Approach: Failure detection Damage assessment
Fault recovery Fault repair N-version programming -- Execute independent implementation in parallel, compare results, accept the most probable.
485
Validation and Verification
Validation: Are we building the right product? Verification: Are we building the product right? In practice, it is sometimes difficult to distinguish between the two. That's not a bug. That's a feature!
486
Cleanroom Software Development

Software development process that aims to develop zero-defect software. Formal specification Incremental development with customer input Constrained programming options Static verification Statistical testing
It is always better to prevent defects than to remove them later. Example: The four color problem.
487
Static and Dynamic Verification
Static verification: Techniques of verification that do not include execution of the software. May be manual or use computer tools. Dynamic verification Testing the software with trial data. Debugging to remove errors.
488
Static Validation & Verification
Carried out throughout the software development process. Validation & verification
Requirements specification
Design
Program
489
Static Verification: Program Inspections

Program reviews whose objective is to detect faults Code may be read or reviewed line by line. 150 to 250 lines of code in 2 hour meeting. Use checklist of common errors.
Requires team commitment, e.g., trained leaders So effective that it can replace unit testing
490
Inspection Checklist: Common Errors

Data faults: Initialization, constants, array bounds, character strings Control faults: Conditions, loop termination, compound statements, case statements Input/output faults: All inputs used; all outputs assigned a value Interface faults: Parameter numbers, types, and order; structures and shared memory Storage management faults: Modification of links, allocation and deallocation of memory Exceptions: Possible errors, error handlers
491
Static Analysis Tools

Program analyzers scan the source of a program for possible faults and anomalies (e.g., Lint for C programs). Control flow: loops with multiple exit or entry points Data use: Undeclared or uninitialized variables, unused variables, multiple assignments, array bounds Interface faults: Parameter mismatches, non-use of functions results, uncalled procedures Storage management: Unassigned pointers, pointer arithmetic
492
Static Analysis Tools (continued)
Cross-reference table: Shows every use of a variable, procedure, object, etc. Information flow analysis: Identifies input variables on which an output depends. Path analysis: Identifies all possible paths through the program.
493
Test Design
Testing can never prove that a system is correct. It can only show that (a) a system is correct in a special case, or (b) that it has a fault. The objective of testing is to find faults. Testing is never comprehensive. Testing is expensive.
494
Testing and Debugging

Testing is most effective if divided into stages: Unit testing at various levels of granularity tests by the developer emphasis is on accuracy of actual code
System and sub-system testing uses trial data emphasis is on integration and interfaces Acceptance testing uses real data in realistic situations emphasis is on meeting requirements
495
Acceptance Testing
Alpha Testing: Clients operate the system in a realistic but non-production environment Beta Testing: Clients operate the system in a carefully monitored production environment Parallel Testing: Clients operate new system alongside old production system with same data and compare results
496
The Testing Process

System and Acceptance Testing is a major part of a software project It requires time on the schedule It may require substantial investment in datasets, equipment, and test software. Good testing requires good people!
Management and client reports are important parts of testing. What is the definition of "done"?
497
Testing Strategies
Bottom-up testing. Each unit is tested with its own test environment. Top-down testing. Large components are tested with dummy stubs. user interfaces work-flow client and management demonstrations Stress testing. Tests the system at and beyond its limits. real-time systems transaction processing
498
Test Cases
Test cases are specific tests that are chosen because they are likely to find faults. Test cases are chosen to balance expense against chance of finding serious faults. Cases chosen by the development team are effective in testing known vulnerable areas. Cases chosen by experienced outsiders and clients will be effective in finding gaps left by the developers. Cases chosen by inexperienced users will find other faults.
499
Test Case Selection: Coverage of Inputs

Objective is to test all classes of input Classes of data -- major categories of transaction and data inputs. Cornell example: (undergraduate, graduate, transfer, ...) by (college, school, program, ...) by (standing) by (...) Ranges of data -- typical values, extremes Invalid data, reversals, and special cases.
500
Test Case Selection: Program

Objective is to test all functions of each computer program Paths through the computer programs Program flow graph Check that every path is executed at least once Dynamic program analyzers Count number of times each path is executed Highlight or color source code Can not be used with time critical software
501
Program Flow Graph
if-then-else
loop-while
502
Fixing Bugs
Isolate the bug Intermittent --> repeatable Complex example --> simple example Understand the bug Root cause Dependencies Structural interactions
Fix the bug Design changes Documentation changes Code changes
503
Moving the Bugs Around

Fixing bugs is an error-prone process! When you fix a bug, fix its environment
Bug fixes need static and dynamic testing Repeat all tests that have the slightest relevance (regression testing) Bugs have a habit of returning! When a bug is fixed, add the failure case to the test suite for the future.
504
Regression Testing
Applied to modified software to provide confidence that modifications behave as intended and do not adversely affect the behavior of unmodified code. Basic technique is to repeat entire testing process after every change, however small.
505
Real Time Software Development

Testing and debugging need special tools and environments Debuggers, etc., can not be used to test real time performance Simulation of environment may be needed to test interfaces -- e.g., adjustable clock speed General purpose tools may not be available
506
Software Engineering for Real Time

The special characteristics of real time computing require extra attention to good software engineering principles: Requirements analysis and specification Development of tools
Modular design Exhaustive testing Heroic programming will fail!

507
Some Notable Bugs

Built-in function in Fortran compiler (e0 = 0) Japanese microcode for Honeywell DPS virtual memory The microfilm plotter with the missing byte (1:1023) The Sun 3 page fault that IBM paid to fix Left handed rotation in the graphics package Good people work around problems. The best people track them down and fix them!
508
Staying Out of Prison in the Information Economy
Lecture Caveats
I am not a lawyer and do not have any formal legal training This lecture is made up of my observations of the legal system to make you aware of important issues concentrating on an information technology workplace Cardinal Rule: Be aware of the law, but always consult an attorney if/when you become involved with it.
510
Law Caveats
Some people read the text of the law and think they know it. Things are never so easy. If you have questions ask a lawyer. Others ignore the law relying on corporate lawyers in case something goes wrong. This is not a good idea. As in any other system, catching problems in the design phase is always better than in the debugging phase.
511
Talk Overview
Life for Lawyers Vs. Life for Engineers Patents, copyright, trademarks, trade secrets reviewed Defamation ISP Liability Privacy Jurisdiction Issues
512
Life for Computer Professionals

Binary
Problem solutions either work or not. Little room for gray areas.
Physical and mathematical laws ultimate authority when disputes arise Guiding Philosophy - Tell me what you need and I will create a system with appropriate trade-offs at least cost to solve your problem.
513
Life for Lawyers

Gray
Effort and intent often matter as much as results

Supreme court ultimate authority when disputes arise Guiding Philosophy - Laws are passed based on how society should run - even if enforcement and legal interpretation issues have yet to be nailed down.
514
When Worlds Collide . . .

Legal community always behind the technology curve Lawyers and politicians typically have poor technical backgrounds As a result, analogies often made between new technological paradigms and old world systems - some more easily defended than others. Different interpretations would result in different laws
515
Patents
Embodiment of a specific methodology Competing products must use different method for achieving same task to avoid payments Definite lifespan beyond which patent information freely available for use by the public
516
Copyright
Specific work Automatically held when work is created, but easier to defend if it is registered Definite lifetime beyond which the work is freely available to the public
517
Trademark
Specific name or phrase Generic terms cannot be trademarked Trademarks can be lost if they are not defended
Lost trademarks: aspirin, kleenex Held Trademarks: Coke, Pepsi
518
Trade Secrets
Does not expire - as long as it is kept secret Competitors may not use secrets obtained through extraordinary means Example: Walled chemical plant layout learned through helicopter use
519
Defamation
Publishing damaging statements you cannot prove about others The publisher and author are both liable Slander is a less serious, but similar, crime where damaging statements that cannot be proven are made in a public arena
520
Bally Total Fitness Vs. Faber

A Bally Sucks web site was created by Faber complaining about Bally fitness centers The trademarked Bally seal was placed on the site overlaid with the words Sucks Bally sued Faber making claims of trademark infringement, dilution, and unfair competition.
521
Bally Case Decision

No trademark infringement - little possibility of confusion No dilution - the defendant did not sell a competing product and did not convey confusion about the authors identity No dilution (lessening ability of the plaintiffs mark to identify its goods and services) since defendant was not marketing a competing product Incidentally - no slander, negative opinions protected under the first amendment
522
ISP Liability
What is an Internet Service Provider Like?
Phone Company: Route information flows between individuals Newspaper: Package content for distribution in a public forum
Answer determines ISPs legal liability The rules have been in a constant state of flux in recent years
523
Ancient History (~Decade Ago)

Defamatory posting on Prodigy (Stratton Oakmont Vs. Prodigy Services 1995)
Prodigy a large ISP Claimed to be family friendly. Prodigy advertised that internal newsgroups monitored for bad/inappropriate language Role of a publisher - hence, Prodigy like a newspaper CompuServe did not monitor users activity - like a telephone company (Cubby Inc. Vs. CompuServe Inc. in 1991)
524
Modern Era Communications Decency Act

ISP may monitor user activity (according to policy) If statement to the effect that ISP does not take responsibility for user traffic in place then no ISP liability, BUT
Area for complaints must be available Complaint response must happen in a timely fashion
525
DMCA
Digital Millennium Copyright Act If a copyright infringement is claimed a web site must be taken down (however tenuous the claim may be) Web site can only be reinstated after an appeals process.
526
Near Future? . . .
European Computer Crime Treaty may be created by the end of this year ISPs may be required to monitor user traffic with a 40 day data-log. ISPs not explicitly exempt from liability Hacker/Security Tools Illegal Citizens must provide passwords for data seized by police
527
Privacy in the Workplace

Test for employers/employees - Do you have a reasonable expectation of privacy? A case can be made that private e-mail on business machines still private, but this is not the law Work-related material on business machines is definitely not private
528
Privacy in E-mail
Legally, e-mail is like a postal letter
Expectation of privacy in transit Mail loses its special protected status once it leaves the letter carrier's grasp
For e-mail,
Expectation of privacy while signal travels over Internet E-mail loses its protected status at the mail server whether you have read it or not
529
Spam and Address Spoofing

Matthew Seidl v. Greentree Mortgage Co. (1998) Greentree hired third party to send mass e-mail to potential customers (spam) Return address spoofed to read nobody@localhost.com (an actual address) Over 7,000 complaints sent to nobody resulting in denial of service for 3 days Libel case dismissed since third party was a contractor. Likely that third party would, in fact, be vulnerable to a lawsuit.
530
Business E-mail
Electronic Communications Privacy Act (1986) says all business communication belongs to that business Deleting e-mail can be ruled spoliation (intentionally destroying company records) Archive worthless if it cannot be indexed effectively (in effect, saving everything can be equivalent to saving nothing)
531
What about Privacy at Home?

A lot of public information is considered private. An increasing amount of public information available on the Internet Reverse phone lookups Campaign Contributions Housing prices (Thwarted) Drivers license information and photographs
532
Data Collection
Data collection has few boundaries in U.S. Check privacy policy (can change!!) EU Safe Harbor agreement may change things in the future (TRUSTe web site privacy seal program)
533
Jurisdiction
The Internet has no boundaries Is that really true? If you break a law in Finland, but you were on the Internet in the United States, what happens to you? What if you are in California and you break a law in Minnesota?
534
E-Commerce Big Questions

Did you sell an illegal item to a resident of community X? Did you try to stop the flow of illegal sales into X? An easy example of where this might come up is found in the on-line pornography boom.
535
Obscene or Offensive?
Indecent speech and offensive speech protected under the 1st Amendment Obscene speech is not But what is obscene speech?
536
Miller Test for Obscenity

(1) Whether the average person applying contemporary community standards, would find that the work, taken as a whole, appeals primarily to prurient interest. (2) Whether the work depicts or describes, in a patently offensive way, sexual conduct specifically defined by applicable state law. (3) Whether the work, taken as a whole, lacks serious literary, artistic, political, or scientific value.
537
Federal Court System

94 US District Courts (89 in the 50 states) 13 Judicial Circuits, each with a court of appeals Supreme Court ultimate appellate court Jurisdiction can be a determining factor in case outcomes
538
US V. Thomas (1994)
Mr. And Mrs. Thomas ran a pornographic BBS in California State officer paid a membership fee and downloaded pornography in Tennessee Couple tried in Federal court in Tennessee and lost their case
539
International Jurisdiction
Extradition over civil suits unlikely Big Question #1: Do you have assets in the country in question? Big Question #2: Will you ever try to enter country X?
540
Godfrey Vs. Dolenga

Dolenga was a Cornell Biochemistry Masters student from British Columbia Godfrey, a nuclear physicist from London, made anti-Canadian remarks in a newsgroup Dolenga responded by flaming Godfrey Godfrey notified Cornell of the offensive remarks, but they were not removed (First Amendment) Godfrey filed defamation suits against Dolenga and Cornell in Britain (one of at least seven such cases)
541
Dolenga Did Not Defend Himself . . .

Dolenga was found guilty by default in English court BUT - Dolenga does not have assets in England and it is unlikely that American courts will enforce the British judgement.
542
Cornell Did Defend Itself

Cornell has assets in England (the Cornell abroad program) The suit was for roughly 80,000 pounds. The University could have settled, but chose to take the case to court The suit was brought to a successful conclusion (for Cornell) Lessons to be taken away from this . . .
543
Conclusions . . .
The law is constantly changing and never as simple as it seems You should try to be familiar with the law to protect yourself (corporate lawyers are like a fire department, not like a seeing eye dog) Even so, you DO need the help of someone with formal training when dealing with legal issues
544
Lecture 25
Management III Managing People
Administration
Return of laptops and wireless cards -> Dates for return will be announced on "Notices" -> All equipment must be returned before the examination. Bring the receipt to the exam. -> If an extension granted, (e.g., independent research) must return and be issued again If any repairs needed, please swap for replacement since warranty runs out on December 15.
546
Administration
Early examination December 7, 10:00 to 11:30, Upson 5130 Send email to rosemary@cs.cornell.edu if you plan to take the early examination, by December 5 All laptops and wireless cards must be returned before the examination
547
Managing People
Theoretical: Organizational behavior Industrial psychology Group behavior Cognitive fundamentals Economic motivation
548
Maslow's Hierarchy of Needs
Self-realization needs Esteem needs Social needs Safety needs Physiological needs
549
Software Engineering Basics

Professional staff are the major cost of software Professional staff vary greatly in productivity => Ability => Education and training => Motivation => Interaction with colleagues and leaders => Work environment People are productive when happy and happy when productive
550
Software is Built by Teams

Best size for a team is 3 to 8 people Team members may include: developers (from trainee to expert) domain experts graphic or interface designers software librarians testers Teams must have: administrative leadership (manager) technical leadership
551
Group Working
20% non-productive 50% interaction with others
30% working alone
552
Communication
Informal Kitchen, smokers' doorway, after work, etc. Walkabout (tours) Ad hoc meetings Staff meetings (non-technical) Example: Tektronics Technical meetings Facilitation Record of decisions
553
Administrative Leader (Manager)

Personnel Assigning tasks Hiring, promoting, etc. Resources Budgets Space, facilities Equipment Project management Relationships with other teams and clients Project plan and schedule
554
Hiring Criteria
Productivity is a combination of: Analytic ability Verbal ability and communication skills Education Application domain knowledge
Adaptability and inquisitiveness Personality and attitude Platform experience Programming language experience
555
Staff Retention
Technically interesting work up to date hardware and software opportunities to learn and experiment Feeling of appreciation management recognition money and promotion Working conditions space, light, noise, parking flexibility Organizational dynamics
556
Firmness
Managers must be firm when needed: Assignment of tasks must be equitable and open; everybody will have to tackle some of the dreary tasks Carrots are better than sticks, but poor performance must be addressed. Nobody is indispensable; nobody should be allowed to think that they are indispensable
557
Technical Challenges
Canceling projects Example: the Andrew window manager Changes of environment Example: the World Wide Web Technical tinkering v. needed re-engineering
558
Turning a Group Around

To turn a weak group into a strong one is the greatest challenge of leadership The art of the possible Promotion of the best over the old leaders Using opportunities to reorganize
Resignations and terminations Respect people who try, yet refuse to accept problem areas Brutal and abrupt rarely equals persistent and firm
559
How to be Led
As a junior member of a team, what can you do to make it productive?
560
Lecture 26
Risk in Software Engineering
Failures and Risks

Software development projects can fail in many ways: Bad software engineering Late, over budget Lack of function, full of bugs, bad performance Changing circumstances Changing markets Better alternatives Changes of management The biggest single source of problems is poor understanding of requirements
562
Managing Risk
Manage projects to avoid risk: Open and visible software process => Avoid surprises Continual review of requirements Willingness to modify or cancel projects
563
Canceling a Project
Example: Andrew Window Manager (wm) Technically superior to X (MIT's Athena project) in 1986 but ... Digital Equipment Corporation turning X into a product with massive support nobody ready to support wm Therefore wm cancelled in 1986, Andrew user interface and applications ported to X
564
Failure to Cancel a Project

Example: University F developed a novel programming language. From 1985 to 1989, this was a promising language for simple programming of window-based applications By 1990, clearly not gaining acceptance beyond University F But development continued for many more years (about $500K) Not cancelled because ...
565
Too Big to Cancel!

Example: University A has antiquated administrative systems. Senior management decides to replace them all with commercial packages from X. The timetable and budget are hopelessly optimistic. Staff get dispirited. The Chief Information Officer finds another job. A new Chief Information Officer is appointed. What should she do?
566
We are doing it the Wrong Way!

Example: University B has a (big) joint project with Company Y to develop a new computer operating system. After two years work, a junior software developer persuades the university leader that the technical approach is wrong. What should the university do? What should the company do?
567
How to Stop Gracefully

It is harder to cancel a project than to start it. It is harder to withdraw a service than introduce it. Considerations The proponents of the system must now reverse their public stance. => Management of expectations Users of the service need a migration strategy. Technical staff must have a graceful path forward.
568
Time to Complete a Software Project

Large software projects typically take at least two years from start to finish Formative phase -- changes of plan are easy to accommodate Implementation phase -- fundamental changes are almost impossible Yet many things can change in two years.
569
A Sense of Urgency
Example: A not-for-profit corporation is developing a system for a government organization. By 1996 all research had been completed and the system demonstrated successfully with real users. In 2000, the system is still not in full production Reasons: => Incremental improvements to the software => Repeated requests for more functionality => Reluctance to reorganize clerical staff Nobody had a sense of urgency
570
Overtaken by Events
Example: University C has a project to develop a digital library system, with funds from Company Z , private foundations and the government. By 1993 an extensive system is running at the university and Z is marketing the technology to its customers. By 1994 it is clear that web browsers and web formats (though technically weak) are becoming widely adopted. => What should the university do? => What should the company do?
571
Changing Requirements and Design

Example: The CNRI Handle System -- a high performance, distributed system to map names to resources (1994-99). In 1994 only web browser was Mosaic In 1994 Java did not exists In 1994 mirroring and caching utilities were not available In 1994 commercial interest was limited
Design decisions made in 1994 had to be changed. Software was rewritten and greatly improved in 1998/9. If a job's worth doing, it's worth doing twice!
572
Changes of Leadership
Many projects are wasted because of management changes Example: In 1988, Company W gave University D $1,000,000 to port a new operating system to its personal computers. The work was well done, on time. Company W changed its president and senior technical staff during the project. The work was wasted. A decade later and several presidents later, Company W is releasing a modern version of the same operating system. A graduate student from University D is now Senior Vice President of Company W!
573
Client Oversight
When work is out-sourced, the client must be vigilant. Example: Company G was the world's leader in software for optimization (e.g., linear and integer programming). G had implemented several packages for various manufacturers. An operating system Company H contracted with G to develop an optimization package for its new operating system. The package was late, performed badly and disliked by customers. What went wrong? What can we learn?
574
Too Difficult!
Example: A development team at University E was given government funds to build a high-performance gateway from protocol x to protocol y. A promising young developer was hired and assigned to this task The project was too difficult for him, but he hid his problems for many months. The project produced nothing of value. What can we learn from this experience?
575
Engineering and Marketing

Corporate engineering & marketing divisions at cross purposes: Examples: Xerox's Palo Alto Research Center pioneered window managers, Ethernet, graphical user interfaces, font managers, etc, => Apple, Adobe, Digital, etc. brought them to the market IBM would not bring its first Unix workstation to the market until the software had been largely rewritten => Sun's early workstations were unreliable but sold well
576
Senior Management Dynamics

Directors and shareholders appoint the President => The President does not want to admit failures The President appoints the Chief Information Officer => The CIO does not want to admit failures The CIO appoints the computing managers => The computing mangers do not want to admit failures The computing managers appoint the developers => The developers do not want to admit failure Everybody pretends that things are going well
577
Senior Management Dynamics

At last the troubles can not be hidden ... Directors and shareholders try to blame the President The President tries to blame the Chief Information Officer The CIO tries to blame the computing managers (and grumbles about the President) The computing managers try to blame the developers (and grumble about the CIO) The developers grumble about their managers What can we do better?
578
Sobering Thoughts
Major computing projects are very complex. Inevitably there are delays and failures. Few organizations know how to manage risk & uncertainty. The best CIO's => Manage to minimize risk => Have the confidence of their staff who keep them truthfully informed => Have the self-confidence to keep their seniors truthfully informed
579
Lecture 27
Software Engineering as Engineering
The Y2K Problem: Saving Memory
In 1967 memory cost $1 per byte The Air Force used single digit dates If 2-digit dates saved 1% of memory... savings over 20 years $16 to $24 million per gigabyte
581
The Y2K Problem: Saving Memory

By 1980s, memory was much cheaper, but 2-digit dates were standard. Why incur the cost of changing standards? 1970 The mortgage industry 1990 The Social Security Industry moved towards 4-digit dates On January 1, 2000 2-digit dates stopped working!
582
Where's the Problem?

A simple bug: dates of the form 19xx have been encoded xx A simple fix: find every occurrence of the bug modify the code recompile Where's the problem?
583
Find Every Occurrence ...

What computers do we use? data processing control embedded systems personal devices What programs do they run? in-house development packages and libraries firmware, microcode, hardware Who wrote this program? Where is the source code?
584
Where's the Problem?
Computers fail everyday. What's special about this bug? What if they all fail at the same time? What if we lose telephone, electricity, radio, etc.?
Traffic signals, elevators, The greatest worry was uncertainty.
585
Social Consequences
Worry creates its own problems: Wal-Mart forecast lower profits in Q1 2000
Legislation to limit law suits Opportunities for computer fraud and sabotage
Trading partners
586
Organizational Procedures
Ostrich => do nothing => buy insurance
Bureaucratic => fill in forms that programs are compliant Subcontract => hire Y2K specialists Do it yourself => in-house computing department
587
Y2K Validation
Request from Library of Congress to confirm that our code is Y2K compliant: Our code is fine .... but it depends on ... which depends on ... Yes. Our code is fine. Request from DARPA to confirm that our code is Y2K compliant: It's been validated by another part of the US government Thank you!
588
Technical Strategies
Replace noncompliant applications with compliant ones (e.g., new versions of packages) Repair noncompliant applications (e.g., in-house applications) Terminate noncompliant programs on an as-needed basis Mask the data exchange between applications Object code interception
589
New Bugs
If it's not broke don't fix it. 10 billion lines of code checked (often automatically) 10 million new bugs introduced accidentally ?? security holes, errors, etc. introduced accidentally or deliberately
590
Is all the Money Going to Y2K?

Y2K as a great excuse to have the computing budget increased: Upgrade the operating system
Replace the old package Sell something to your customers What boss will turn turn a request for Y2K funds? What systems administrators will not install Y2K upgrades?
591
Profiteering
Buy gold, wood stoves, bottled water Y2K specialists Pundits, consultants, writers Religious cranks
592
Final Thoughts on Y2K
We create computer systems that are more complex than our understanding of them: We over estimate our ability to validate systems We under estimate our ability to adapt and respond Software engineering usually thinks of systems as independent. Will the long-term benefit of the Y2K problem be a greater understanding of how software systems interact with each other and with our social systems?
593
The Need for Software Engineering
Software as a product: => Awkward to use => Full of errors => No chance to try it out => No guarantees Not much of a product
594
What is Engineering?
595
What is Engineering?
The profession of: ... creating cost-effective solutions ... ... to practical problems ... ... by applying scientific knowledge ... ... and established practices ... ... building things ... and taking responsibility for them!
596
Crafts, Science, Engineering
Science Production Commercial Craft Professional Engineering
From: Shaw and Garlan
597
Crafts, Science, Engineering

algorithms data structures Science Production software development methodologies Commercial compiler construction Professional Engineering
Craft
598
From: Shaw and Garlan
Software Engineering as Engineering?
Part craft -- part engineering Embryonic scientific basis Evolving body of knowledge Too much flux for the apparatus of a profession (e.g., accreditation) Example: Texas and the ACM
599
The End
Good process leads to good software: the limits of heroic efforts Minimize risks: visible process function v. time v. cost The importance of people Requirements, requirements, requirements!
600

Software Engineering New

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Software Engineering New

Caricato da

Copyright:

Formati disponibili

Software Engineering

Lecture 1 Introduction to Software Engineering

Characteristics of Software Products

Client (a.k.a Customer)

Variety of Software Products

Variety of Software Products

Lecture 2 The Software Process

The Software Process (Simplified)

Feasibility and Planning

Operation and Maintenance

The Waterfall Model

Requirements Analysis and Definition

System and Software Design

Programming and Unit Testing

Integration and System Testing

Operation and Maintenance

Discussion of the Waterfall Model

Advantages: v v v v Process visibility Dependence on individuals Quality control Cost control

Feedback in the Waterfall Model

Iterative Refinement (Evolutionary Development)

Iterative Refinement & Software Process

Iterative Refinement + Waterfall Model: Graphics for Basic

Iterative Refinement + Waterfall Model: Graphics for Basic

Iterative Refinement + Waterfall Model: Graphics for Basic

Observations about Software Processes

Where are the risks? How can they be minimized?

Get a good grade on CS 501

How to Minimize Risk?

Requirements Definition and Analysis

Example: Library of Congress (A Partial Failure)

Storage and Representation of Complex Objects

Repository: Research Achievements

Good Discoveries During Prototype

Boundaries of required repository system

Bad Discoveries During Prototype

The Requirements Process

Library of Congress Requirements Study

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 Handle resolution

The Aim of Project Management

The Project Manager

Project Planning Methods

Example: An Open University Course

Scheduling: Critical Path Method

Critical Path Method

Critical Path Method

Print Units 3/4

Mail Units 3/4

Critical Path Method

Edit Unit 3 Edit Unit 4

Make TV 2 Mail Delivery

Time Estimates for Activities (Weeks)

Earliest Start Dates

Latest Start Dates

26/26 15/15 17/17 22/23 23/24 25/25

26/26 3 17/17 1 22/23 1 5 0 23/24 0 25/25 1