1 / 26

Components, roles, and ports

FMCO 2004 – Leiden, NL. Components, roles, and ports. Marcello Bonsangue LIACS – Leiden University 2 November 2004. Collaboration. This is a Mobi-J work in collaboration with Frank de Boer (CWI and LIACS) Martin Steffen (Kiel University) Erika Abraham (Kiel University)

emarcum
Download Presentation

Components, roles, and ports

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. FMCO 2004 – Leiden, NL Components, roles, and ports Marcello Bonsangue LIACS – Leiden University 2 November 2004

  2. Collaboration This is a Mobi-J work in collaboration with • Frank de Boer (CWI and LIACS) • Martin Steffen (Kiel University) • Erika Abraham (Kiel University) originated from discussions with • Farhad Arbab • Willem-Paul de Roever • Jan Rutten Components, roles, and ports

  3. Roadmap • Component-based software • A role-based calculus • Full-abstraction Components, roles, and ports

  4. Component-based software • Goals • Reuse of software • Evolution of software • Mechanisms • Components (encapsulation of implementations) • Ports (communication points) • Roles (ways of describing and generating ports) • Polymorphism • Late binding • Metaprogramming Components, roles, and ports

  5. Components • A software component is static abstraction subjects to third-party composition with contractually specified interfaces and explicit context dependencies only • Components encapsulate their internal structure • Classes don’t (inheritance breaks encapsulation) • Components do not have run-time identity • Object do • Components can be (re-)composed at run-time • Modules can’t Components, roles, and ports

  6. Ports and roles • Ports • mediate all communications of a component with its environment. • receiving messages from the environment • sending messages to it • Roles • describe a set of valid message exchanges between ports (protocol) • generate new ports subject to the specified protocol Components, roles, and ports

  7. Example • Srv == cln??msg;cln!ack • Cln == x:=New(Srv);x!msg;x?ack • init == x:= New(Cln);y:= New(Cln) Main init Cln Client Server Srv Components, roles, and ports

  8. Roadmap • Component-based software • A role-based calculus • Full-abstraction Components, roles, and ports

  9. The role calculus • Similar to CSP • Port protocols are sequential non-deterministic processes • Port protocols are executed in parallel • Similar to objects • port protocols are associated with ports for their lifetime • Variables are local to port protocols • Similar to classes • Roles describe generically the protocol of an unbounded set of ports • Static variables are shared among port protocols of the same role Components, roles, and ports

  10. Syntax • Roles role == Init;Protocol • Init Initialization assignments • Protocol composition of actions with usual operators ; + rec • Actions x:=n assignment n:= new(role) creation n!n send n?n receive n??n anonymous receive • Variables x::= myrole.n | n • Names n Components, roles, and ports

  11. Port creation • No observable event r’’ Environment r’ Program r i i’ Components, roles, and ports

  12. Port creation • Observable event <i,e> e r’’ Environment r’ Program r i i’ Components, roles, and ports

  13. Communication - internal • No observable event e r’’ Environment r’ Program r i i’ Components, roles, and ports

  14. Communication - external • Observable event <i,e,n> e r’’ Environment r’ Program r i i’ Components, roles, and ports

  15. Operational semantics • A program  succeeds if it may generate a trace <n0,n1> …<nk-1,nk><i,e,success> • Two programs 1, 2 are may-equivalent if for any other program  1, succeeds if and only if 2, Components, roles, and ports

  16. Communication traces • Creation events can be ordered as tree • Creation events are binders in 2nd argument • All names but root of tree are bound e i i’ <e,i><e,i’><i,i’’><e,i’,i> i’’ Components, roles, and ports

  17. Knowledge • There is no program implementing the communication trace <e,i><i,n><e,n,i> because e cannot know n • The port e knows n in a trace t iff • e = n • e received n in a communication • e is the creator of n • e knows another e’ that knows n Components, roles, and ports

  18. A note on creation events • External and internal creation events must be observable • i must have created e • i must have created e’ • but either e created e’’ or • e’ created e’’ <e’,e’’> <i,e’> <i,e> <i,e,i><i,e’,i><e’’,i,e’’> <e,e’’> Components, roles, and ports

  19. Denotational semantics • A communication trace is executable if ports from the environment use only names they knows in a communication • Every executable trace can be implemented by a set of roles. • The semantics given by the set of all executable traces of a program is • compositional • sound (with respect to may equivalence) Components, roles, and ports

  20. Roadmap • Component-based software • A role-based calculus • Full-abstraction Components, roles, and ports

  21. Swapping r == x:=new(r1);y:=new(r2);x!self;y!self r == … + x:=new(r1);y:=new(r2);y!self;x!self • They are may-equivalent but <i,e1><i,e2><i,e2,i><i,e1,i> is a trace only of the second role • The external ports e1 and e2 do not know each other and thus cannot synchronize Components, roles, and ports

  22. Local renaming r == DO x:=new(r’);x!self OD r == x:=new(r’); x!self; y:=new(r) • The first program generates events of the form <i,ek,i> • The second program generates events of the form <ik,ek,ik> • An environment cannot observes this difference since the ports ek’s cannot compare their knowledge • They are may-equivalent Components, roles, and ports

  23. Creation • Creation events not bounding any communication can be removed • Order and time of creation events does not matter • External creator can be replaced by any ports with the same knowledge Components, roles, and ports

  24. Completeness • The semantics given by the set of all executable traces of a program closed under appropriate abstractions for • swapping, • local renaming and • creation is • compositional • sound (with respect to may equivalence) • complete (with respect to may equivalence) Components, roles, and ports

  25. From traces to roles • Sequentializing the knowledge cluster • Passing the baton between ports that knows each other to fix the orderof their events • Expressing the port protocol • Construct a statement for each external port involved as sender, receiver or creator in the events of the trace • Defining the roles • Using static role variables to allow each port to select the right statement • Using a static role variable as a semaphore to control shared variable concurrency and an initial assignment to set it up at creation time. Components, roles, and ports

  26. Conclusion • Model for component-based software • Associating protocols to ports • Allowing dynamic creation of ports • Fully abstract with respect to may-testing • why static variables? • Roles vs. ports as first class structures • More complex types/interfaces • Parametric polymorphism, subtyping • No run-time reconfiguration • introduce a dynamic borderline between program and environment ports Components, roles, and ports

More Related