CBSE: Components and Architecture

1. CBSE:Components and Architecture

2. Motivation: “Software Integrated Circuits”

3. Motivating Case Study • Design of digital circuits: • Logic gates: AND, OR, XOR, NOT: independent, reusable building blocks • Simple sequential circuits: multiplexer, half-adder, etc: composed by using available logic gates • Complex sequential circuits: full-adder: composed by using available building blocks (logic gates and simpler sequential circuits)

4. Example: building a Half-Adder

5. Example: building a Full-Adder

6. Example: building a 3-bit Adder

7. Reproduce the story using “software components” …

8. Design “Logical Gates” Interface IAnd { operation doAnd(in Bit b1, in Bit b2, out Bit rez); } Interface INot { operation doNot(in Bit b1, out Bit rez); }

9. Design “MyHalfAdder” Interface IHalfAdder { operation doHalfAdd(in Bit b1, in Bit b2, out Bit sum, out Bit carry ); }

10. Design “MyFullAdder” Interface IFullAdder { operation doFullAdd(in Bit b1, in Bit b2, in Bit cin, out Bit sum, out Bit cout); }

11. Design “My-3-Bit-Adder” Interface I3BitAdder { operation do3BitAdd(in Bit[3] b1, in Bit[3] b2, out Bit[3] sum); }

12. Composed Application

13. Reuse Example 1 • MyFullAdder may be reused by a 4BitAdder new reused

14. Reuse Example 2 • My4BitAdder is still working when MyFullAdder is replaced with YourFullAdder, if this one implements the same interface IFullAdder

15. Another way of implementing a Full-Adder

16. Design “YourFullAdder” Interface IFullAdder { operation doFullAdd(in Bit b1, in Bit b2, in Bit cin, out Bit sum, out Bit cout); }

17. Reuse Example 2 (cont) • My4BitAdder is still working when MyFullAdder is replaced with YourFullAdder, if this one implements the same interface IFullAdder

18. Implementing … • The “reusable components” described before can be implemented in any OO or procedural language • What we like: • Code reuse • Design for reuse • Abstraction of domain-specific components • Good design principles (“programming to an interface”) • What we do not like: • Composed application is written by writing glue-code • Component diagram which results is not the ideal logic view • Component diagram is far from being as self-explaining as the logic gates circuit representations • Composition occurs before runtime • before runtime it is known by the composed application weather it will use MyFullAdder or YourFullAdder • Application can not replace at runtime the FullAdder in use with a new ANewSpecialFullAdderImplementation • (OK, it could by using features of language reflection, but in a ugly way)

19. What we want: (1) A picture more similar to this: Components are at the same time: design time entities deployment time entities runtime entities Instead of:

20. What we want: (1’) A picture more similar to this: Components with Ports / Components with only Interfaces Instead of:

21. What we want: (2) Write less glue code: description languages for composition Describe composed application in a way similar with describing a configuration in a hardware description language => Use ADLs (architectural description languages)

22. What we want: (3) A single component model for different technologies Component model: language independent Component model: open semantics for bindings

23. What we want: (4) Binding time delayed as much as possible: • Which FullAdder Implementation ? • choose late • change at runtime if wanted • But in a NICE way, programmatically speaking • Dynamic Architectures

24. Components and Architecture • Component • “a unit of composition with contractually specified interfaces and context dependencies only. A software component can be deployed independently and is subject to composition by third parties” [Szyperski] • Architecture • The structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. [Bass] • Unified view of component: a reusable component is also an architectural component • the architecture is made of components • the components are assembled together to form an architecture

25. Architectural Description Languages (ADL’s) • A language able to describe software architectures: • Describes components, ports, connectors, connections • Many ADL’s: ACME (CMU), Wright (CMU), Rapide, Darwin (Imperial College) • ISO/IEC 42010: standardises the practice of architecture description

26. Fractal • Fractal is: • A component model: • Hierarchical: a component may contain other components • Programming-language independent: Many different implementations • Reflective: Components can provide introspection capabilities • Open: No predefined semantics for connection, composition and reflection • Associated architecture description language (ADL) • Additional supporting tools • Developed by ObjectWeb Consortium • Official Fractal site: http://fractal.ow2.org/

27. The Fractal Component Model

28. Basic concepts in Fractal • Component • Has well identified interfaces • May have recursive sub-components • Interface • A named access point to a component • Can emit or receive operations or messages (client and server interfaces) • Can be typed • Binding • Communication path between components • Bindings mediate all interactions between components

29. External view of a Fractal component

30. Original concepts in Fractal • Component = membrane + content • Membrane (=controllers) • Supports a component’s reflective capabilities • Can support meta-object protocols through control interfaces • Content • Sub-components • A component can have an internal structure of its own • Sharing • A component can be a subcomponent of several composites • Component graphs, not just trees • Useful for architectures with resources and cross-cutting concerns

31. Internal view of a Fractal component

32. Kinds of interfaces • External interfaces: accessible from outside the component • Internal interfaces: accessible from inside the component (by the sub-components) • Functional interfaces: corresponds to a provided or required functionality (server interfaces or client interfaces) • Control interfaces: server interfaces that correspond to non-functional aspects such as introspection, configuration, reconfiguration

33. Reflective capabilities (Controllers) • Basic reflection: • Component controller (discovering a component interfaces) • Interface controller (obtaining the Component controller) • Binding controller (binding an external component interface) • Structural reflection • Content controller (adding, removing subcomponents) • Attribute controller (setting, getting component attributes) • Behavioral reflection • Interceptors (before, around and after operations) • Lifecycle controller (starting, stopping the component)

34. Kinds of components • Composite component: a component which exposes its contents; it has a ContentController • Primitive component: a component which does not expose its content, but has at least one control interface • Base component: a component without any control interface

35. Kinds of bindings • Primitive binding: a binding between one client interface and one server interface in the same address space • Normal binding, export binding, import binding • Composite binding: through binding components (connectors)

36. Binding controller

37. Rules for binding

38. Characteristics of Fractal interfaces • Name • Type T: the language type (set of operations) • Role (client or server) • Contingency (mandatory or optional) • Cardinality: how many interfaces of type T a component may have (singleton or collection)

39. Interface access • Required (client) interfaces are controlled by the binding controller interface. • external interfaces (server interfaces) are controlled by the component controller interface. • internal interfaces are controlled by the content controller interface.

40. Bootstrap component and Factories • In order to create components, and types, Fractal has the notion of factories. • The type factory: allowing the creation of interface types, and component types. • The generic factory (component factory) : allowing the creation of components. • These factories are accessible from the bootstrap component. The bootstrap component is just a component which does not need to be created explicitly and which is directly accessible.

41. Fractal implementations • The Fractal Component Model is available for various programming languages: • Reference implementations: • Julia (Java) • Cecilia (C) • Other implementations: • AOKell (Java) • Think (C) • FractNet (.NET experimental) • FracTalk (SmallTalk experimental) • Julio (Python experimental)

42. The Fractal ADL

43. Fractal ADL • The base architectural description language of the Fractal component model • Describes component types, component implementations, component hierarchies and component bindings • Extensible and modular toolchain framework • http://fractal.ow2.org/fractaladl/index.html

44. The HelloWorld Example

45. The HelloWorld Example: Functional Interfaces Client functional interface: Public interface Main { void main (String[] args); } Server functional interface: Public interface Service { void print (String msg); } Server attribute configuration interface: Public interface ServiceAttributes extends AttributeController{ String getHeader(); void setHeader(String header); int getCount(); void setCount(int count); }

46. The HelloWorld Example: Server component ADL • Definition of component’s type (optional): <definition name="ServerType"> <interface name="s" role="server" signature="Service"/> </definition> • Definition of component’s implementation: <definition name="ServerImpl" extends="ServerType"> <content class="ServerImpl"/> <attributes signature="ServiceAttributes"> <attribute name="header" value=">> "/> <attribute name="count" value="1"/> </attributes> <controller desc="primitive"/> </definition>

47. The HelloWorld Example: Client component ADL • Definition of component’s type (optional): <definition name="RootType"> <interface name=”m" role="server" signature=”Main"/> </definition> <definition name="ClientType" extends="RootType"> <interface name="s" role="client" signature="Service"/> </definition> • Definition of component’s implementation: <definition name="ClientImpl" extends="ClientType"> <content class="ClientImpl"/> </definition>

48. The HelloWorld Example: Composed component ADL • Definition of component’s type (optional) <definition name="AbstractClientServer" extends="RootType"> <component name="client" definition="ClientType"/> <component name="server" definition="ServerType"/> <binding client="this.m" server="client.m"/> <binding client="client.s" server="server.s"/> </definition> • Definition of component’s implementation: <definition name="ClientServerImpl" extends="AbstractClientServer"> <component name="client" definition="ClientImpl"/> <component name="server" definition="ServerImpl"/> </definition>

49. The HelloWorld Example: Server implementation public class Server implements Service, ServiceAttributes{ private String header = ""; private int count = 0; public void print (final String msg) { System.err.println("Server: begin printing..."); for(int i = 0; i < count; ++i) { System.err.println(header+ msg); } System.err.println("Server: print done."); } public String getHeader() { return header; } public void setHeader(String header) { this.header = header; } public int getCount() { return count; } public void setCount(int count) { this.count = count; } }

50. The HelloWorld Example: Client implementation public class Client implements Main, BindingController{ private Service service; public void main (finalString[] args) { service.print("hello world"); } public String[] listFc() { return new String[] { "s"}; } public Object lookupFc(final String cItf) { if(cItf.equals("s")) { return service; } return nul; } public void bindFc(finalString cItf, finalObject sItf) { if(cItf.equals("s"){ service = (Service)sItf; } ) } public void unbindFc(finalString cItf) { if(cItf.equals("s")) { service = null; } } }