1. Component-Based Development Silvio Romero de Lemos Meira Eduardo Santana de Almeida silvio@cesar.org.br esa2@cin.ufpe.br

2. Based on

9. Agenda Software Development Perspective Component-Based Development Components Concepts Elements

10. Software Development Perspective Custom-made x Standard software –Scratch x Outsource Maintenance Interoperability Adaptability Upgrade Reorganization of the business processes

11. Software Development Perspective % bought 1000 Cost efficiency Flexibility, Nimbleness, Competitive edge

12. Component-Based Development Classical View –SW = monolithic “Blocks” –Inter-related parts –“integral” world... CBD –pieces of blocks … –To reduce complexity and time development –distributed world…

13. Components Mass Produced Software Components, Doug McIlroy NATO Software Engineering Conf., Garmisch, Germany, 1968 http://cm.bell-labs.com/cm/cs/who/doug/components.txt

14. Mass Produced Software Components, ‘68 McIlroy’s component industry:...to see standard catalogues of routines, classified by precision, robustness, time-space performance, size limits, and binding time of parameters...to apply routines in the catalogues to any one of a larger class of often quite different machines; to have confidence in the quality of the routines...[I want] different types of routine in the catalogue that are similar in purpose to be engineered uniformly, so that two similar routines should be available with similar options and two options of the same routine should be interchangeable in situations indifferent to that option

15. Components Assets for composition –Nomen est omen Units of deployment Classes......Objects.......Components –Object I.Technical (without independence notion) –State –Behavior –Polymorphism, Inheritance II. Economics and Markets –Component Markets –Services

16. Market versus technology Component Development – It is not easy Domain Generic solutions Deployment context –Documentation –Test suites –Help Return on Investment (ROI) –In house Time to market, maintainability, flexibility –Component Market “imperfect technology in a working market is sustainable; Perfect technology without any market will vanish.” Szyperski, 2002, pp. 18

17. Two perspectives: Market Orientation - Reengineering-oriented Domain - Development for reuse

18. Putting the Pieces Together Components Objects Interfaces Contracts Component Framework Component Model

19. Components Properties –Is a unit of independent deployment; –Is a unit of third-party composition; –Has no (externally) observable state. Objects’ Properties –Is a unit of instantiation, it has a unique identity; –May have state and this can be externally observable; –Encapsulates its state and behavior.

20. Components “ A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.” Szyperski, 2002, pp. 41 Black box –JAVA API White box –Releases {contracts}

21. Component and Object Comparison

22. Objects Entities that encapsulate state and behavior and have a unique identity Behaviors and structures defined by classes that: -Implement concept of abstract data type (ADT) -Provide abstract descriptions of behavior of objects -Provide concrete implementation of object behavior -Enable creation of objects – instances of the class

23. All component models based on the object- oriented programming paradigm Components define object behavior and create objects – component instances Both make functionality available through abstract behavior descriptions called interfaces Component and Object Similarities

24. Component and Object Differences Implementation of component is generally completely hidden and sometimes only available in binary Component may be implemented in many ways: single class, multiple classes, or traditional non– object oriented procedures Component names not used as type names. Type and implementation completely separated Components conform to standards defined by component model

25. Interfaces Components’ point access –A set of named operations that can be invoked by clients –Provided component contains an implementation of all operations defined by that interface –Required component requests an interaction defined in that interface and expects another component to support that interface

26. Contracts Contracts states: –what the client needs to do to use the interface –what the provider has to implement to meet the services promised by the interface –Pre x Pos conditions

27. Component Framework Analogy –Mini-operating system Components (Framework) – Processes (OS) –Infra-structure Resource Management Communication between components –Enterprise JavaBeans (EJB) Framework of servers and containers –Persistence, Transaction, Security

28. Component Model Component Model defines a set of standards for component implementation, interoperability, customization, composition, evolution, and deployment –Enterprise JavaBeans (EJB) –CORBA Component Model (CCM) –Microsoft COM/DCOM Component model implementation is the dedicated set of executable software elements required to support the execution of components that conform to the model –JBoss EJB application server

29. Component Model: Elements

30. Basic Elements of Component Model Standards forDescription InterfacesServes as contract between component and client. Specifies component behavior and properties; definition of Interface Description Languages (IDL) NamingGlobal unique names for names for interfaces and components Meta dataInformation about components, interfaces, and their relationships; API to services providing such information

31. Basic Elements of Component Model Standards forDescription Interoperability Communication and data exchange among components from different vendors, implemented in different languages CustomizationInterfaces for customizing components. User-friendly customization tools will use these interfaces

32. Basic Elements of Component Model Standards forDescription CompositionInterfaces and rules for combining components to create larger structures and for substituting and adding components to existing structures Evolution SupportRules and services for replacing components or interfaces by newer versions

33. Basic Elements of Component Model Standards forDescription Packaging and DeploymentPackaging implementation and resources needed for installing and configuring a component

34. Interface –Specifies component behavior and properties using an Interface Description Language (IDL) –Serves as contract between component and its clients. –Specifies services a client may request from a component. The component provides an implementation of these services –Includes constraints on usage of these services –Interface specifications are a central element in a component model –Consists of the elements -Name of each operation -Parameters of each operation -Type of each parameter -Return type for each operation

35. –Globally unique names for names for interfaces and components –Naming schemes - Unique identifiers  Generated by tools that use combination of specific data to guarantee uniqueness  For example, Global Unique Ids (GUIDs) used by COM/DCOM/COM+ -Hierarchical name spaces  Guaranteed to be unique if top-level names are uniquely registered with global naming authority.  For example Java-based components Naming

36. –Information about components, interfaces, and their relationships; API to services providing such information –Many ways of providing metadata - Interface and implementation repositories  CORBA-based systems -Type libraries  COM-based systems -Introspection  Java-based systems Meta Data

37. –Communication and data exchange among components from different vendors, implemented in different language For example, Enterprise Java Beans written in Java, can be deployed across various platforms and application servers –Remote interoperability based on Remote Procedure Calls (RPCs) For example, Simple Object Access Protocol (SOAP), Remote Method Invocation (RMI) for Java- based systems, serve as remote method specifications Interoperability

38. Customization Interfaces for customizing components. User friendly customization tools will use these interfaces. –For example, two similar EJB components can be customized differently by using different deployment descriptors for each component

39. –Interfaces and rules for -combining components to create larger structures -substituting and adding components to existing structures. -registration of component with component/service for notification of pre-defined events –Component composition is combination of two or more software components that yields a new component behavior –Basic types of component interactions -Client/server – remote method invocation -Publish/subscribe -Messaging –Glue languages -Support component composition at a higher level of abstraction than all- purpose programming language –Disadvantage of composition language -Glue code has to be written or graphically specified from inception Composition

40. –Rules and services for replacing components or interfaces by newer versions. –New version may have different implementation or provide extended or new interfaces –Ideally existing clients should be minimally affected by later versions Evolution Support

41. Packaging and Deployment Packaging implementation and resources needed for installing and configuring a component –For example, a deployment descriptor provides information about contents of the package and deployment information

42. Putting Pieces Together [SEI, 2000]

43. Questions ?

44. References [Heineman, 2001] Heineman, G., T., Council, W., T. Component- Based Software Engineering: Putting the Pieces Together, Addison- Wesley. 2001. [SEI, 2000] Software Engineering Institute. Market Assessment of Component-Based Software Engineering, Technical Report, May, 2000. [Szyperski, 2002] Szyperski, Clemens. Component Software: Beyond Object-Oriented Programming, Addison-Wesley, 2002.