1 / 56

CBSE: Components and Architecture

CBSE: Components and Architecture. Motivation: “Software Integrated Circuits”. Motivating Case Study. Design of digital circuits: Logic gates: AND, OR, XOR, NOT: independent, reusable building blocks

nholt
Download Presentation

CBSE: Components and Architecture

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. 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; } } }

More Related