1 / 22

The C2 Architectural Style

The C2 Architectural Style. ICS 123 Richard N. Taylor and Eric M. Dashofy UC Irvine http://www.isr.uci.edu/classes/ics123s02/. Architectural Styles. “Walk like this!” “Why should I walk like that?” Canonical structures and rules provide context focus attention

jonco
Download Presentation

The C2 Architectural Style

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. The C2 Architectural Style ICS 123 Richard N. Taylor and Eric M. Dashofy UC Irvine http://www.isr.uci.edu/classes/ics123s02/

  2. Architectural Styles • “Walk like this!” • “Why should I walk like that?” • Canonical structures and rules • provide context • focus attention • promote shared understanding • carry hard-won domain knowledge and proven solution techniques

  3. The C2 Style(Taylor et al., UC Irvine) • A general multi-tier architectural style • Asynchronous message-based integration of independent components • Based on past experience with the model-view-controller design pattern and the Chiron-1 UIMS • Generalizes architectures for user interface management systems • Notable feature: flexible connectors • Accommodate arbitrary numbers of components • Facilitate runtime architectural change • Principle of substrate independence • A component need not know anything about components beneath it • We’ll define the layering rules and the notion of “beneath” shortly … • Rich design environment for composition & analysis

  4. The C2 Style • Autonomous components • own thread and non-shared address space • All communication is by asynchronous events which must pass through a connector • connectors may be complex and powerful • Some additional rules to promote reuse • (A variety of implementation techniques)

  5. Intellectual Heritage • Domain-specific software architectures • concurrent, loosely coupled, distributed, dynamic apps • Smalltalk’s model-view-controller paradigm • Field’s event-based integration • Abstraction and separation of concerns • OO typing • Lisp, et.al.s dynamic properties

  6. Qualities Affected • Advantages • Reusability (discrete components promote reusability) • Evolvability/Flexibility: Because event receivers are not explicitly named, it is possible to integrate new components fairly easily • Dynamism (can change architecture on the fly) • Visibility (explicit & mandatory connectors provide points for observation) • Distributability (all events are assumed to be independent, and therefore components can be distributed across hosts) • Understandability (particularly promoted via substrate independence) • Disadvantages • Familiarity: Programmers often not initially familiar with event-based & asynchronous programming • Complexity: Because of asynchrony, concurrency issues are more prevalent and must be handled, event interactions are not always obvious (although tools can help!)

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

  8. Example: KLAX Video Game KLAX Chute • Tiles of random colors drop one cell at a time, starting at random times and locations KLAX Palette • Palette manipulated to catch tiles coming down the Chute and to drop them into the Well KLAX Well • Horizontal, vertical and diagonal sets of three or more consecutive tiles of the same color are removed, and any tiles above them collapse down to fill in the newly-created empty spaces KLAX Status • Points scored as sets are formed • Lives lost as Well or Palette spills over

  9. Clocklogic StatusADT ChuteADT WellADT PaletteADT Next tileplacing logic Tile matchlogic Relative poslogic Statuslogic Statusartist Wellartist Chuteartist Paletteartist Tileartist Layoutmanager Graphicsbinding A Simple Example: KLAX • KLAX™ game • 16 components, approx. 4k SLOC, 100kb compiled • implemented from scratch inthe C2 architectural style[TMA+96]

  10. Clocklogic StatusADT ChuteADT WellADT PaletteADT Next tileplacing logic Tile matchlogic Relative poslogic Statuslogic Statusartist Wellartist Chuteartist Paletteartist Tileartist Layoutmanager Graphicsbinding KLAX: Adaptability • Spelling KLAX • spell words from falling letters • replaces 3 components • High score list • adds 3 new components • Multi-player networked KLAX • a match adds a tile toopponents’ chute

  11. Clocklogic StatusADT ChuteADT WellADT PaletteADT Next tileplacing logic Tile matchlogic Relative poslogic Next letterplacing logic Word matchlogic Statuslogic Statusartist Wellartist Chuteartist Paletteartist Tileartist Letterartist Layoutmanager Graphicsbinding KLAX: Adaptability • Spelling KLAX • spell words from falling letters • replaces 3 components • High score list • adds 3 new components • Multi-player networked KLAX • a match adds a tile toopponents’ chute

  12. High scoreADT Clocklogic StatusADT ChuteADT WellADT PaletteADT Next tileplacing logic Tile matchlogic Relative poslogic Next letterplacing logic Word matchlogic High scorelogic Statuslogic Statusartist Wellartist Chuteartist Paletteartist High scoreartist Tileartist Letterartist Layoutmanager Graphicsbinding KLAX: Adaptability • Spelling KLAX • spell words from falling letters • replaces 3 components • High score list • adds 3 new components • Multi-player networked KLAX • a match adds a tile toopponents’ chute

  13. High scoreADT ClientADT Clocklogic StatusADT ChuteADT WellADT PaletteADT Next tileplacing logic Tile matchlogic Relative poslogic Next letterplacing logic Word matchlogic High scorelogic Statuslogic Statusartist Wellartist Chuteartist Paletteartist High scoreartist Clientartist Tileartist Letterartist Layoutmanager Graphicsbinding KLAX: Adaptability • Spelling KLAX • spell words from falling letters • replaces 3 components • High score list • adds 3 new components • Multi-player networked KLAX • a match adds a tile toopponents’ chute

  14. C2 Component Structure (I) • The internal object is the “guts” of the component • The wrapper maps messages to operations of the internal object • Requests  Operation Invocations • Operation Results  Notifications • Wrapped object can be described in terms of method signatures • This organization allows reuse of independently-developed, “off-the-shelf” components as the internal object Domain Translator Wrapper Internal Object Dialog requests notifications

  15. C2 Component Structure (II) • The dialog provides the “control logic”, routing any relevant message to/from the internal object • The domain translator translates messages from this component’s “vocabulary” to that of the layer above • Note that a component never requests anything of components “beneath” it Domain Translator Wrapper Internal Object Dialog requests notifications

  16. C2 Component Connection • C2 Connectors • Broadcast all messages received on the bottom side to the top side, and vice versa • Operate across machines • Operate across languages • Accommodate dynamic attachment and removal of components • Can be implemented in a number of ways • Procedure calls • Ada rendezvous • Java events • CORBA ORBs • … Connector

  17. A Typical C2 Configuration • Computation originates mostly in lower layers • Components need not process all messages they receive • Connectors need not fully segregate layers Comp1 Comp5 Conn1 Comp2 requests notifications Conn2 Comp3 Comp4

  18. Rules of the C2 Style • Components are never attached to other components • A component can be attached to at most one connector on its top side and one on its bottom side • Connectors can be attached to other connectors • A connector must have at least one component or connector attached on its top side and one attached on its bottom side • Requests only go up in an architecture • Notifications only go down in an architecture • There is no circularity allowed • A component can never receive its own messages

  19. Component Interfaces Comp1 top bottom request query(ID: int, M: msg) notification ack(ID: int) Comp2 top request notification ack(ID: int) bottom request init(ID: int) notification ... Comp1 Comp5 Conn1 Comp2 requests notifications Conn2 Comp3 Comp4

  20. A C2 Style Architecture for KLAX • Exhibits typical C2 characteristics • State components reside in upper layers • Interface components reside in lower layers • Intermediate layers provide control logic

  21. Turning KLAX intoSpelling KLAX • Flexible connectors facilitate the necessary architectural changes • Next Letter Placing Logic component substituted for Next Tile Placing Logic component • Spelling Logic substituted for Tile Logic • Letter Artist substituted for Tile Artist

  22. Example: A Long-Distance Telecommunications System • Telephones • Local Switches (one per area code) • Long-Distance Switches (communications backbone) • Call Records database • Other embellishments • 800 numbers • 911 stations • Operator stations • Bill generators

More Related