1. Page 1, 12 September 2015 Introduction to Component-Based Software Engineering Ivica Crnkovic Mälardalen University, Department of Computer Engineering Sweden ivica.crnkovic@mdh.se http://www.idt.mdh.se/~icc

2. Page 2, 12 September 2015 Topic overview 1 The challenges of SW- how can CBD help? 2What is a software component? 3Basic principles of component-based approach 4Component-based Software Development Process 5Problems and research issues 6References

3. Page 3, 12 September 2015 The challenges of software development - how can component software help?

4. Page 4, 12 September 2015 Challanges of Software Engineering (The author of slides with blue background: Michel Chaudron, Tue)

5. Page 5, 12 September 2015

6. Page 6, 12 September 2015 Software paradigm shift Productivity Time Structured programming Object-Oriented Development Component-based development Agent-based development Design method Language System organization 1970199020002005 COBOL, C FORTRAN, ADA Smalltalk C++ SA/SOUMLADL’s??? C++ Java Agglets ? MainframeClient-server N-tier distributed Self-organizing © 2001 ITEA Office Assoc ITEA-Softec project

7. Page 7, 12 September 2015 Answer: Component-based Development  Idea: Build software systems from pre-existing components (like building cars from existing components) Building components that can be reused in different applications Separate development of components from development of systems

8. Page 8, 12 September 2015 Component-Based Software Engineering (CBSE)  Provides methods and tools for Building systems from components Building components as reusable units Performing maintenance by replacement of components and introducing new components into the system

9. Page 9, 12 September 2015 application Component #1 Component #2 Component #3 Component #4 components Component-based software construction (1) Component #1 Component #2 Component #3 Component #4 construction

10. Page 10, 12 September 2015 Concentration on the business parts Business issues GUI Communication GUI Data model Deployment - - - INFRASTRUCTURE Standard Reusable parts Application specific “30 % of SW development effort is spent on infrastructure that adds no value”

11. Page 11, 12 September 2015 Is CBD the same as OOP?  Object-oriented programming ObjectAttributesMethods ObjectAttributesMethods Message Are objects the same as components?

12. Page 12, 12 September 2015 Side remark: OO and reuse Object orientation is not primarily concerned with reuse, but with appropriate domain/problem representation using the technological enablers Objects, classes, inheritance, polymorphism Experience has shown that the use of OO does not necessarily produce reusable SW CBD scale reusable entities: Component = many objects in collaboration reusable parts on the execution level (plug-in) Additional services provided by component models

13. Page 13, 12 September 2015 What is a software component?

14. Page 14, 12 September 2015  The software architecture of a program or computing system is the structure or structures of the system, which comprise software components [and connectors], the externally visible properties of those components [and connectors] and the relationships among them.” Bass L., Clements P., and Kazman R., Software Architecture in Practice, C1 C4 C2 C5C3 Architectural point of view

15. 15 9/12/2015 CORBA (Common Object Request Broker Architecture ) CORBAapps CORBAdomains CORBAfacilities CORBAservices Another example Object Management Architecture Overview TransactionsTransactionsEventEventSecuritySecurityNamingNaming

16. Corba component model Page 16, 12 September 2015

17. Page 17, 12 September 2015 Some successful components: In the past...  Mathematical libraries NAGLIB - Fortran Library Mathematical and physical functions  Characteristics  Well defined theory behind the functions - very well standardized  Simple Interface - procedural type of communication between client (application) and server (component)  Well defined input and output  Relative good error handling  Difficult for adaptation (not flexible)

18. Page 18, 12 September 2015 Some successful components: The big ones… Client - server type  Database Relational databases, (Object-oriented databases, hierarchical databases) Standard API - SQL  Different dialects of the standard  X-windows Standard API, callback type of communication  High level of adaptation  Too general - difficult to use it

19. Page 19, 12 September 2015 Even bigger components: Operating systems Even bigger components: Operating systems  Example - Unix A general purpose OS, used as a platform for dedicated purposes Standard API - POSIX  Commands uses as components in a shell-process Example: sort out words from text files: $ cat file1 file2 file3... | sed ’s/ /\ /g’ | sort -u >words.txt  Different variants, POSIX is not sufficient  Not a real component behavior (difficult to replace or update)  MS Windows...

20. Page 20, 12 September 2015 Frameworks - building “the real components”  Component Object Management - COM, Active X  Enterprise JavaBeans  CORBA components .NET Late binding - easy replacement Word document Excel document My_application Excel document component

21. Page 21, 12 September 2015 Example: The architecture of a car control system Vehicle mechanics ECU Sensor ActuatorSensor ECU Sensor ActuatorSensor ECU Sensor Actuator Sensor gateway (CAN) BUS brakeinjection Infotaiment ECU – Electronic Control Unit

22. Page 22, 12 September 2015 The architectural design challenge Vehicle stabilitySuspensionDrive by wire…… Complex functions Local Control Functions Sensor ActuatorSensor Basic functions Local Control Functions Sensor ActuatorSensor How to implement complex functions based on local control functions?

23. Page 23, 12 September 2015 Problem: resource sharing Sensor 1 Sensor 2 Sensor 3 Sensor.. Network resources ++++++++++ Sensor.. Execution resources Node 1 Node 2 Node 3 Node … Actuator 1 Actuator 2 Actuator 3 Actuator … Can functions of different criticality be allowed to share resources?

24. Page 24, 12 September 2015 sensors Challenge – open and dependable platform Vehicle actuators Engine ControlLocal brake ControlTransmission……… local Vehicle stability Cruise control Antispin Global (complex) functions Hardware Input/output drivers Middleware ECU Applications SOFTWARE COMPONENTS Collision detection

25. Page 25, 12 September 2015 Challenge – open and dependable platform Hardware Input/output drivers Middleware ECU Applications C1C2 Requirements Separation of hw from SW development Separation of SW component development

26. Page 26, 12 September 2015 Szyperski: Software Component Definition Szyperski (Component Software beyond OO programming) q A software component is l a unit of composition l with contractually specified interfaces l and explicit context dependencies only. q A software component l can be deployed independently l it is subject to composition by third party. Will you meet him?

27. Page 27, 12 September 2015 Composition unit 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 party. –Clemens Szyperski How much components fit together? How much costs the glue code? Components Glue code System

28. Page 28, 12 September 2015 What is a contract? 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 party.  Interface – component specification  Contract - A specification attached to an interface that mutually binds the clients and providers of the components. Functional Aspects (API) Pre- and post-conditions for the operations specified by API. Non functional aspects (different constrains, environment requirements, etc.)

29. Page 29, 12 September 2015 What is an explicit context dependency? 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 party.  Provided and Required Interface  Context dependencies - Specification of the deployment environment and run-time environment Example: Which tools, platforms, resources or other components are required? Do

30. Page 30, 12 September 2015 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 party.  Late binding - dependencies are resolved at load or run-time. What does it mean deployed independently? Platform (framework) connector

31. Page 31, 12 September 2015 Example: Interface description: (M)IDL (Microsoft) Interface Definition Language [ uuid(00112233-ABBA-ABBA-ABBA-BADBADBADBAD), object ] interface IAddressList { HRESULT addAddress ([in] name, [in] address); HRESULT deleteAddress ([in] name, [in] address); }  language independent interface specification  can be compiled into language dependent code skeletons

32. Page 32, 12 September 2015 Components and Interfaces - UML definition Component – a set of interfaces required (in-interfaces) provided (out-interfaces) Interface – set of operations Operations – input and output parameters of certain type

33. Page 33, 12 September 2015 Contractually specified interfaces in a UML metamodel

34. Page 34, 12 September 2015  Is Szyperski definition enough?

35. Page 35, 12 September 2015 Component specification  Components are described by their interfaces  (A black box character) glass box black box white box grey box

36. Page 36, 12 September 2015 Nice components that can be composed (put together)

37. Page 37, 12 September 2015

38. Page 38, 12 September 2015

39. Page 39, 12 September 2015 Another definition  A software component is a software element that confirms a component model can be independently deployed composed without modification according to a composition standard.  A component model defines specific interaction and composition standards. G. Heineman, W. Councel, Component-based software engineering, putting the peaces together, Addoson Wesley, 2001

40. Page 40, 12 September 2015

41. Page 41, 12 September 2015

42. Page 42, 12 September 2015

43. Page 43, 12 September 2015

44. Page 44, 12 September 2015

45. Page 45, 12 September 2015 Summary CBSE – basic definitions  The basis is the Component  Components can be assembled according to the rules specified by the component model  Components are assembled through their interfaces  A Component Composition is the process of assembling components to form an assembly, a larger component or an application  Component are performing in the context of a component framework  All parts conform to the component model  A component technology is a concrete implementation of a component model c 1 c 2 Middleware Run-time system framework Component Model

46. Page 46, 12 September 2015 Component Technology Component Component Framework Platform Components Repository Supporting Tool

47. Page 47, 12 September 2015 Software Architecture and Software Components

48. Page 48, 12 September 2015 Software Architecture L. Bass, P. Clements, R. Kazman, Software Architecture In Practice q The software architecture of a program or computing system is the structure or structures of the system, which comprise software components [and connectors], the externally visible properties of those components [and connectors] and the relationships among them.”

49. Page 49, 12 September 2015 Aspects of Software Architecture Connector Role Port Attachment (sub)System Architectural Component Representation u Elements and Form u (UniCon notation)

50. Page 50, 12 September 2015 Two Tier Architecture Database Tier Boundary Presentation -------------- Business Logic Presentation -------------- Business Logic Database Driver Data Layer Presentation / Business Layer Presentation -------------- Business Logic Presentation -------------- Business Logic

51. Page 51, 12 September 2015 N-Tier Architecture Database Tier Boundary Business Logic Database Driver Business Logic Presentation Logic Data Layer Business Layer Tier Boundary Presentation Layer

52. Page 52, 12 September 2015 N-Tier Architecture - and Components Database Tier Boundary Business Logic Database Driver Business Logic Presentation Logic Data Layer Business Layer Tier Boundary Presentation Layer Componet componet componet componet

53. Page 53, 12 September 2015 Different architecture view in different phases  Phase I System architecture - Decomposition of the system > ComA IComA > ComB IComB > ComC IComC Conceptual Architecture

54. Page 54, 12 September 2015 System Design – Phase 2  Implementation Architecture - Component Identification > ComA IComA > ComB IComB > ComC IComC > SysX ISysX > ComY IComY Implementation Architecture

55. Page 55, 12 September 2015 System Design – Phase 3  Deployment architecture :SysX:ComC:ComA Deployment Architecture :ComB Server DataServer :ComD

56. Page 56, 12 September 2015 Basic principles of Component-based approach

57. Page 57, 12 September 2015 Main principles: (1) Reusability  Reusing components in different systems  The desire to reuse a component poses few technical constraints.  Good documentation (component specification…)  a well-organized reuse process  Similar architecture  …. C1 C2 C3C4 Application A1 C1C5 C6C7 Application A2

58. Page 58, 12 September 2015 Main principles: (2) Substitutability  Alternative implementations of a component may be used.  The system should meet its requirements irrespective of which component is used.  Substitution principles Function level Non-functional level  Added technical challenges Design-time: precise definition of interfaces & specification Run-time: replacement mechanism C1C2 C3C4 Application A1 C1´C2 C3C4 Application A1

59. Page 59, 12 September 2015 Substitution principle q Substituting a component Y for a component X is said to be safe if: l All systems that work with X will also work with Y q From a syntax viewpoint, a component can safely be replaced if: l The new component implements at least the same interfaces as the older components q From semantic point of view? l Contractual interface holds (pre-, postconditions and invariants)

60. Page 60, 12 September 2015 Substitution principle  Principle: A component can be replaced if the new component  Provide a sub-range of the output  Can accept larger range of input CONDITION. Everything which comes from the first Tube fits to the second C -  C´ Input(c) <_ Input(c’) Output(C) _> Output(C’)

61. Page 61, 12 September 2015 Main principles: (3) Extensibility  Comes in two flavors: extending components that are part of a system Increase the functionality of individual components  Added technical challenges: Design-time: extensible architecture Run-time: mechanism for discovering new functionality C1C2C3 C1C2+C3 C1C2C3 C1C2C4C3

62. Page 62, 12 September 2015 Main principles: (4) Composability  Composition of components P(c1 o c2) =P(c1) o P(c2) ?? Composition of functions Composition of extra-functional properties  Many challenges How to reason about a system composed from components?  Different type of properties  Different principles of compositions C1C2 assembly C

63. Page 63, 12 September 2015

64. Page 64, 12 September 2015

65. Page 65, 12 September 2015

66. Page 66, 12 September 2015

67. 2015-09-12 Séverine Sentilles 67 Components in Unified Modelling Language (UML)

68. 2015-09-12 Séverine Sentilles 68 Component diagram  Three representations for a component  But access points are required Utilisation of interfaces Utilisation of port C > C > C

69. Interfaces  Role: Specification of the access point Required functionalities Provided functionalities  2 existing representation The most descriptive The compact > ProvidedItf > C > RequiredItf > C ProvidedItf RequiredItf

70. 70 Ports  Role: Access point to the internal structure of the component Can have 0 or several interfaces  Representation: > C

71. 2015-09-12 Séverine Sentilles 71 Relationship between components  Use the notion of connector Roughly a way to link components together & make them ”communicate” via a request of services  Generalisation of the means of communication  Example: Client-server Pipe&filter Message exchange  Can also be called horizontal composition > Client > Server IdenticalItf

72. 2015-09-12 Séverine Sentilles 72 Vertical composition  Can also be called hierarchical composition  Role To increase the component granularity To expose the content of the component  Use the notion of delegation connector (between two ports) > C > A > B

73. 2015-09-12 Séverine Sentilles 73 Profile UML  Extension of the UML model in order to adapt it to the particular requirements of a context  Uses Stereotypes Tagged values OCL Constraints  Examples: Profile for EJB components Profile for a software architecture

74. 2015-09-12 Séverine Sentilles 74 EJB Profile

75. 2015-09-12 Séverine Sentilles 75 The component model PICOLO From “Picolo: A Simple Python Framework for Introducing Components Principles, 2005” UML Metamodel

76. Page 76, 12 September 2015 Component-based software development process

77. Page 77, 12 September 2015 Time to Market – “Classical” Development Process? Requirements Specification Design Implementation Test Product Lifecycle Problems: Time To MarketTime To Market High CostsHigh Costs Meeting deadlinesMeeting deadlines VisibilityVisibility Operation & Maintenance TIME

78. Page 78, 12 September 2015 Development process  COTS and outsourcing require different development processes Requirements Specification Design Implementation Test Find & Select Adapt Deploy

79. Page 79, 12 September 2015 Development process – emphasize reuse  Managing COTS in the early stage of the development process Requirements Specification Design Implementation Test Deploy Find & Select Adapt Test

80. Page 80, 12 September 2015 CBD – separation of development processes Requirements Specification Design Implementation Test Deploy Find & Select Adapt Test Applicationdevelopment Componentdevelopment Operation & Maintenance

81. Page 81, 12 September 2015 Types of component-based development  Internal components as structural entities  Reusable components developed in-house  COTS (commercial off the shelf) components

82. Page 82, 12 September 2015 Product Line Architecture  Core components building a core functionality (Basic platform)  A set of configurable components combined building different products

83. Page 83, 12 September 2015 Platform-based products Basic services Middleware / infrastructure Platform layer Application layer

84. Page 84, 12 September 2015 Advantages of Software Product Lines  Using existing infrastructure Savings 30%-40% of efforts per product Time to Market - improved  Larger variety of products  Uniform and recognizable functionality/interface  Better scalability (not obvious!)  Better maintainability (not obvious!)  Better possibility of component replacement

85. Page 85, 12 September 2015 The Cathedral and the Bazaar? La Sagrada Familia, Barcelona Building Started: On March 19, 1882 Still not completed Is it worth to build it in that way? Building platforms Similar with platform-based And component-based development Is it worth?

86. Page 86, 12 September 2015 Problems and research issues

87. Page 87, 12 September 2015 CBSE research and the SW life-cycle Analysis Design Implementation Testing Deployment Analysis Design Implementation Testing Deployment Analysis Design Implementation Testing Deployment Quality Management Project Management Components Application - assembly - finding - trusting - distribution - glue code - design for customization/ variability - wrapping - specification/contracts - development methods - frameworks - storage - documentation - run-time infrastructures - configuration management - certification - SW development process - team structure

88. Page 88, 12 September 2015 Specification Are more than interface method definitions  How to specify? Interfaces, behavior (pre-/post conditions, invariants) dependencies (required interfaces) quality of service  How to test/verify component specifications?  How to document component specifications?  How to automatically connect components in builder tools using their specification?  How to verify the correctness of a composite system? ...

89. Page 89, 12 September 2015 Design for reuse Design for reuse requires additional effort  What is the best level of reuse (component granularity)?  How can the benefit of reuse be measured?  Development and documentation of component usage patterns

90. Page 90, 12 September 2015 Repositories  How to store components?  How to classify and describe components?  How to find components? fast different aspects  interfaces  functionality  component model  certification level  previous usage, trust negotiable requirements

91. Page 91, 12 September 2015 Software development process  Current approach requirements - analyses - design - implementation - test  CBSE approach must include reuse component selection component test requirements reconciliation  CBSE must be supported by modeling formalisms and tools development tools

92. Page 92, 12 September 2015 Developing a component market Imperative feature for component success  Have to establish framework for …? legal aspects (licensing and warranties) technical abilities economic forces  Proven business case  Repositories, precise descriptions and search engines  Documentations and application support

93. Page 93, 12 September 2015 Versioning and configuration management  Is more complex than usually (DLL hell) especially in dynamic environments  Dependencies and composition constraints have to be resolved almost automatically consider systems comprising thousands of components  How to do safe exchange of components e.g. upgrade, without contractual specification and proof?  All of the issues above are prerequisite for uploading and downloading of components

94. Page 94, 12 September 2015 Security  Requires trust and certification  complicated by large group of (small) vendors  ‘mobile code security’ important not user access control but code access control  current mechanisms sandboxing: restricted functionality, restricted availability codesigning: not necessarily suitable to establish trust  prove of problem origin  difficulty of persecution

95. Page 95, 12 September 2015 Problems and research issues - Summary  Contracts and documentation  Design for reuse  Repositories  Software development process  Organizational changes  Developing a component market  Versioning and configuration management  Security  Component models for embedded systems

96. Page 96, 12 September 2015 Information sources Information sources

97. This presentations is based on:  Ivica Crnkovic, Magnus Larsson: Building reliable component-based systemsBuilding reliable component-based systems Chapters: PART 1The Definition and Specification of Components The Definition and Specification of Components  Chapter 1 Basic Concepts in Component-Based Software Engineering  Chapter 2 On the Specification of Components PART 2 SOFTWARE ARCHITECTURE AND COMPONENTSSOFTWARE ARCHITECTURE AND COMPONENTS  Chapter 3 Architecting Component-based Systems  Chapter 4 Component Models and Technology PART 3 DEVELOPING SOFTWARE COMPONENTS DEVELOPING SOFTWARE COMPONENTS  Chapter 6 Semantic Integrity in Component Based Development  Ivica Crnkovic: CBSE - New Challenges in Software DevelopmentCBSE - New Challenges in Software Development  Ivica Crnkovic et al: Specification, Implementation and Deployment of ComponentsSpecification, Implementation and Deployment of Components Page 97, 12 September 2015

98. Page 98, 12 September 2015 Books  Ivica Crnkovic & Magnus Larsson: CBSE - Building reliable component--based systems  Clemens Szyperski: Component Software : Beyond Object- Oriented Programming: (1998), 2003 – second edition  Alan W. Brown: Large-Scale Component-Based Development  Betrand Meyer: Object-Oriented Software Construction, 2 nd  G.T. Heineman, W. Councill: CBSE Putting the Pieces Together  J. Cheesmam, J. Daniels: UML Components  K. Wallnau: Building Systems form Commercial Components

99. Page 99, 12 September 2015 Journals  IEEE Computer  IEEE Software  IEEE Internet Computing  IEEE Transactions on Software Engineering  IEEE Transactions on Computers  ACM Transactions on Programming Languages and Systems languages and programming systems.  ACM Transactions on Software Engineering and Methodology  ACM Transactions on Computer Systems  Software Development (www.sdmagazine.com)  … all major SW development magazines

100. Page 100, 12 September 201512 September 2015 Conferences  International Conference on Software engineering (ICSE)  International Symposium of Component-based Software Engineering (CBSE) - COmpArch  Euromicro Conference on Software Engineering and Advanced Application (SEAA) – track MOCS –Model-based development, components and services  International Workshop on Component-Oriented Programming (WCOP)  Symposium on Generative and Component-Based Software Engineering  Technology of Object-Oriented Languages and Systems (TOOLS) (www.tools-conferences.com)  International Conference on Software Reuse (ICSR)  ESEC/FSE