Presentation is loading. Please wait.

Presentation is loading. Please wait.

Interaction, Concurrency & OOP in the Curriculum A Second-Year Course OOPSLA 1998 Educators’ Symposium.

Similar presentations


Presentation on theme: "Interaction, Concurrency & OOP in the Curriculum A Second-Year Course OOPSLA 1998 Educators’ Symposium."— Presentation transcript:

1 Interaction, Concurrency & OOP in the Curriculum A Second-Year Course OOPSLA 1998 Educators’ Symposium

2 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

3 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 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

5 5 What is wrong? How do students learn to build concurrent systems?

6 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 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 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 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 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 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

12 12 Our course: Introduction to Concurrency

13 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 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 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 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 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 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 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 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 21 Our research contribution: Triveni A component model for concurrent programming with threads and events

22 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 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)

24 24 Triveni: Computational Model objects in host lang Triveni process: finite state machine events

25 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 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 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 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 Data1CGA Data3CGA Data2 CGA Collection req1resp2req3resp3req1resp1 restart data to HMI

29 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 30 Example DataSoft = 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 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 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 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 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 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 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 37 JavaTriveni case study Re-implemented CGA Software in JavaTriveni –hierarchically nested parallel components –about 2500 lines of JavaTriveni code summary requests CGA Data1CGA Data3CGA Data2 CGA Collection req1resp2req3resp3req1resp1 restart data to HMI

38 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 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)


Download ppt "Interaction, Concurrency & OOP in the Curriculum A Second-Year Course OOPSLA 1998 Educators’ Symposium."

Similar presentations


Ads by Google