Interaction, Concurrency & OOP in the Curriculum A Second-Year Course OOPSLA 1998 Educators’...
-
Upload
percival-mccarthy -
Category
Documents
-
view
215 -
download
0
Transcript of Interaction, Concurrency & OOP in the Curriculum A Second-Year Course OOPSLA 1998 Educators’...
Interaction, Concurrency & OOP in the Curriculum
A Second-Year Course
OOPSLA 1998 Educators’ Symposium
Christopher Colby Radha Jagadeesan
Konstantin Läufer Chandra Sekharan
Loyola University Chicago
Dept. of Mathematical and Computer Sciences
6525 N Sheridan Road
Chicago, Illinois 60626, USA
{colby,radha,laufer,chandra}@cs.luc.edu
http://www.cs.luc.edu/triveni/
3
Abstract
We argue that a computer-science curriculum should introduce the principles of concurrent programming in an integrated, coherent, and
application-independent fashion early in the major. We have incorporated current research into our
curriculum. We describe a second-year course on the fundamentals of concurrent and interactive programming that is the fruit of this work. We
offered this course to about 90 students in Fall 1997, Spring 1998, and Fall 1998.
4
The world is full of concurrent systems
• real-time systems• signal-processing systems• telecommunication systems• graphical user interfaces• operating systems• multiprocessors and pipelining• distributed systems
6
How sequential programming is usually taught
• At the foundation level• In introductory courses:
– structured programming– data abstraction– object-oriented programming– functional programming
• As a means for problem-solving
7
How concurrent programming is usually taught
• At the application level• In advanced courses:
– operating systems: threads in Nachos– networks: concurrency used in protocols– software engineering: concurrency in GUIs– computer architecture: concurrency in HW
• Not as a means, but as an end
8
A better approach: A new intro course in concurrency
• taught early in curriculum (second year)
• based on our current research in concurrency (Triveni)
• integrated
• coherent
• application-independent
9
Advantages• Programming methodology
– conceptual decomposition into concurrent modules
– pedagogically beneficial to expose students to concurrency before sequential programming becomes their primary way of thinking
• Specification, testing, verification– formal methods taught as an integral part of the
programming process– concurrent programming suitable motivation
10
Main ideas in concurrent programming
• Reactivity– systems are event-driven– systems interact continuously with environment– execution as bursts of activity in response to
events
• Asynchrony– processes loosely coupled– communication can take arbitrary time
11
Relevant research in concurrent programming
• Process algebras and synchronous programming languages– notion of abstract behavior– combinators on behaviors
• Temporal logic, testing, and verification– verifiable properties of reactive systems– automated verification based on model checking
13
Running theme: Battle game
• n-player variation of 2-player Battleship
• Oceans: each player has a collection of ships on one of n disjoint ocean grids
• Ships: each ship occupies a rectangular subgrid of a player’s ocean– battleships stay on surface, submarines can dive
• Moves: a player can move as fast as the user interface or his/her reflexes allow– shoot, move ship, dive submarine, raise shield
14
Interaction and concurrency and OOP in Battle
• Concurrency– decomposition: game into players and central
controller– abstraction: over nonessential dependencies among
independent user events– other issues: e.g. priorities
• OOP– inheritance for extending concurrent behavior:
submarine is-a ship with diving capabilities
15
Program correctness in Battle
• Safety properties: consistency– concurrent access to shared data: state of each
player
• Liveness properties: progress– each player must have a chance to proceed– actions of each player must eventually reach
controller and other players
• Nondeterminism: lack of repeatability– timing of shot vs. move
16
Integration into our curriculum• First year:
– CS170: Structured programming (now in Java)– CS271: Data structures (soon in Java)
• Second year:– CS272: Object-oriented prog. (Java/C++)– CS211: Discrete structures (FSMs, induction)– CS275: Computer architecture
• Prerequisites for Intro to Concurrency– CS272 and CS211– ensures data structures, algorithms, OOP, Java
17
Course modules
• (1) Specification– temporal logic– automata as specifications– generating test cases from specifications
• (2) Design of concurrent and interactive programs– process algebras– parallel composition as structuring mechanism– preemption: termination, suspension, interrupts
18
Course modules (cont.)
• (3) Case studies in Triveni
• (4) Implementation of concurrent programming languages– automata as abstractions of interaction– thread programming for managing concurrency
19
Programming assignments
• (1) Implement simple 2-player version of Battle using Java AWT– aim: intro to events and event handlers
• (2) Implement a framework for FSMs with combinators– aim: intro FSMs as abstractions of controllers
• (3) Implement a full-scale version of battle (group project)– aim: decomposition, temporal logic specs
20
Results and future work
• Course well-received and successful
• Now integral component of our undergraduate curriculum as an elective
• Considering migrating some modules into CS272 and CS375 (Software Engineering)
• Investigating idea of more in-depth two-semester sequence
• Investigating idea of introducing concurrency in first year
21
Our research contribution:
Triveni
A component model for concurrent programming with threads and events
22
Triveni: Overview• A component model for concurrent
programming that integrates:– thread-based programming (e.g. Java threads)– event-based programming– object-oriented programming
• Based on process algebras and synchronous programming languages
• Realized as a Java API - JavaTriveni library
• Joint work with Lalita J. Jagadeesan & Carlos Puchol, Bell Labs, Lucent Technologies
23
Motivation • Process algebras (e.g. CCS, CSP) and
synchronous programming (e.g. Esterel, Lustre, Statecharts)– key feature: notion of abstract behavior
• In a concurrent system, essentially the interaction of the system with its environment
– program combinators operate on behaviors and yield behaviors
– communication is via labeled events (that are abstractions of names of communication channels)
25
Basic Principle 1: Behaviors
• Programs can be combined freely with Triveni combinators– one need only be concerned about the desired
effects on the resulting behavior– implementation of Triveni yields the correct
combination of behaviors
26
The Triveni Combinators
• emit e, await e -> P, present e then P
• switch-valuator(e)
• rename [e1’/e1, e2’/e2, ...] in P
• local e1, e2, ... in P
• do P watching e, suspend P on e1 resume e2
• P1 || P2 (parallel composition)
• loop P, P1 ; P2 (seq. composition), done
• activity (code in host lang)
27
Basic Principle 1a: Parallel Composition
• Parallel composition can be used freely for the modular decomposition of designs– parallel-composed programs indistinguishable
from simple programs– correct wiring among events sent by parallel
components is done automatically by Triveni• implementation of program can closely reflect
design
• each parallel component can be implemented separately: Triveni realizes desired communication
28
Example: 5ESS Carrier Group Alarms
CollectionSoft ||RENAME [req1/req,resp1/resp] IN DataSoft1||…||RENAME [reqk/req,respk/resp] IN DataSoftk
Triveni pseudocode
summary requests
CGA Data1 CGA Data3CGA Data2
CGA Collection
req1 resp2 req3 resp3req1resp1restart restart
data to HMI
29
Basic Principle 1b: Preemption
• Exceptions are supported via preemption combinators– example: DO P WATCHING e– aid in program modularity
• Exceptions have first-class status– any event can be used in place of e
30
ExampleDataSoft = LOOP
DO AWAIT req ->
// collect threshold amount of data from beginning of database
EMIT resp(data); LOOP
AWAIT req -> // collect threshold amount of data from rest of database
EMIT resp(data);
WATCHING restart
Note: Event priorities achieved by nesting of preemption combinators restart has higher priority than req
31
Basic Principle 2: Integration
• Triveni is compatible with existing work in programming languages and concurrent systems– integration of previous principles with OOP– compatible with existing threads standards (e.g.
Java threads, Posix threads)– compatible with event models based on event
multicast patterns (e.g. Java Beans)– specification-based testing: automates testing of
safety properties
32
• Integration with OO Programming– Triveni processes are objects with enriched
state• reactive: interaction with environment via events
– communication with environment via event multicast
• autonomous: system clocks, timers– communication with environment via thread operations
– any objects that conform to these general requirements can be used as Triveni processes
Basic Principle 2a: Processes as Objects
33
Basic Principle 2b:Specification-based Testing
• Non-intrusive form of testing/debugging• Safety properties written in temporal logic
– all execution sequences that satisfy property
• Safety property (negation) automatically translated into a Triveni process
• Alerts user if property violated during a run of the system
• Example: No summary request should be honored when another one is running
34
Some Implementation Issues Handled by Triveni
• Parallel composition:– multiplicity of threads is hidden– fair scheduling
• Event multicast– atomicity of events– all parallel components see same event ordering– local events are hidden from components
outside their scope
35
JavaTriveni Implementation
• Implementation based on Petri Nets
• Java class library: – integrated with Java threads and objects– event model compatible with Java Beans
• Supports specification-based testing
• Formal semantic foundation for compositionality and fairness
36
5ESS Carrier Group Alarms Software
• Carrier groups are the connections between switches– malfunctions can result in disturbances in
telephone calls
• 5ESS Carrier Group Alarms Software responsible for reporting status changes on carrier groups
• Earlier case study: re-implemented CGA Software in Esterel programming language
37
JavaTriveni case study
• Re-implemented CGA Software in JavaTriveni– hierarchically nested parallel components– about 2500 lines of JavaTriveni code
summary requests
CGA Data1 CGA Data3CGA Data2
CGA Collection
req1 resp2 req3 resp3req1resp1restart restart
data to HMI
38
JavaTriveni case study (cont.)• Extensively used Triveni design principles
– JavaTriveni combinators– modularity in design and implementation greatly
aided by parallel composition and preemption operators
– objects + renaming + inheritance gives a convenient way to express variances
• Used specification-based testing to check whether CGA implementation satisfied some safety properties
39
Current and future Work
• Interaction of preemption and induced JavaTriveni priorities with Java exceptions and priorities
• Integration of JavaTriveni with distributed programming - Remote Method Invocation (RMI)
• Investigation of mobility
• More applications (e.g. user interfaces, interactive web services)