Component-based Software Engineering

1
Component-based Software Engineering
Motivations

• Marcello Bonsangue
• LIACS Leiden University
• Fall 2005

2
Component-based Software Engineering

• Main concerns
• Development of software from pre-produced parts
• Reuse of those parts in other applications
• Easily maintaining and customizing those parts to
  produce new features
• Goals (users demands)
• Build more reliable software
• Less time between versions

3
Component everywhere

• Concerns and goals are similar in many other
  engineering disciplines
• Precise assembly of reusable, well-documented,
  quality and trusted parts
• For them components are well established
• Civil engineering -gt house prefab,
• Chemical engineering-gt proteins,
• Electronic engineering-gt circuit,
• Industrial engineering -gt cars,

4
Example the automobile lesson

• Car assembly was a costly, tedious and slow
  process
• Henry Ford lifes goal
• Produce cars for the masses by building them
  faster
• Fords method
• The assembly line (1914)
• Idea by reversing the process of beef- trolleys
  butchers removed cuts from the carcass passed by
  until nothing remained.

5
But why not in Software engineering?

• If the goals of CBSE are no different from
  industrial and civil engineering why is CBS an
  hype only now?
• Industrial and civil engineering develop final
  products
• Software is a generic meta-product that can be
  used to create families of instances
• using different parametrizations

6
Standards

• Industrial and civil engineering successfully
  develop components because of standards,
  regulations and laws.
• Before the software crisis (1968) software had no
  standard.

7
Too less, too much

• Custom-made software
• Flexible, competitive, if it works
• Maintenance, interoperability are serious
  problems
• Very long time to market
• Fully standard software
• Short time to market
• Maintenance, interoperability and evolution are
  vendor business
• Hard to be competitive, hard to adapt

8
Standard needed

• Interaction standard for specifying the explicit
  context dependency on other software elements
• Composition standard for defining how components
  can be composed to create a larger structure and
  how a producer can replace one existing component
  with another one.

9
What are components? (I)

• A software component is not different from other
  software elements because of the programming
  language used to implement it
• The difference must be in how software components
  are used
• Components are not for real programmers.
• They are for software users
• Components are for composition
• Parts can be reused by rearranging them

10
Software users

• The PC revolution and the Internet have
  interjected a new heavy weight in the software
  arena the software consumer.
• Before consumerization of software
• Turn every user into a programmer.
• After consumerization of software
• Turn every human into a software user.

11
Two approaches to reuse

• Design a system monolithically and then find the
  parts (top-down)
• Often parts are not reusable
• Design the parts and then compose them into a
  system (bottom-up)
• Parts must be general (to be really reusable)
• but not too much (to remain practicable)

12
Software components

• A software components is a software element that
• conforms to specific interactions and composition
  standards
• can be independently deployed and composed
  without modification (according to a composition
  standard)

13
What is not a component

• The requirement for independence rules out
• Type declarations
• C macros
• C templates
• Smalltalk blocks

14
What could be a component

• Procedures
• Libraries
• Classes (not objects)
• Modules

15
What is a component

• Coarse grain
• Applications executing in the environment
  provided by an operating system
• Finer grain
• Web browsers plug-ins
• Microsoft Office documents
• Spreadsheet, document, email, web-page, database,
  presentation

16
Neither custom nor fully-standard

• Conformity to interaction and composition
  standards allow for
• robust integration
• fast time to market
• and rules out custom-made software
• Whereas independence is essential to allow for
• multiple independent vendors
• independent development
• and rules out fully-standard software

17
Component abstraction levels

• To design and develop the internals of a
  components we distinguish four levels of
  abstraction
• Component specification
• Component implementation
• Component executable
• Component deployment
• The process can be carried out using techniques
  like UML and OO programming languages, and
  methodologies supporting component production.

18
Component specification

• It includes the technology independent definition
  of the component but also information to
  facilitate the finding of a component (gap
  fulfilment)
• It may derives from
• Component producers desire
• Solution builders specific needs
• Industry standard for interactions and
  compositions

19
Component implementation

• It defines the inside of a component, with its
  internal parts and collaborations.
• It occurs after the decision of the programming
  language to use for the development
• It must satisfies the specification
• One-to-many relationship

20
Component executable

• It is the real pluggable component used in the
  assembly of the application
• Each executable may results in more than one
  version
• There may be more than one executable per
  implementation

21
Component deployment

• It is the deployment of the component executable
  on a number of nodes
• There may be several deployment for the same
  executable.

22
Component production

• A methodology for the production of components
  must support the four component abstraction
  levels
• It is different from traditional software
  production
• More time is spent for business rules, business
  process modelling, analysis, and design
• Less time is spent in development