Lecture29-CompositionIntegration-4up - Outline...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
Component-Based Software Engineering ECE493-Topic 5 Winter 2007 Lecture 29 – Component Composition and Integration Ladan Tahvildari Assistant Professor Assistant Professor Dept. of Elect. & Comp. Eng. University of Waterloo University of Waterloo March 16, 2007 March 16, 2007 ECE493 ECE493 -T5 T5 2 Outline z Component Integration z From Integration to Composition z Composition Techniques z Predictable Assembly from Certifiable Components (PACC) z Prediction-Enabled Component Technology (PECT) – Architecture-based Analysis – Component Certification – Architectural Styles and Component Models March 16, 2007 March 16, 2007 ECE493 ECE493 -T5 T5 3 Component Integration (1) z Integrating components can be illustrated as a mechanical process of “wiring” components together to form assemblies: – This isn’t always easy – It may be necessary to create adaptors to translate data types or to manage control issues. • This is not good because you get a extra layer which has to be developed and maintained. z Component integration is based on syntactic information such as method signatures and, when available, supplementary information supplied in a component’s interface. March 16, 2007 March 16, 2007 ECE493 ECE493 -T5 T5 4 Component Integration (2) z Supplementary information will most likely include information such as a description of the function to be performed, and types of exceptions thrown z Standardization in form of component models like EJB, CORBA and COM. – Problems in component integration has been reduced by the introduction of these models – Supplies standards for interfaces and what methods they must implement – Defines protocols for communication between components z Still Difficult to make components play well together
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
March 16, 2007 March 16, 2007 ECE493 ECE493 -T5 T5 5 Component Integration (3) “Architectural mismatch stems from mismatched assumptions a reusable part makes about the structure of the system it is to be part of. These assumptions often conflict with the assumptions of other parts and are almost always implicit, making them extremely difficult to analyze before building the system.” D. Garlan, R. Allen and J. Ockerbloom. “Architectural Mismatch: Why Reuse is So Hard,” IEEE Software, 12(6):17-26, November 1995 March 16, 2007 March 16, 2007 ECE493 ECE493 -T5 T5 6 Component Integration (4) z Two key cases: – D. Garlan, R. Allen and J. Ockerbloom “Architectural Mismatch: Why Reuse is So Hard” AESOP – P. Inverardi, A.L. Wolf, and D. Yankelevich, Static Checking of System Behaviors Using Derived Component Assumptions Compressing Proxy March 16, 2007 March 16, 2007 ECE493 ECE493 -T5 T5 7 AESOP: Component Integration z AESOP permits the rapid construction of style-specific (or domain-specific) architectural design environments.
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 10/28/2010 for the course ECE 493 taught by Professor Lam during the Spring '09 term at Waterloo.

Page1 / 6

Lecture29-CompositionIntegration-4up - Outline...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online