c2 supplement
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
C2 Supplement
Jie Ren
ICS 123, Fall 2002
Based on Eric Dashofy’s slides for
ICS 123, Spring 2000
One more example
ArchStudio 3 Holds architecture descriptions
Critics watch architecture for problems
Architecture-to-implementation mappings
Manages open issues
Manages design critics
GUIs for various high-level tools
Graphical and syntax-directed editors
Manages open files and tools
Review of C2 Constraints and Properties
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 Component
Connector
“push”
“pull”
Connector
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!
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
• 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!
Another interesting configuration
Circular dependence
• What if you have two (or more) components that you really believe are circularly dependent?
• Five common solutions…
A B
Solution 1-3:
A+BSolution 1: Merge
A
B
Solution 2:Remove one dependency
A
BSolution 3:
Remove other
dependency
Solutions 4 & 5:
A B
ADTSolution 4:
(Data Integration)Communicate via shared data
(mini-blackboard style)
A B
Manager
Solution 5:(Control Integration)
Use a manager that can make requests of either component; notifications are turned into
invocations.
Try to avoid this…
A B
BAD
“Magic Mirror” or “Reflectors”approach: Component simply
“reflects” notifications or requests
into the opposite type of message.
Using c2.fw to Implement C2-style Architectures
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
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• 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).
• 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
• 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
• 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);
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
• 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