1. Based on Eric Dashofy’s slides for
C2 Supplement
Jie Ren
ICS 123, Fall 2002
Based on Eric Dashofy’s slides for
ICS 123, Spring 2000

2. One more example

3. ArchStudio 3 Holds architecture descriptions 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 5

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 B A
What if you have two (or more) components that you really believe are circularly dependent?
Five common solutions… A B

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

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

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

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

15. Overview For this assignment, you will: You will NOT:
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