C2 supplement
1 / 22

C2 Supplement - PowerPoint PPT Presentation

  • Uploaded on

C2 Supplement. Jie Ren ICS 123, Fall 2002 Based on Eric Dashofy’s slides for ICS 123, Spring 2000. One more example. Holds architecture descriptions. ArchStudio 3. Manages open issues. Critics watch architecture for problems. Manages design critics.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' C2 Supplement' - castor-slater

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
C2 supplement

C2 Supplement

Jie Ren

ICS 123, Fall 2002

Based on Eric Dashofy’s slides for

ICS 123, Spring 2000

Archstudio 3

Holds architecture descriptions

ArchStudio 3

Manages open issues

Critics watch architecture for problems

Manages design critics

Architecture-to-implementation mappings

GUIs for various high-level tools

Graphical and syntax-directed editors

Manages open files and tools

A quick look at the c2 style
A Quick Look at the C2 Style

  • Asynchronous, event-based communication among autonomous components, mediated by active connectors

  • No component-component links

  • Event-flow rules:

  • Hierarchical application


Notifications fall


Requests rise




Review c2 constraints
Review: C2 Constraints

  • Components & connectors have two interfaces (top & bottom)

  • Components must only communicate through a connector

  • Components may have 0-1 connector connected to each interface

  • Connectors may have as many components on top & bottom as they want

  • All communication through INDEPENDENT messages


C2 constraints cont
C2 Constraints (cont).

  • Substrate Independence

    • Make assumptions about what components above you can do for you (but not necessarily which specific components those are)

    • Make no assumptions about what components are below you

  • Up & Down communication only

  • No side-side communication

Leveraging c2 constraints
Leveraging C2 Constraints

  • The connector-connector link can be a powerful thing

    • If you have a component that merely passes messages untouched, consider linking connectors

  • Also, there are lots of interesting configurations that are non-obvious!

Circular dependence
Circular dependence

  • What if you have two (or more) components that you really believe are circularly dependent?

  • Five common solutions…



Solution 1 3
Solution 1-3:


Solution 1: Merge



Solution 3:

Remove other dependency

Solution 2:

Remove one dependency



Solutions 4 5
Solutions 4 & 5:


Solution 4:(Data Integration)

Communicate via shared data (mini-blackboard style)





Solution 5:(Control Integration)

Use a manager that can make requests of either component; notifications are turned into invocations.


Try to avoid this
Try to avoid this…

BAD“Magic Mirror” or “Reflectors”

approach: Component simply“reflects” notifications or requestsinto the opposite type of message.




  • For this assignment, you will:

    • Be implementing the component behaviors of a C2-style architecture using the c2.fw framework

      • Have components send out messages when necessary

      • Have components handle all necessary messages

  • You will NOT:

    • Create new components

    • Create or modify an architectural configuration

    • Create connectors

What is c2 fw
What is c2.fw?

  • An architecture framework, in Java, that is faithful to the C2 architectural style

  • “Killer” Features

    • Pluggable topology manager

      • You will be using the default topology manager

    • Pluggable message queueing policy

      • You will be using one-queue-per-interface

    • Pluggable threading policy

      • You will be using one-thread-per-brick

    • More clear support for brick lifecycles and architecture configurations

      • You will be using the lifecycles, configurations are taken care of for you

    • Better support for distribution, dynamism than in previous frameworks

      • You will not be using this for this assignment

Important classes
Important Classes

  • AbstractC2Brick

    • The base class of all C2 bricks

    • Two interfaces: topIface and bottomIface

    • Important Methods:

      • init() - override

        • Called when the brick is instantiated

      • begin() - override

        • Called when the brick is welded into place, send initial messages here

      • end() - override

        • Called when the brick is about to be unwelded, send final messages here. Not used in this assignment.

      • destroy() - override

        • Called when this brick is about to be destroyed. Not used in this assignment.

Abstractc2brick cont
AbstractC2Brick (cont).

  • More important methods…

    • sendToAll(Message m, Interface iface) - Call

      • Sends message m out the interface iface

      • iface can be ‘topIface’ for requests or ‘bottomIface’ for notifications

    • handle(Message m) – Override

      • Called automatically by the framework when a message arrives on any interface

      • This is where all message handling is done

    • getIdentifier() – Override

      • Call this to get the identifier (class Identifier) of the brick

      • Call toString() on the identifier to get a string representation of it

Notes on connectors
Notes on Connectors

  • You will rely on existing connector class

  • The connector will forward all messages to the other side

    • Request forwarded upward

    • Notification forwarded downward

More important classes
More Important Classes

  • NamedPropertyMessage

    • A C2 message with a name and a property list

    • Properties have string names and either simple-type or serializable Object parameters


//Create a named property message

NamedPropertyMessage npm = new NamedPropertyMessage(“ChatText”);

//Add some parameters

npm.addParameter(“Text”, text);

npm.addParameter(“Sender”, “Strong Bad”);

//Send it upward as a request

sendToAll(npm, topIface);

More about message
More about Message

  • c2.fw.Message is an interface

    • Operations are simple:

    • Where did this message come from?

      • getSource()

    • Where did it go?

      • getDestination()

    • Is this the same as another message?

      • equals()

    • Make me a copy

      • duplicate()

  • Source and destination are returned as BrickInterfaceIdPairs

    • Each contains a brick identifier and an interface identifier

    • Useful for checking if an incoming message was a request or a notification

      • If destination interface ID equals(TOP_INTERFACE_ID) it’s a notification

      • If destination interface ID equals(BOTTOM_INTERFACE_ID) it’s a request

Subclassing namedpropertymessage
Subclassing NamedPropertyMessage

  • This is possible, but some boilerplate code is required

  • Enforces better type safety, makes code clearer

  • You don’t have to do this in this assignment. Using parameters to achieve a goal.

  • Think how a message flows