1. Introduction to Component-Based Software Engineering
Ivica Crnkovic
Mälardalen University,
Department of Computer Engineering
Sweden
Page 1, 25 April 2017

2. Topic overview 1 The challenges of SW- how can CBD help?
What is a software component?
Software Architecture and Software Components
Basic principles of component-based approach
Component-based Software Development Process
Problems and research issues
References
Page 2, 25 April 2017

3. Part 1 The challenges of software development - how can component software help?
Page 3, 25 April 2017

4. NATO conf 1968
SW crisis
SW engineering
components
Software problems
How to develop high quality software in an efficient an inexpensive way?
The “software crisis” (1968) still exists:
SW is late
SW is buggy
SW is expensive
SW is difficult to understand
Software is difficult to maintain (problems with software life cycle)
Page 4, 25 April 2017

5. SW Productivity Gap (ITEA)
Page 5, 25 April 2017

6. Challanges of Software Engineering
(The author of slides with blue background: Michel Chaudron, TUe
Page 6, 25 April 2017

7. Page 7, 25 April 2017

8. Software paradigm shift
Productivity
© 2001 ITEA Office Assoc
ITEA-Softec project
Agent-based development
Component-based development
Object-Oriented Development
Structured programming
Time
Design method
SA/SO
UML
ADL’s
???
COBOL, C FORTRAN, ADA
Smalltalk C++
C++ Java
Agglets ?
Language
We have been moving system organisation since the 70-ies from mainframe to client server to the current N-tier distributed systems in development, moving towards self organising SW systems.
We started software engineering technologies with structured programming (Structured Analysis and Organisation) and moved through Object-Oriented development now to Component-Based Technologies. The next step maybe Agent-based. Aspect based
OO and CBT allows us to improve the requirements and system modeling, to set up SW development platforms based on re-use and COTS, using Architecture Design Languages at design level
We are working at technologies to support distributed SW development.
However, the Component based development is not yet well understood and broadly used. Large problems remain, e.g. including non-functional requirements at the design phase, scalability of architectures and design patterns, testing and validation in particular in a distributed environment, reconfiguration.
At the same time we need to work towards the next step to allow connectivity for pervasive computing, dynamic reconfigurability, to create self-organising and self-correcting software.
We could call this “agent-based development”
We can be confident that the Information Society will come over us. How beneficial it will be and when the various steps will be made, depends on how we will address the challenges ahead.
The above considerations will certainly shape the planning currently ongoing for the sixth FP.
System organization
Mainframe
Client-server
N-tier distributed
Self-organizing
1970
1990
2000
2005
Page 8, 25 April 2017

9. 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
Page 9, 25 April 2017

10. 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
Page 10, 25 April 2017

11. Component-based software construction (1)
components
Component #1
construction
application
Component
Component
Component #1 #2 #4
Component #2
Component
Component
Component #3 #3 #4
Page 11, 25 April 2017

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

13. Is CBD the same as OOP? Object Object Attributes Attributes Methods
Object-oriented programming
Object
Attributes
Methods
Object
Attributes
Methods
Message
Are objects the same as components?
Page 13, 25 April 2017

14. 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
Page 14, 25 April 2017

15. Part 2 What is a software component?
Page 15, 25 April 2017

16. Architectural point of view
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 C3 C5
Page 16, 25 April 2017

17. Another example Object Management Architecture Overview
CORBAapps
CORBAdomains
CORBAfacilities
CORBA (Common Object Request Broker Architecture)
This is the Object Management Architecture. It is not read top-down or bottom-up, but rather inside-out:
The most important component is the Object Request Broker (ORB). This is responsible for providing access to clients and servers to discover objects (applications), discover their interfaces, make requests and receive responses.
Everything else in the architecture is an object, communicating with other objects via the ORB. We categorize objects into three groups based on one criterion: when the standardization process will get to them:
Object Services are the low-level services that must be available on all platforms in a distributed system (e.g., lifecycle);
Common Facilities are the commonly-found services in particular distributed systems (e.g., , print queueing);
Application Objects are the high-level applications themselves (e.g., spreadsheets, word processors, programmable controllers).
Transactions
Event
Security
Naming
CORBAservices
4/25/2017

18. Corba component model
Page 18, 25 April 2017

19. 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)
Page 19, 25 April 2017

20. 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
Page 20, 25 April 2017

21. 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 file | 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 ...
Page 21, 25 April 2017

22. 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
Page 22, 25 April 2017

23. Example: The architecture of a car control system
Infotaiment
gateway
(CAN) BUS
ECU
Sensor
Actuator
ECU
Sensor
Actuator
brake
injection
ECU
Sensor
Sensor
Actuator
Vehicle mechanics
ECU – Electronic Control Unit
Page 23, 25 April 2017

24. The architectural design challenge
Vehicle stability
Suspension
Drive by wire ……
Complex functions
Local Control Functions
Local Control Functions
Basic functions
Sensor
Sensor
Sensor
Actuator
Sensor
Actuator
How to implement complex functions based on local control functions?
Page 24, 25 April 2017

25. 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 25, 25 April 2017

26. Challenge – open and dependable platform
Collision detection
Antispin
Global (complex) functions
Cruise control
Vehicle stability
local
Engine Control
Local brake Control
Transmission
………
sensors
actuators
Vehicle
Applications
ECU
SOFTWARE COMPONENTS
Middleware
Input/output drivers
Hardware
Page 26, 25 April 2017

27. Challenge – open and dependable platform
Applications
Middleware
Input/output drivers
Hardware
ECU
ECU
ECU
Requirements
Separation of hw from SW development
Separation of SW component development
Page 27, 25 April 2017

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

29. Composition unit How much costs the glue code?
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?
System
Glue code
Components
Page 29, 25 April 2017

30. 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.)
Page 30, 25 April 2017

31. 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
Page 31, 25 April 2017

32. 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.
Late binding - dependencies are resolved at load or run-time.
Platform (framework)
connector
Page 32, 25 April 2017

33. Example: Interface description: (M)IDL
(Microsoft) Interface Definition Language [
uuid( 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
- IDL language independent
- or strongly typed languages (e.g. also C header files)
- based on ADTs
- particularly interesting in the face of distribution (how does type info flow to server or client side)
Page 33, 25 April 2017

34. 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
UML metamodel of the concepts used in syntactic specification of software components
Page 34, 25 April 2017

35. Contractually specified interfaces in a UML metamodel
Page 35, 25 April 2017

36. Is Szyperski definition enough?
Page 36, 25 April 2017

37. Component specification
Components are described by their interfaces
(A black box character)
white box
black box
grey box
glass box
Page 37, 25 April 2017

38. Nice components that can be composed (put together)
Page 38, 25 April 2017

39. Page 39, 25 April 2017

40. Page 40, 25 April 2017

41. 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
Page 41, 25 April 2017

42. Page 42, 25 April 2017

43. Page 43, 25 April 2017

44. Page 44, 25 April 2017

45. Page 45, 25 April 2017

46. Page 46, 25 April 2017

47. 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
Page 47, 25 April 2017

48. Component Technology Supporting Tool Components Platform
Component Framework
Repository
Page 48, 25 April 2017

49. Part 3 Software Architecture and Software Components
Page 49, 25 April 2017

50. Software Architecture
L. Bass, P. Clements, R. Kazman, Software Architecture In Practice
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.”
Page 50, 25 April 2017

51. Aspects of Software Architecture
Elements and Form
(UniCon notation)
Attachment
Architectural Component
Connector
Representation
Port
Role
(sub)System
Page 51, 25 April 2017

52. Presentation / Business Layer
Two Tier Architecture
Presentation
Business Logic
Presentation
Business Logic
Database Driver
Presentation / Business Layer
Tier Boundary
Data Layer
Database
Page 52, 25 April 2017

53. N-Tier Architecture Presentation Logic Presentation Layer
Tier Boundary
Business Logic
Business Logic
Business Logic
Database Driver
Business Layer
Tier Boundary
Data Layer
Database
Page 53, 25 April 2017

54. N-Tier Architecture - and Components
Componet
componet
Presentation Logic
Presentation Layer
Tier Boundary
componet
Business Logic
Business Logic
Business Logic
componet
Database Driver
Business Layer
Tier Boundary
Data Layer
Database
Page 54, 25 April 2017

55. Different architecture view in different phases
Phase I
System architecture - Decomposition of the system
<<subsystem>>
ComA
IComA
<<subsystem>>
ComB
IComB
<<subsystem>>
ComC
IComC
Conceptual
Architecture
Page 55, 25 April 2017

56. System Design – Phase 2
Implementation Architecture - Component Identification
Implementation
Architecture
<<imp>>
ComA
<<imp>>
ComB
IComA
IComB
<<imp>>
ComC
IComC
<<imp>>
ComY
IComY
<<imp>>
SysX
ISysX
Page 56, 25 April 2017

57. System Design – Phase 3 Deployment architecture Server Deployment
:ComA
:ComB
DataServer
:SysX
:ComC
:ComD
Page 57, 25 April 2017

58. Basic principles of Component-based approach
Page 58, 25 April 2017

59. 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 C1 C2 C1 C5 C3 C4 C6 C7
Application A1
Application A2
Page 59, 25 April 2017

60. 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 C1 C2 C3 C4
Application A1
C1´ C2 C3 C4
Application A1
Page 60, 25 April 2017

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

62. Substitution principle
A component can be replaced if the new component
Provide a sub-range of the output
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 62, 25 April 2017

63. 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 C1 C2 C3 C1
C2+ C3 C1 C2 C3 C1 C2 C4 C3
Page 63, 25 April 2017

64. 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 C C1 C2
assembly
Page 64, 25 April 2017

65. Page 65, 25 April 2017

66. Page 66, 25 April 2017

67. Page 67, 25 April 2017

68. Page 68, 25 April 2017

69. Part 5 Component-based software development process
Page 69, 25 April 2017

70. 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 70, 25 April 2017

71. Development process
COTS and outsourcing require different development processes
Requirements
Specification
Design
Implementation
Test
Find & Select
Adapt
Deploy
Page 71, 25 April 2017

72. Development process – emphasize reuse
Managing COTS in the early stage of the development process
Requirements
Specification
Design
Implementation
Test
Find & Select
Test
Adapt
Deploy
Page 72, 25 April 2017

73. CBD – separation of development processes
Requirements
Application
development
Specification
Find & Select
Design
Test
Implementation
Adapt
Test
Deploy
Operation & Maintenance
Component
development
Page 73, 25 April 2017

74. Types of component-based development
Internal components as structural entities
Reusable components developed in-house
COTS (commercial off the shelf) components
Page 74, 25 April 2017

75. Product Line Architecture
Core components building a core functionality
(Basic platform)
A set of configurable components combined building different products
Page 75, 25 April 2017

76. Platform-based products
Application layer
Middleware / infrastructure
Basic services
Platform layer
Page 76, 25 April 2017

77. 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
Page 77, 25 April 2017

78. Building platforms 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?
Similar with platform-based
And component-based development
Is it worth?
Page 78, 25 April 2017

79. Part 6 Problems and research issues
Page 79, 25 April 2017

80. CBSE research and the SW life-cycle
- SW development process
- configuration
management
- certification
- team structure
Project Management
Quality Management
Analysis
Design
Implementation
Testing
Deployment
Application
Components
Analysis
Design
Implementation
Testing
Deployment
- assembly
- finding
- trusting
- distribution
- glue code
Analysis
Design
Implementation
Testing
Deployment
- development
methods
- frameworks
- run-time
infrastructures
- design for
customization/
variability
- wrapping
- specification/contracts
- storage
- documentation
Design for Customization/Variability, Wrapping, Specification:
Software product lines, Variability patterns
Wrapping of legacy code, componentification of OO code e.g. based on inheritance trees(FZI work with CAP580)
Storage, Documentation
component repositories (see later)
docu as part of code?, separate document, how formal, etc.
Development Methods, Notations, Frameworks
Methods: RUP, Catalysis, KobrA, Select
Identification of components, design of component frameworks
Notation languages: UML/OCL, Alloy (new from MIT), Z
Finding and trusting of components, Assembly Application Distribution
Composition models
Glue code, automatic bridges
Certification
classification, test procedures per class of components
legal issues
Page 80, 25 April 2017

81. 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?
...
Page 81, 25 April 2017

82. 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
Page 82, 25 April 2017

83. 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
Page 83, 25 April 2017

84. 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
Page 84, 25 April 2017

85. 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
Page 85, 25 April 2017

86. 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
Page 86, 25 April 2017

87. 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
Page 87, 25 April 2017

88. 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
Page 88, 25 April 2017

89. Part 7 Information sources
Page 89, 25 April 2017

90. This presentations is based on:
Ivica Crnkovic, Magnus Larsson: Building reliable component-based systems
Chapters:
PART 1 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 COMPONENTS
Chapter 3   Architecting Component-based Systems
Chapter 4    Component Models and Technology
PART 3   DEVELOPING SOFTWARE COMPONENTS 
Chapter 6    Semantic Integrity in Component Based Development
Ivica Crnkovic: CBSE - New Challenges  in Software Development
Ivica Crnkovic et al: Specification, Implementation and Deployment of Components
Page 90, 25 April 2017

91. Books
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, 2nd
G.T. Heineman, W. Councill: CBSE Putting the Pieces Together
J. Cheesmam, J. Daniels: UML Components
K. Wallnau: Building Systems form Commercial Components
Ivica Crnkovic & Magnus Larsson: CBSE - Building reliable component--based systems
Page 91, 25 April 2017

92. 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 (
… all major SW development magazines
Page 92, 25 April 2017

93. Conferences
International Workshop on Component-Based Software Engineering, ICSE, CBSE
Euromicro CBSE track
Page 93, 25 April 2017

94. Conferences International Conference on Software engineering (ICSE)
ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA) (oopsla.acm.org)
International Workshop on Component-Oriented Programming (WCOP)
Symposium on Generative and Component-Based Software Engineering
Technology of Object-Oriented Languages and Systems (TOOLS) (
International Conference on Software Reuse (ICSR)
ESEC/FSE
Page 94, 25 April 2017