Connecting Components (AIGR view)

A fundamental concept in CCastle is the connection between components; by Ports and Protocols. The implementation of a component can’t see ( or ‘reach’) anything outside it own Component. It can only react on data on an (incoming) Port, and sent data (like events) over an (outgoing) Port.

In this chapter we examine how that conceptually works and which data-structures in a AIGR are needed to capture it. For simplicity we limit ourselves to Events (and so EventProtocols & Eventhandlers) for now. Other kinds, like “Data”, “Stream” are added later.

Primary Classes

Let’s start with an overview of the dataclasses in the AIGR, that are fundamentally to connect components by communicating with events.

@startuml title: Primary Classes abstract NamedNode #lightgray { name :ID:str } abstract Protocol #lightgray{ based_on : Protocol } NamedNode <|-- Protocol Protocol o... Protocol::based_on #Indigo class Event #AquaMarine {} NamedNode <|--Event class EventProtocol #lightBlue { events : tuple[Events] } Protocol <|- EventProtocol EventProtocol o-> "many" Event class Port #lightBlue { direction \t: PortDirection type \t\t: Protocol | <type> } NamedNode <|-- Port Protocol <-- Port::type EventProtocol <.. Port::type #AquaMarine class ComponentInterface #lightGreen{ based_on \t: ComponentInterface ports \t\t: PTH.Sequence[Port] } NamedNode <|-- ComponentInterface Port "*" -* ComponentInterface::ports ComponentInterface o... ComponentInterface::based_on #Indigo package INVISIBLE <<Rectangle>> #AntiqueWhite-Gold { class ComponentImplementation #limeGreen{ interface \t: ComponentInterface parameters \t: tuple[TypedParameter, ...] } NamedNode <|--ComponentImplementation ComponentInterface --* ComponentImplementation::interface class "proto.event on port'" as EV1 <<EventHandler>> #lightBlue { proto \t: Protocol event \t: Event port \t: Protocol } EventProtocol "1" <.. EV1::proto Event "1" <.. EV1::event Port "1" <.. EV1::port } @enduml

  • The ComponentInterface & ComponentImplementation describe the Component. One with an external aspect, and one with the internal parts – the later are “hidden”.
    Notice that both are named – and will have the same name.

  • The external aspects of the Port class are “visible”; they are mentioned in the ComponentInterface. Aside of it’s name, its direction (like incoming) and type are also visible.
    Here we assume its type is an (Event)Protocol. Then, the Port links to an EventProtocol; which is a specialization of Protocol.

  • The EventProtocol contains a list of Events. As events are sent from component to component, they are clearly “visible”.

  • The Eventhandlers however, are “hidden” and invisible outside the Component (Implementation).
    They are triggered by the external event, and associated with a Port, and an Event within a specific Protocol [1].

    Note

    As both ComponentInterface and Protocol support sub-classing, one should ponder the inherited Ports & Events too – see the fields based_on.

Footnotes

Comments

comments powered by Disqus