Motivation: “Software Integrated Circuits”

1. Motivation: “Software Integrated Circuits”

2. 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)

3. Example: building a Half-Adder

4. Example: building a Full-Adder

5. Example: building a 3-bit Adder

6. Reproduce the story using “software components” …

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

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

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

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

11. Composed Application

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

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

14. Another way of implementing a Full-Adder

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

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

17. 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)

18. What we want: (1) A picture more similar to this: Components = design time entities = deployment time entities = runtime entities Instead of:

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

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

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

22. 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

23. 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

24. 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

25. Fractal • Fractal is: • A component model: • Programming-language independent: Many different implementations • Open: No predefined semantics for connection, composition and reflection • Reflective: Components can provide introspection capabilities • Associated architecture description language (ADL) • Additional supporting tools • Developed by ObjectWeb Consortium

26. Fractal Slides • Official Fractal site: http://fractal.ow2.org/ • Slides: Fractal Overview by Jean-Bernard Stefani http://fractal.ow2.org/doc/ow2-webinars09/Fractal-JBS.pdf • Slides: Fractal & ADL by Martin Monperrus http://www.monperrus.net/martin/lecture-fractal.pdf • Slides: Fractal in Java by Lionel Seinturier http://fractal.ow2.org/doc/ow2-webinars09/Fractal-Java-Lionel.pdf