1 / 22

C2 Supplement

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.

castor-slater
Download Presentation

C2 Supplement

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. C2 Supplement Jie Ren ICS 123, Fall 2002 Based on Eric Dashofy’s slides for ICS 123, Spring 2000

  2. One more example

  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

  4. Review of C2 Constraints and Properties

  5. 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 Connector Notifications fall “pull” Requests rise Component “push” Connector

  6. 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 • NO PASSING POINTERS!

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

  8. 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!

  9. Another interesting configuration

  10. Circular dependence • What if you have two (or more) components that you really believe are circularly dependent? • Five common solutions… B A

  11. Solution 1-3: A+B Solution 1: Merge A B Solution 3: Remove other dependency Solution 2: Remove one dependency A B

  12. Solutions 4 & 5: ADT Solution 4:(Data Integration) Communicate via shared data (mini-blackboard style) B A B A Solution 5:(Control Integration) Use a manager that can make requests of either component; notifications are turned into invocations. Manager

  13. Try to avoid this… BAD“Magic Mirror” or “Reflectors” approach: Component simply“reflects” notifications or requestsinto the opposite type of message. B A

  14. Using c2.fw to Implement C2-style Architectures

  15. Overview • 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

  16. 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

  17. 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.

  18. 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

  19. 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

  20. 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 • DO NOT PASS PONINTERS IN 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);

  21. 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

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

More Related