1 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, 23-04-2005 MTCoord'05 Roles as Coordination Construct: Introducing powerJava.

Slides:



Advertisements
Similar presentations
Introduction to Java 2 Programming
Advertisements

Construction process lasts until coding and testing is completed consists of design and implementation reasons for this phase –analysis model is not sufficiently.
Design by Contract.
Architecture Representation
Systems Analysis and Design 8th Edition
An Associative Broadcast Based Coordination Model for Distributed Processes James C. Browne Kevin Kane Hongxia Tian Department of Computer Sciences The.
Model-Based Programming: Executable UML with Sequence Diagrams By Ruben Campos Cal State L.A. Computer Science Thesis Work Spring 2007.
Object-Oriented Analysis and Design
Department of Computing
Adding Organizations and Roles as Primitives to the JADE Framework NORMAS’08 Normative Multi Agent Systems, Matteo Baldoni 1, Valerio Genovese 1, Roberto.
Page 1 Building Reliable Component-based Systems Chapter 7 - Role-Based Component Engineering Chapter 7 Role-Based Component Engineering.
Introduction To System Analysis and Design
1 Software Testing and Quality Assurance Lecture 12 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 5: Restaurant.
 2006 Pearson Education, Inc. All rights reserved Introduction to Classes and Objects.
Object-Oriented Databases v OO systems associated with – graphical user interface (GUI) – powerful modeling techniques – advanced data management capabilities.
1 SWE Introduction to Software Engineering Lecture 23 – Architectural Design (Chapter 13)
Object Oriented System Development with VB .NET
Software Testing and Quality Assurance
Unified Modeling Language (UML)
IMS1805 Systems Analysis Topic 3: Doing Analysis (continued from previous weeks)
Systems Analysis & Design Sixth Edition Systems Analysis & Design Sixth Edition Toolkit Part 5.
Communication in Distributed Systems –Part 2
 2008 Pearson Education, Inc. All rights reserved Introduction to Classes and Objects.
UML Sequence Diagrams Eileen Kraemer CSE 335 Michigan State University.
Institute for Software Research©2001, University of California, Irvine Product-Line Architectures André van der Hoek Institute for Software Research University.
The chapter will address the following questions:
UML Sequence Diagrams Michael L. Collard, Ph.D. Department of Computer Science Kent State University.
Chapter 7: The Object-Oriented Approach to Requirements
Object Oriented Software Development
Programming Languages and Paradigms Object-Oriented Programming.
CSM-Java Programming-I Spring,2005 Introduction to Objects and Classes Lesson - 1.
Object Oriented Analysis By: Don Villanueva CS 524 Software Engineering I Fall I 2007 – Sheldon X. Liang, Ph. D.
(C) 2009 J. M. Garrido1 Object Oriented Simulation with Java.
An Object-Oriented Approach to Programming Logic and Design
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
Unified Modeling Language, Version 2.0
Introduction To System Analysis and Design
CSE 425: Object-Oriented Programming I Object-Oriented Programming A design method as well as a programming paradigm –For example, CRC cards, noun-verb.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
ARTIFICIAL INTELLIGENCE [INTELLIGENT AGENTS PARADIGM] Professor Janis Grundspenkis Riga Technical University Faculty of Computer Science and Information.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Systems Analysis & Design 7 th Edition Chapter 5.
Systems Analysis and Design 8 th Edition Chapter 6 Object Modeling.
CSC480 Software Engineering Lecture 11 September 30, 2002.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
Roles and Coordination in powerJava M. Baldoni, G. Boella Dipartimento di Informatica, Università degli Studi di Torino (Italy) and L. van der Torre SEN3.
Logical view –show classes and objects Process view –models the executables Implementation view –Files, configuration and versions Deployment view –Physical.
Chapter 5: Distributed objects and remote invocation Introduction Remote procedure call Events and notifications.
CS451 - Lecture 2 1 CS451 Lecture 2: Introduction to Object Orientation Yugi Lee STB #555 (816) * Acknowledgement:
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Object vs Class composition By Marine Ruhamanya. Disciplined Inheritance  Problems with implementation inheritance: Encapsulation Fragile Base Class.
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
Chapter 5 Classes and Methods II Lecture Slides to Accompany An Introduction to Computer Science Using Java (2nd Edition) by S.N. Kamin, D. Mickunas, E.
CMSC 345 Fall 2000 OO Design. Characteristics of OOD Objects are abstractions of real-world or system entities and manage themselves Objects are independent.
Object Design More Design Patterns Object Constraint Language Object Design Specifying Interfaces Review Exam 2 CEN 4010 Class 18 – 11/03.
Object Oriented Programming and Data Abstraction Earl Huff Rowan University.
UML Fundamental Elements. Structural Elements Represent abstractions in our system. Elements that encapsulate the system's set of behaviors. Structural.
Basic Characteristics of Object-Oriented Systems
Topic 4: Distributed Objects Dr. Ayman Srour Faculty of Applied Engineering and Urban Planning University of Palestine.
Objects First with Java A Practical Introduction using BlueJ
Communication DIAGRAM
Software Architecture & Design Pattern
Programming Models for Distributed Application
Chapter 20 Object-Oriented Analysis and Design
Communication DIAGRAM
ISpec: A Compositional Approach to Interface Specification
Chapter 5.
Design Yaodong Bi.
Presentation transcript:

1 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, MTCoord'05 Roles as Coordination Construct: Introducing powerJava M. Baldoni 1, G. Boella 1, L. van der Torre 2 1 Dipartimento di Informatica Università degli Studi di Torino 2 SEN3 – CWI Amsterdam and Delft University of Technology

2 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, Data vs Control driven coordination ● Data-driven coordination (typical of OO): – computation evolves driven by the data involved in the coordination ● Control-driven coordination: – computation evolves according to events following state changes – Separation between coordination and computation (different processes) – Black-boxes with input/output interfaces – Dynamic reconfiguration

3 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, Coordination in OO model ● The introduction of coordination components in OO presents some difficulties [Arbab] ● Asimmetry: the caller must know the callee (syntax and semantics of the invoked methods) ● The control is passed to callee ● The “pluggability” of pre- existing components in a new system is reduced Object B Object A Message

4 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, Alternative view ● To use untargeted passive messages that do not imply method invocation ● For example by introducing channel ● The sender is not required to know the receiver a third party sets up the interaction between a sender and a receiver of its choice ● How to introduce this view preserving the OO characteristics? Object B Object A Message channel Message

5 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, Aim of the work ● Coordination models often refer to some metaphor: Shared dataspace, Blackboard model, Actor model, Chemical model, Channel model,... ● Aim of this work: To introduce the “role metaphor” in OO programming (Java) for allowing control-driven coordination ● powerJava: A proposal of extension of Java with roles

6 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, A proposal: the role metaphor ● It is a basic metaphor in social and organization theories ● Role often defined as the description of an expected behaviour ● Used to distribute responsabilities, obligations, and rights among the entities of an organization ● Playing a role means acquiring specific powers (given by the organization) ● For playing a role some requirements are needed ● Roles (as entities endowed with powers) are a means to coordinate the behavior within an organization

7 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, Our notion of role ● Definitional dependence: the definition of a role must be given inside the definition of the its institution ● Foundation: an instance of a role must always be associated with an instance of the institution it belongs to (besides being associated with its player) ● Institutional empowerment: the role actions can access the state of the institution

8 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, Use of roles ● Roles can be a means for improving the pluggability ● Simmetry vs asimmetry ● The institution and its roles play as the third party that controls the interaction ● The players will interact according to the acquired powers (they will follow the protocol implemented by the institution and its roles)

9 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, Introducing roles in Java: powerJava ● We define roles as instances associated at runtime to objects (their players) ● The extension of objects to roles is transparent to the programmer ● The language is extended preserving the characteristics of the original language to make its use natural to the Java programmer ● The current implementation requires a preprocessing (by JavaCC) step to produce a pure Java program

10 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, Introducing roles in Java ● A construct for defining roles as interfaces ● A construct that allows to implement a role inside an institution ● A construct to associate a role to an object ● A construct to allow a role to pass information to the players ● A construct to allow an object to play a role, i.e. to invoke the power

11 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, Role as “double” interface ● Role specification – Requirements: the methods required to a class playing the role (the “pluggability”) – Powers: the methods offered to objects playing the role ● The use of interfaces increases the modularity and the component-based programming [Steimann] powers requirements interface PhilosopherReq { void putData(... ); void processData(); } role Philosopher playedby PhilosopherReq{ void eat(); void think(); }

12 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, Role implementation as inner classes ● Role implementation – Java inner classes that implement the powers specified by the role definition – keyword “realizes” – keyword “that” ● A role implementation has access to the state of the institution (like inner classes w.r.t. outer classes) ● that is used to invoke methods (requirements) of the player role Philosopher playedby PhilosopherReq{ void eat(); void think(); } class Table { [...] class PhilosopherImpl realizes Philosopher { [...] public void eat() { [...] public void think() { that.processData(); }

13 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, Role instance creation ● Roles: created similarly to instances of inner classes ● Implicit parameter of type “requirements” (the player of the role) ● Each role instance has a reference to the instance of its institution, like an instance of an Java inner class has a reference to its outer class (directly provided by Java compiler) interface PhilosopherReq { void putData(... ); void processData(); } class Consumer implements PhilosopherReq { public void putData(... ) { [...] } public void processData() { [...] } [...] Consumer consumer = new Consumer(); [...] Philosopher phil = new table.PhilosopherImpl(consumer); [...]

14 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, Playing a role ● Role instances do not exist by themselves ● Role powers are invoked starting from the associated players ● Cast to a role: casting the player of a role to the role implementation instance it refers to (it is necessary to specify the institution the role belongs to) ● Delegation mechanism role Philosopher playedby PhilosopherReq{ void eat(); void think(); } [...] Consumer consumer = new Consumer(); [...] Philosopher phil = new table.PhilosopherImpl(consumer); [...] ((table.Philosopher) consumer).eat(); ((table.Philosopher) consumer).think(); ((table.PhilosopherImpl) consumer).myEat();

15 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, Overview ● Overall model using a UML class diagram ● Translation in pure Java by means of a pre-processor built by JavaCC (

16 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, An example: dining philosophers ● Resource: requires a method for getting data ● Consumer: requires methods for receiving and processing data ● Table: the coordination environment ● Philosopher: offers to the consumer the method to eat (grabbing two resources and getting data), think (using data), start the process and leave the table ● Chopstick: offers the method for being used table resource consumer philosopher chopstick

17 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, An example: dining philosophers ● The table is the coordination environment, coordination between resources and consumers is carried on through the roles ● Private methods for grabbing and realising chopsticks in a synchronized way ● Philosophers obtain chopsticks and use them table resource consumer philosopher chopstick

18 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, An example: dining philosophers ● Use chopsticks becomes getting data from the resources (that.getData()), invocation of a method from role to player (resource) ● The philosopher passes the obtained data (that.putData(...)) to the consumer, and releases the chopsticks (resources) ● The philosopher comunicates to the consumer that it can now process the data (that.processData()) table resource consumer philosopher chopstick

19 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, Summary of the example ● Sequence diagram of the dinning philosophers ● The coordination happens all inside the “table” throgh the roles table

20 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, powerJava pre-processesing ● JavaCC (Java Compiler Compiler) using Java grammar ● Role specifications are translated into interfaces ● Role implementations are traslated into inner classes whose constructors are extedend appropriately ● Players are modified in order to manage a list of roles ● Role casting is translated into an instruction that allows to find the corresponding roles inside its list (using the name of the role and the instance of institution), then delegating this object for the execution of the power

21 Roles as a Coordination Construct: Introducing powerJava MTCoord'05, Namur, Conclusions ● By roles we implement control-driven coordination in an OO language ● powerJava introduces roles in Java preserving the natural OO programming style (expecially for the use of interfaces) ● Type checking is demanded to the Java compiler ● On-going work: studying a notion of type for the role definition and implementation ● powerJava shares some features with Object Teams, Caesar, AspectJ, Traits, Mixins, its originality mainly stands in the use of interfaces, a key choice to support modularity and reuse