C2 Supplement
-
Upload
castor-slater -
Category
Documents
-
view
27 -
download
0
description
Transcript of C2 Supplement
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