CS 141a Distributed Computation LaboratoryCourse Introduction

1
CS 141Distributed Computation Laboratory

• Instructors
• Professor Mani Chandy
• Email mani_at_cs.caltech.edu
• Office Hours TBA
• Dr. Dan Zimmerman
• Email dmz_at_cs.caltech.edu
• Office Hours TBA
• TAs
• TBA

2
Administrative Information

• Textbook Concurrent Programming in Java Second
  Edition, Lea, 2002.
• CS cluster account required to submit all
  assignments. Available from http//sysadmin.cs.cal
  tech.edu/.
• Course material, including lab assignments, is
  posted on the course web pages at
  http//www.cs.caltech.edu/cs141/.

3
Administrative Information

• Email
• All class-related email should be sent to
  cs141_at_cs.caltech.edu. Dont send class-related
  email to our individual email addresses unless we
  tell you to.
• Announcements are sent to a class mailing list.
• Be sure to write your email on the sheet of paper
  circulating around the room
• Usenet
• A Usenet newsgroup for general discussion -
  caltech.class.cs141 - is available on the Caltech
  news server (nntp-server.caltech.edu). We will
  monitor it, but not as closely as the
  cs141_at_cs.caltech.edu email address.

4
Coursework

• The coursework consists of 7 homework assignments
  (60 total) and 2 quizzes (20 each). These will
  be due on Wednesdays, and each will be available
  online by the Wednesday before it is due.
• Homeworks and quizzes cover theory, design, and
  implementation.
• Working in teams of up to 3 is allowed (and
  encouraged) on design assignments.
• On all other assignments, you may discuss the
  assignment with other students but all submitted
  work must be your own.

5
Grading

• All homeworks will include requirements on what
  must be submitted. These requirements may include
  specific filenames, style guidelines, etc.
• Any submission that does not fulfill these
  requirements will not be graded (and will
  therefore earn no points).
• All homework submissions will use an automated
  submission system, which also allows you to check
  your grades at any time, manage extensions, etc.

6
Grading

• Labs are due by 235959 on the due date.
• You start the term with six 24-hour extensions,
  to be distributed among your homeworks as you see
  fit.
• Up to three extensions may be applied to any
  homework.
• Extensions may not be applied to quizzes.
• For every two days you turn a homework in early,
  you earn an extra 24-hour extension.
• Late penalty is 20 for up to one day late (after
  applying extensions), 40 for up to two, 60 for
  up to three, etc.

7
Grading

• This course will heavily emphasize design. The
  more time you spend designing your programs, the
  less time you will have to spend implementing and
  debugging them.
• Grades on implementation assignments will reflect
  not only whether the implementations work, but
  also how well they are designed. Good design and
  correct operation will have approximately equal
  weight.

8
Prerequisites

• Knowledge of basic algorithms and data structures
  is required.
• Knowledge of object oriented programming is
  extremely useful, and experience with Java even
  more so. All implementation assignments are in
  Java.
• Other than some brief discussion this week, we
  arent going to teach Java or object oriented
  programming in this class.

9
Course Outline

• This Term
• (Briefly) Java and Object Orientation
• Threads and Thread Operations
• Design by Contract and Unit Testing
• Reasoning about Concurrent Systems
• Techniques for Distributed Algorithms
• Implementation assignments this term will
  simulate distributed systems on single machines
  using threads.

10
Course Outline

• Next Term
• Communication Mechanisms
• Security
• Current Technologies (XML, Web Services)
• Other Topics (to be determined)
• Implementation assignments next term will be real
  distributed systems built using current
  technologies.

11
Remainder of This Lecture

• Brief Overview of Distributed Systems Concepts
• Brief Introduction to Software Engineering,
  Object Orientation, and Java (to be continued
  Thursday)

12
Distributed Systems

• What exactly is a distributed system?
• Basic Definition A distributed system is a
  system that consists of multiple communicating
  processes.
• Examples of distributed systems
• CS department machines
• World Wide Web
• Electronic mail delivery system (SMTP)
• SETI_at_Home
• Massive multiplayer games

13
Why Distributed Systems?

• Primary goal to connect users and resources
• Benefits
• Economic savings
• Easier collaboration and information exchange
• Drawbacks
• Security issues (Microsoft and other virii,
  identity theft)
• Privacy issues (spam, surveillance)

14
Transparency

• End users and client applications shouldnt need
  to know whether (or how) a system is distributed.
• Various types of transparency
• Access transparency hides differences in data
  representation and how resources are accessed.
• Location transparency hides where resources are
  located.
• Migration transparency hides the fact that
  resources may change locations.
• Relocation transparency hides the fact that
  resources may be moved to other locations while
  in use.

15
Transparency

• More types of transparency
• Replication transparency hides replication of
  resources.
• Concurrency transparency hides concurrent access
  by multiple users.
• Failure transparency hides the failure and
  recovery of resources.
• Persistence transparency hides whether a resource
  is in memory or on disk.
• Complete transparency is often undesirable, and
  sometimes impossible.

16
Openness

• Distributed systems should offer services
  according to a set of standard syntactic and
  semantic rules.
• Interfaces
• Protocols
• Interoperability separate implementations of the
  same specification should work with each other
• Portability applications developed for one
  implementation should work on others as well

17
Openness

• Flexibility systems should be organized as
  collections of small component programs, not as
  monolithic programs.
• Components can be built concurrently by multiple
  developers.
• System can be changed without being completely
  rebuilt (or worse, completely rewritten).

18
Scalability

• Systems can scale in size, in geographical
  distribution, and in administrative complexity.
• Systems with centralized services, data or
  algorithms do not scale well.
• Scaling Techniques
• Hiding Communication Latency
• Distribution
• Replication

19
Example The Domain Name System

• Distribution of the Domain Name System

20
Software Engineering

• The process of creating software systems,
  consists of several phases
• Analysis - determination of what the software
  needs to do and what is necessary to do it
• Design - detailed specification of the
  architecture and interactions of the software
  components
• Implementation - translation of the design into
  code
• Testing - verifying that the implementation
  matches the design
• Maintenance - ensuring that the software
  continues to work and be understood as time goes
  by

21
Object Oriented Software Engineering

• In object oriented software engineering, we
  implement reusable components rather than
  monolithic systems.
• A consequence of this is that you will, in
  general, build on earlier homeworks in order to
  complete later ones.
• Guiding principles of object-oriented software
  engineering
• Modularity - the ability to build complex systems
  by putting together relatively simple components
• Reusability - the ability to use a single
  component in many different systems without
  changing it (much)

22
Modularity

• 5 Rules (Bertrand Meyer)
• Direct Mapping - modular structure of a system
  should always be compatible with the modular
  structure of the problem domain
• Few Interfaces - every module should communicate
  with as few other modules as possible
• Small Interfaces (Weak Coupling) - if two modules
  communicate, they should exchange as little
  information as possible
• Explicit Interfaces - whenever two modules
  communicate, it should be obvious from the
  program text of at least one of them
• Information Hiding - some subset of the modules
  properties must be the official information
  about how to interact with it

23
Reusability

• Modules should have abstract documentation - you
  should never need to look at their source code
• 5 Requirements (Bertrand Meyer)
• Type Variation - routines should be able to be
  used with different types without rewriting
• Routine Grouping - modules should have
  appropriate sets of routines
• Implementation Variation - families of modules
  should cover various possible implementations and
  algorithms

24
Reusability (Continued)

• Remaining 2 Requirements (Bertrand Meyer)
• Representation Independence - a client should be
  able to specify an operation on a reusable module
  without knowing exactly how it is implemented
• Factoring Out Common Behaviors - commonalities in
  data structures and algorithms should be
  exploited when implementing multiple modules

25
Classes and Objects

• The central concept of object oriented software
  engineering is (oddly enough) the class, not the
  object.
• A class is an abstract data type equipped with a
  possibly partial implementation, and usually
  corresponds to a particular type of thing in a
  system model.
• A banking system might have classes named
  Account, Withdrawal, Deposit
• A renderer might have classes named Vertex and
  Edge
• A granular flow simulator might have classes
  named Particle, Cell, State, and Force

26
Classes and Objects

• Classes are instantiated as objects. For example,
  an object instantiated from class Account would
  represent, and contain information about, a
  particular bank account.
• Classes have two basic kinds of feature
  attributes (also called fields) and methods (also
  called routines)
• An attribute is a feature that is represented by
  space - it is an actual piece of information
  stored in class instances
• A method is a feature that is represented by time
  - it is a computation applicable to all instances
  of a class

27
Example Two-Dimensional Points

• public class Basic2DPoint
• / Abscissa. /
• public double x
• / Ordinate. /
• public double y
• / Distance to origin (0, 0). /
• public double rho()
• return Math.sqrt(x x y y)

• / Angle to horizontal axis. /
• public double theta()
• return Math.atan2(x, y)
• / Move by (a, b). /
• public void translate
• (double a, double b)
• x x a
• y y b
• // end of class Point

28
The Current Instance (this)

• In the translate method, we moved a point by (a,
  b) by performing x a and y b, but never said
  which objects x and y we were changing.
• Classes describe objects of a certain type. The
  current instance of a class is the one described
  in the class text, and (in Java) we sometimes
  explicitly write it as this.
• So, our x a was equivalent to this.x this.a.
• Every action in an object-oriented system occurs
  relative to the current instance.

29
Constructors

• Classes usually have constructors, special
  methods that perform initialization tasks.
• In Java, these methods have no return value and
  have the same name as the class
• public Basic2DPoint(double initialX, double
  initialY)
• x initialX
• y initialY
• A class can have multiple constructors, as long
  as they have different signatures.

30
Information Hiding

• Allows a class to prevent details of its
  implementation from being used within other
  classes (important for modularity). Java has 4
  different levels of protection.
• public class S
• public f // this feature can be used by any
  client
• protected g // this feature can be used by
  clients that are
• // subclasses or classes in the same
  package
• h // this feature can be used by clients
  in the same
• // package (but not subclasses in other
  packages)
• private i // this feature cannot be used by
  clients

31
Next Class

• More Java and Object Orientation, Including
• Static Fields and Methods
• Abstract Classes and Interfaces
• Inheritance
• Casting
• Exceptions
• Packages and Imports
• Directories and Class Paths
• main() and Arguments
• Coding Standard
• Homework 1 Overview