Introduction to ComponentBased Software Engineering Ivica Crnkovic Chalmers
Introduction to Component-Based Software Engineering Ivica Crnkovic Chalmers University Mälardalen University, Sweden ivica. crnkovic@mdh. se http: //www. idt. mdh. se/~icc Page 1, 12/2/2020
Topic overview 1 The challenges of SW- how can CBD help? 2 What is a software component? 3 Basic principles of component-based approach 4 Component-based Software Development Process 5 Problems and research issues 6 References Page 2, 12/2/2020
The challenges of software development - how can component software help? Page 3, 12/2/2020
Challanges of Software Engineering (The author of slides with blue background: Michel Chaudron, Tue) Page 4, 12/2/2020
Page 5, 12/2/2020
Answer: Component-based Development q Idea: l Build software systems from pre-existing components (like building cars from existing components) l Building components that can be reused in different applications l Separate development of components from development of systems Page 7, 12/2/2020
Component-Based Software Engineering (CBSE) q Provides methods and tools for l Building systems from components l Building components as reusable units l Performing maintenance by replacement of components and introducing new components into the system Page 8, 12/2/2020
Component-based software construction (1) components Component #1 Component #4 Component #2 construction application Component #1 Component #2 Component #3 Component #4 Component #3 Page 9, 12/2/2020
Concentration on the business parts “ 30 % of SW development effort is spent on infrastructure that adds no value” Application specific Business issues GUI Standard Reusable parts Communication Data model Deployment - - - INFRASTRUCTURE Page 10, 12/2/2020
What is a software component? Page 13, 12/2/2020
Architectural point of view 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. ” Bass L. , Clements P. , and Kazman R. , Software Architecture in Practice, C 1 C 4 C 2 C 3 C 5 Page 14, 12/2/2020
Another example Object Management Architecture Overview CORBAapps CORBAdomains CORBAfacilities CORBA (Common Object Request Broker Architecture) Transactions Event Security Naming CORBAservices 12/2/2020 15
Corba component model Page 16, 12/2/2020
Frameworks - building “the real components” q Component Object Management - COM, Active X q Enterprise Java. Beans q CORBA components q. NET Word document Excel document Late binding - easy replacement My_application Excel document component Page 20, 12/2/2020
Example: The architecture of a car control system Infotaiment gateway (CAN) BUS ECU brake Sensor Actuator Sensor ECU injection Sensor Actuator Sensor ECU Sensor Actuator Sensor Vehicle mechanics ECU – Electronic Control Unit Page 21, 12/2/2020
The architectural design challenge Vehicle stability Suspension Local Control Functions Sensor Actuator Drive by wire …… Local Control Functions Sensor Complex functions Basic functions Actuator How to implement complex functions based on local control functions? Page 22, 12/2/2020
Problem: resource sharing Network resources Execution resources Sensor 1 +++++ Node 1 Actuator 1 Sensor 2 Node 2 Actuator 2 Sensor 3 +++++ Node 3 Actuator 3 Sensor. . Node … Actuator … Sensor. . +++++ Node … Actuator … Can functions of different criticality be allowed to share resources? Page 23, 12/2/2020
Challenge – open and dependable platform Antispin Collision detection Global (complex) functions Cruise control Vehicle stability Engine Control Local brake Control Transmission local ……… sensors actuators Vehicle Applications Middleware Input/output drivers Hardware ECU ECU SOFTWARE COMPONENTS Page 24, 12/2/2020
Challenge – open and dependable platform Applications C 1 C 2 Middleware Input/output drivers Hardware Requirements Separation of hw from SW development Separation of SW component development ECU ECU Page 25, 12/2/2020
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? Page 26, 12/2/2020
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 System Glue code Components How much components fit together? How much costs the glue code? Page 27, 12/2/2020
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. q Interface – component specification q Contract - A specification attached to an interface that mutually binds the clients and providers of the components. l Functional Aspects (API) l Pre- and post-conditions for the operations specified by API. l Non functional aspects (different constrains, environment requirements, etc. ) Page 28, 12/2/2020
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. q Provided and Required Interface q Context dependencies - Specification of the deployment environment and run-time environment l Example: Which tools, platforms, resources or other components are required? Do Page 29, 12/2/2020
What does it mean deployed independently? 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. Platform (framework) q Late binding - dependencies are resolved at load or run-time. connector Page 30, 12/2/2020
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 Page 32, 12/2/2020
Contractually specified interfaces in a UML metamodel Page 33, 12/2/2020
q Is Szyperski definition enough? Page 34, 12/2/2020
Component specification q Components are described by their interfaces white box q (A black box character) black box grey box glass box Page 35, 12/2/2020
Nice components that can be composed (put together) Page 36, 12/2/2020
Page 37, 12/2/2020
Page 38, 12/2/2020
Another definition q A software component is a software element that l confirms a component model l can be independently deployed l composed without modification according to a composition standard. q A component model defines specific interaction and composition standards. G. Heineman, W. Councel, Component-based software engineering, putting the peaces together, Addoson Wesley, 2001 Page 39, 12/2/2020
Page 40, 12/2/2020
Page 41, 12/2/2020
Summary CBSE – basic definitions q The basis is the Component q Components can be assembled according to the rules specified by the component model q Components are assembled through their interfaces q A Component Composition is the process of assembling components to form an assembly, a larger component or an application q Component are performing in the context of a component framework c 1 c 2 Middleware Run-time system Component Model q All parts conform to the component model q A component technology is a concrete implementation of a component model Page 45, 12/2/2020 framework
Component Technology Tool Supporting s ent pon C om m tf or Pl a ork mew a r F t onen p m o C Repository Page 46, 12/2/2020
Basic principles of Component-based approach Page 56, 12/2/2020
Main principles: (1) Reusability q Reusing components in different systems C 1 q The desire to reuse a component poses few technical constraints. F Good documentation (component specification…) F a well-organized reuse process F Similar architecture F …. C 1 C 2 C 1 C 5 C 3 C 4 C 6 C 7 Application A 1 Application A 2 Page 57, 12/2/2020
Main principles: (2) Substitutability q Alternative implementations of a component may be used. q The system should meet its requirements irrespective of which component is used. q Substitution principles l Function level l Non-functional level q Added technical challenges l Design-time: precise definition of interfaces & specification l Run-time: replacement mechanism C 1 C 2 C 3 C 4 Application A 1 C 1´ C 2 C 3 C 4 Application A 1 Page 58, 12/2/2020
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) Page 59, 12/2/2020
Substitution principle q Principle: l A component can be replaced if the new component F Provide a sub-range of the output F Can accept larger range of input C - C´ Input(c) <_ Input(c’) Output(C) _> Output(C’) CONDITION. Everything which comes from the first Tube fits to the second Page 60, 12/2/2020
Main principles: (3) Extensibility q Comes in two flavors: C 1 C 2 C 3 C 1 C 2+ C 3 C 1 C 2 C 3 l extending components that are part of a system l Increase the functionality of individual components q Added technical challenges: l Design-time: extensible architecture l Run-time: mechanism for discovering new functionality C 1 C 2 Page 61, 12/2/2020 C 4 C 3
Main principles: (4) Composability q Composition of components l P(c 1 o c 2) =P(c 1) o P(c 2) ? ? C C 1 l Composition of functions l Composition of extra-functional properties C 2 assembly q Many challenges l How to reason about a system composed from components? F Different type of properties F Different principles of compositions Page 62, 12/2/2020
Page 63, 12/2/2020
Page 64, 12/2/2020
Page 65, 12/2/2020
Page 66, 12/2/2020
Components in Unified Modelling Language (UML) Séverine Sentilles 67 2020 -12 -02
Component diagram q Three representations for a component <<component>> C C <<component>> C q But access points are required l Utilisation of interfaces l Utilisation of port Séverine Sentilles 2020 -12 -02 68
Interfaces q Role: l l l Specification of the access point Required functionalities Provided functionalities q 2 existing representation l l The most descriptive The compact <<interface>> Provided. Itf <<component>> C <<interface>> Required. Itf <<component>> C Provided. Itf Required. Itf
Ports q Role: l Access point to the internal structure of the component l Can have 0 or several interfaces q Representation: <<component> > C 70
Relationship between components q Use the notion of connector l Roughly a way to link components together & make them ”communicate” via a request of services <<component>> Server <<component>> Client Identical. Itf q Generalisation of the means of communication q Example: l Client-server l Pipe&filter l Message exchange q Can also be called horizontal composition Séverine Sentilles 2020 -12 -02 71
Vertical composition q Can also be called hierarchical composition q Role l To increase the component granularity l To expose the content of the component q Use the notion of delegation connector (between two ports) <<component>> C <<component>> A <<component>> B Séverine Sentilles 2020 -12 -02 72
Profile UML q Extension of the UML model in order to adapt it to the particular requirements of a context q Uses l Stereotypes l Tagged values l OCL Constraints q Examples: l Profile for EJB components l Profile for a software architecture Séverine Sentilles 2020 -12 -02 73
The component model PICOLO UML Metamodel Séverine Sentilles 2020 -12 -02 75 From “Picolo: A Simple Python Framework for Introducing Components Principles, 2005”
Component-based software development process Page 76, 12/2/2020
Time to Market – “Classical” Development Process? Product Lifecycle Problems: • Time To Market • High Costs • Meeting deadlines • Visibility Requirements Specification Design Implementation Test Operation & Maintenance TIME Page 77, 12/2/2020
Development process q COTS and outsourcing require different development processes Requirements Specification Design Find & Select Implementation Adapt Test Deploy Page 78, 12/2/2020
Development process – emphasize reuse q Managing COTS in the early stage of the development process Requirements Specification Design Find & Select Implementation Test Adapt Deploy Page 79, 12/2/2020
CBD – separation of development processes Requirements Application development Specification Find & Select Design Test Implementation Adapt Test Deploy Operation & Maintenance Component development Page 80, 12/2/2020
Types of component-based development q Internal components as structural entities q Reusable components developed in-house q COTS (commercial off the shelf) components Page 81, 12/2/2020
Product Line Architecture q Core components building a core functionality (Basic platform) q A set of configurable components combined building different products Page 82, 12/2/2020
Platform-based products Application layer Middleware / infrastructure Basic services Platform layer Page 83, 12/2/2020
Advantages of Software Product Lines q Using existing infrastructure l Savings 30%-40% of efforts per product l Time to Market - improved q Larger variety of products q Uniform and recognizable functionality/interface q Better scalability (not obvious!) q Better maintainability (not obvious!) q Better possibility of component replacement Page 84, 12/2/2020
Problems and research issues Page 86, 12/2/2020
CBSE research and the SW life-cycle - certification - SW development process - configuration - team structure management Project Management Quality Management Analysis Design Implementation Deployment Testing Application Components Analysis Design Implementation Deployment Testing - development methods - frameworks - design for customization/ - storage variability - documentation - wrapping - specification/contracts Implementation Testing Deployment - run-time - assembly infrastructures - finding - trusting - distribution - glue code Page 87, 12/2/2020
Specification Are more than interface method definitions q How to specify? l Interfaces, behavior (pre-/post conditions, invariants) l dependencies (required interfaces) l quality of service q How to test/verify component specifications? q How to document component specifications? q How to automatically connect components in builder tools using their specification? q How to verify the correctness of a composite system? q. . . Page 88, 12/2/2020
Design for reuse requires additional effort q What is the best level of reuse (component granularity)? q How can the benefit of reuse be measured? q Development and documentation of component usage patterns Page 89, 12/2/2020
Repositories q How to store components? q How to classify and describe components? q How to find components? l fast l different aspects Finterfaces Ffunctionality Fcomponent model Fcertification level Fprevious usage, trust l negotiable requirements Page 90, 12/2/2020
Software development process q Current approach requirements - analyses - design - implementation - test q CBSE approach must include l reuse component selection l component test l requirements reconciliation q CBSE must be supported by l modeling formalisms and tools l development tools Page 91, 12/2/2020
Versioning and configuration management q Is more complex than usually (DLL hell) l especially in dynamic environments q Dependencies and composition constraints have to be resolved almost automatically l consider systems comprising thousands of components q How to do safe exchange of components e. g. upgrade, without contractual specification and proof? q All of the issues above are prerequisite for uploading and downloading of components Page 93, 12/2/2020
Security q Requires trust and certification q complicated by large group of (small) vendors q ‘mobile code security’ important l not user access control but code access control q current mechanisms l sandboxing: restricted functionality, restricted availability l codesigning: not necessarily suitable to establish trust Fprove of problem origin Fdifficulty of persecution Page 94, 12/2/2020
Information sources Page 96, 12/2/2020
This presentations is based on: q Ivica Crnkovic, Magnus Larsson: Building reliable component-based systems l Chapters: l PART 1 The Definition and Specification of Components FChapter 1 Basic Concepts in Component-Based Software Engineering FChapter 2 On the Specification of Components l PART 2 SOFTWARE ARCHITECTURE AND COMPONENTS FChapter 3 Architecting Component-based Systems FChapter 4 Component Models and Technology l PART 3 DEVELOPING SOFTWARE COMPONENTS FChapter 6 Semantic Integrity in Component Based Development q Ivica Crnkovic: CBSE - New Challenges in Software Development q Ivica Crnkovic et al: Specification, Implementation and Deployment of Components Page 97, 12/2/2020
Books q Ivica Crnkovic & Magnus Larsson: CBSE - Building reliable component--based systems q Clemens Szyperski: Component Software : Beyond Object. Oriented Programming: (1998), 2003 – second edition q Alan W. Brown: Large-Scale Component-Based Development q Betrand Meyer: Object-Oriented Software Construction, 2 nd q G. T. Heineman, W. Councill: CBSE Putting the Pieces Together q J. Cheesmam, J. Daniels: UML Components q K. Wallnau: Building Systems form Commercial Components Page 98, 12/2/2020
Journals q IEEE Computer q IEEE Software q IEEE Internet Computing q IEEE Transactions on Software Engineering q IEEE Transactions on Computers q ACM Transactions on Programming Languages and Systems languages and programming systems. q ACM Transactions on Software Engineering and Methodology q ACM Transactions on Computer Systems q Software Development (www. sdmagazine. com) q … all major SW development magazines Page 99, 12/2/2020
Conferences q International Conference on Software engineering (ICSE) q International Symposium of Component-based Software Engineering (CBSE) - COmp. Arch q Euromicro Conference on Software Engineering and Advanced Application (SEAA) – track MOCS –Model-based development, components and services q International Workshop on Component-Oriented Programming (WCOP) q Symposium on Generative and Component-Based Software Engineering q Technology of Object-Oriented Languages and Systems (TOOLS) (www. tools-conferences. com) q International Conference on Software Reuse (ICSR) q ESEC/FSE Page 100, 12/2/2020
- Slides: 77