1 / 18

Stefan Van Baelen, David Urting, Yolande Berbers K.U.Leuven Department of Computer Science

The SEESCOA Composer Tool: Using Contracts for Component Composition and Run-Time Monitoring. UML 2002 SIVOES-MONA workshop October 1, 200 2. Stefan Van Baelen, David Urting, Yolande Berbers K.U.Leuven Department of Computer Science Celestijnenlaan 200 A B-3001 Leuven Belgium

Download Presentation

Stefan Van Baelen, David Urting, Yolande Berbers K.U.Leuven Department of Computer Science

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. The SEESCOA Composer Tool:Using Contracts for Component Composition and Run-Time Monitoring UML 2002 SIVOES-MONA workshop October 1, 2002 Stefan Van Baelen, David Urting, Yolande BerbersK.U.Leuven Department of Computer Science Celestijnenlaan 200 A B-3001 Leuven Belgium http://www.cs.kuleuven.ac.be

  2. Outline • Goals of the SEESCOA Project • Components & Collaborations • Contracts for Components & Collaborations • The SEESCOA Run-Time Component System • The SEESCOA CCOM Composer Tool • Future Work

  3. Goals of the SEESCOA Project • Enable CBD for RT Embedded Systems • Developing applications by hierarchical (de)composition of components • Adding QoS specification contracts onto scenarios (resource constraint contracts) • Development of a run-time component system supporting loose coupling of component • Code generation for SEESCOA component system • Monitoring resource contracts at run-time • Active scheduler based on resource contracts • For higher-end embedded systems

  4. Components & Collaborations • What is a SEESCOA component ? • A logically highly cohesive, lowly coupled, documented software module that can be used as a unit of development, reuse, composition and adaptation. • It provides dedicated functionality through well-defined interfaces. • It can be instantiated and is statefull at run-time • Component blueprint (class-like) vs. instance (object-like) • Example • a collection of objects accessible through one or more facades, and providing a factory to instantiate them

  5. Settings control 3 Sampler # Read-out Master control 1 Components & Collaborations • SEESCOA component modeling & hierarchical (de)composition is based on ROOM/UML-RT • Components = black boxes accessible through ports • Component blueprint (class) can define a number of port blueprints (classes) • Ports define a bi-directional asynchronous interface to a component • Port specification on 3 levels • Syntactical level (in/outgoing message names & params) • Semantic level (message spec., pre & postconditions) • Synchronization level (MSC for the port)

  6. Components & Collaborations • Synchronization level MSC = extended UML Sequence Diagram • Allows specification of loops, alternative & optional messages • Allows specification of message hooks • Sending time of message (S) • Receival time of message (R) • Beginning of activation (B) • End of activation (E) • Return value passing = distinct message :Sampler :Env start S R B E LOOP update S R OPT request R S S R resend

  7. Components & Collaborations • Component instances can have a number of port instances, to which other component/port instances can be connected • MSC’s of connected components must be compliant (MSC conformance checking) • Mapping of names (resolving name mismatches) • Mapping of LOOP / OPT / ALT blocks • “Unified” collaboration MSC as a result reader 1 settings control secondary read-out sampler reader 2 master master control

  8. a’ d/d’ a a/a’ d’ d Components & Collaborations • MSC conformance checking env c2 c1 env LOOP b b’ LOOP ALT LOOP c e’ OPT e c’ c1 c2 b/b’ LOOP e/e’ c/c’ Resulting MSC associated with the connector

  9. consumer producer mediator Components & Collaborations • Connectors are mostly binary • But multi-connectors can also be modeled mediator producer consumer OPT start LOOP send LOOP deliver ok

  10. Components & Collaborations • UML SEESCOA Profile • Meta-model extension • Plus additional restrictions (inheritance, features, …)

  11. read-out sampling reader 1 Memory Contract Timing Contract Contracts for Components & Collaborations • QoS contracts can be attached to components & connectors • Timing contracts on a collection of connectors • Memory contracts on a component • Can be seen as contract between component & the component system, restricting the dynamic memory usage of the component Timing Contract cons prod MW

  12. Contracts for Components & Collaborations • QoS contracts • Based on Real-Time Logic (RTL) • Time-stamped events: occurrence relation R(event, occurrence, time) • Can make use of message hooks • Sending/Receival of message • Beginning/End of activation • msg.B[] - msg.S[] < 10 ms :Sampler :Env start S R B E LOOP update S R OPT request R S S R resend

  13. request Contracts for Components & Collaborations • QoS contracts & LOOP / ALT / OPT constructs • Occurrence maps to MSC loop • ping.S[i+1] - ping.S[I] <= 50 ms • Nesting of MSC loops supported • “*” (all occurrences) • response.S[*][1] - request.S[*][1] <= 10 ms • ALT & OPT expressions have meaning if event occurred • “-” (any one occurrence) env c2 LOOP ping env c2 LOOP LOOP response

  14. Contracts for Components & Collaborations • Typical QoS contracts supported by templates • Deadline constraints (worst-case duration): b[]-a[] <= t • Lower-bound timing constraints: b[]-a[]>= t • Periodicity constraints: period*(i-1) <b[i]-a[]< period*i

  15. The SEESCOA Run-Time Component System • Components send messages via component system • Component system is responsible for starting/stopping/swapping components • Component system is responsible for message delivery • No direct component interaction => loose coupling • Each component has its own message queue • Messages run to completion per component • Active components simulated by self-directed messages

  16. The SEESCOA Run-Time Component System • QoS constraint monitor layer within component system • Gathers timing information of specified events. • External RTL checker analyses information • Restricted intrusion sampling reader 1 RTL Checker QoS Monitor Layer eventoccurrencereporting SEESCOA Component System

  17. The SEESCOA CCOM Composer Tool • Specification of components, ports & MSC’s • Specification of connections • Specification of timing contracts • Code Generation for component connection & interaction • Code Generation for contract checking (monitor)

  18. Future Work • Active component scheduler • Based on timing contracts • Memory constraints • Specification & monitoring • Memory resource broker • Run-time component system • Distributed QoS Monitor

More Related