Component-Based Software Engineering

1
Component-BasedSoftware Engineering

• M.R.V. Chaudron
• www.win.tue.nl/mchaudro
• Dept. of Mathematics and Computing Science
• Eindhoven University of Technology

2
This lecture

• Obstacles to CBD
• CBD Process
• domain engineering

3
Obstacles to CBD
4
Some Obstacles to CBSD

• Organizational Concerns
• who pays for extra development effort?
• (for making components more generic, flexible,
  ..)
• cost of learning

5
Some Obstacles to CBSD

• Commercial Concerns
• No established market!
• No Software shops
• marketing, licensing, trading,
• Legal issues liability (aansprakelijkheid)
• Business model (pay-per-copy vs. pay-per-use)

6
Some Obstacles to CBSD

• Technical Concerns
• Method for Design of Components
• balance genericity, flexibility,
• Adequate tools are needed
• in particular for integration of third party
• components
• Need for Common/Standardized
• architectures
• component model
• data model
• specification methods

7
Domain Engineering
8
What is Domain Engineering ?
Typically, organisations build many systems in a
single domain
Goal Capitalize the experience/expertise
acquired in building systems, in order to build
new systems more efficiently

• Domain Engineering is the activity of collecting,
  organizing and
• storing experience in building systems in a
  particular domain
• using reusable assets
• providing means for reuse
• retrieval, dissemination, adaptation, assembly

Assets may be software, but also requirements,
domain models In general domain knowledge
9
What is Domain Engineering?

• ... the process of producing, maintaining and
  cataloging reusable assets, to make them
  available to application engineering teams.

10
References on Domain Engineering

• FODA Feature Oriented Domain Analysis
• Kang, K., et al. Feature-Oriented Domain
  Analysis (FODA) Feasibility Study
  (CMU/SEI-90-TR-21, ADA 235785). Pittsburgh, PA
  Software Engineering Institute, Carnegie Mellon
  University, 1990.
• ODM Organization Domain Modelling
• Simos, M., et al. Software Technology for
  Adaptable Reliable Systems (STARS) Organization
  Domain Modeling (ODM) Guidebook Version 2.0
  (STARS-VC-A025/001/00). Manassas, VA Lockheed
  Martin Tactical Defense Systems, 1996. Also
  available online http//www.asset.com/WSRD/abstrac
  ts/ABSTRACT_1176.html
• Survey papers
• Arango, G. "Domain Analysis Methods," 17-49.
  Software Reusability. Chichester, England Ellis
  Horwood, 1994.

11
References on Domain Engineering

• Reuse-Based Software Engineering Techniques,
  Organization and Controls, H. Mili, A. Mili, S.
  Yacoub, E. Addy, Wiley Sons, 2002

12
Domain Engineering inputs and outputs
Dom.Eng. Methods
Mngmt. Procedures
Taxonomies
Domain literature
Standards
Existing Appl. Documentation
Dom. Models
Customer Surveys
Components
Expert Advice
Domain Expert
Domain Analysts
Domain Engineer
13
Domain Engineering Process

• Domain Identification Scoping
• What is inside/outside the domain
• Identify stakeholders
• Domain Analysis
• Establish lexicon
• Identify commonalities/variabilities
• Define a set of reusable requirements
• Domain Design
• Establish a common architecture for the domain
• Domain Implementation
• Engineer Asset Base / Implement reusable assets
• e.g. models, components, generators, reuse
  infrastructure, ..

14
Domain Engineering enabled Application Engineering
Domain Engineering
Development Domain SW Architecture
Implement Reusable Assets
Domain Analysis
Reusable Assets Tools
Domain Model
Domain Software Architecture
Domain Model Based Analysis
User Reqs
Domain Arch.-Based Design
Application Development
Application Model
Application Architecture
Application
Application Engineering
15
Domain Analysis

• The process by which a software engineer learns
  about the domain to better understand the
  problem
• The domain is the general field of business or
  technology in which the clients will use the
  software
• A domain expert is a person who has a deep
  knowledge of the domain
• Benefits of performing domain analysis
• Anticipation of extensions
• Aquire expertise to fill in gaps in available
  information

16
Domain Analysis

• A domain model is an explicit representation of
• knowledge about the domain

• Domain model consists of
• Domain lexicon
• Concept models (using e.g. diagrams, formalisms,
  )
• Feature models

17
Features
According to FODA A prominent and user-visible
aspect, quality or characteristic of a
system. ODM A distinguishable characteristic
of a system that is relevant to a stakeholder
of the system
In mobile telephones - polyphonic ringtones -
SMS, MMS - dual, tri-band, -
In cars - airco - power-steering - remote
key-lock -
18
Feature models

• Types of features
• Mandatory All systems must have it
• e.g. A car must have an engine
• Alternative
• A system must have one out of multiple options
• e.g. Transmission may be manual or automatic
• Optional A system may have a feature
• e.g. A car may have air-conditioning

19
Feature Diagram
A hierarchical decomposition of features. A
concept higher in the tree consists of its
children
car
optional
engine
wheels
airco
steering wheel
transmission
alternative
mandatory (default)
manual
automatic

• Additional annotations that may be used in the
  feature diagram
• mutually exclusive features
• rationale for chosing between alternatives
• composition rules airco may be used if
  horsepowergt100

20
Example Domain Analysis document

• A. Introduction
• B. Glossary
• C. General knowledge about the domain
• D. Customers and users
• E. The environment
• Tasks and procedures currently performed
• Vision on future of domain
• Competing software
• Similarities to other domains

21
Domain Eng. vs Software Eng.
Software Engineering Domain Engineering
Analysis Requirements for single system Reusable requirements for a class of systems
Design Design of one system Reusable designs for a class of systems
Implementation Implemented system Reusable components, infrastructure and production process
22
Maintaining Domain Models

• Businesses and their environments change.
• Hence Domain Models should be maintained.

23
CBD Process
24
Typical Activities of a SE Project

• Problem Analysis
• Requirement Engineering
• Architecture Design
• Subsystem Design
• Implementation Unit Test
• Integration System Test
• Deployment
• Maintenance
• (De)comission

25
Consumer and Producer Processes
Two concurrent processes
Domain Model
Domain Software Architecture
Consumer aims to build systems using existing
components
Producer aims to build component to supply to
consumers
Application Architecture
Reusable Assets Tools
Application
26
CBD Consumer Process (1)

• Problem Understanding
• Requirement Engineering
• list (sub)system requirements
• determine (sub)system test-cases
• Component Reconnaisance
• Survey available Components
• Shortlist Candidates
• CBD Architecture Design

The components selected influence the
architecture!
27
CBD Consumer Process (2)

• CBD Architecture Design
• Chose a component model
• proprietary vs. industry-provided
• Indentify dependencies across components
• Design space is typically limited to a set of
  assemblies
• i.e. discrete set of particular combinations of
  components

28
CBD Consumer Process (3)

• Finding/Locating Components
• search internal (department/company) repositories
• search external repositories
• Component Selection
• Component/Assembly Evaluation
• Vendor Selection
• Build vs. Buy-decision
• Component Acquisition
• Component understanding
• Acquirer testing
• Build Custom Software

29
CBD Consumer Process (4)

• Component Integration
• wrapping
• adapting/tailoring
• installing/configuring
• verification validation of assembly system
• test system-wide properties
• Component Maintenance
• when to update with a new version
• when to switch to another vendor
• Component Decomission

30
Consumer Persective

• primary criterium
• suitable functional extra-functional
  properties
• How will the component affect the behaviour of
  other components in the system?
• Components inevitably interact through resource
  use
• What does a component require of other components
  in the system?
• Who is responsible for
• maintenance of the component in the system?
• failures in the final system?
• Producer or assembler?

31
Consumer Persective

• Vendor selection
• reputation
• product quality
• service quality
• expected business continuity

32
Selection Criteria

• Process
• how fast can the component be delivered?
• how much time will it take to integrate?
• how much time will it take to maintain?
• Product
• does it provide required functionality?
• does it not provide superfluous functionality?
• quality/cost ratio?

33
Component versus Assembly Selection

• What count are the properties of the final
  systems.
• These are not necessarily those of individual
• components.
• Instead of evalutating components, we should
  evaluate
• assemblies.

34
CBD Production Activities (1)

• Assess market-potential
• what are current and future needs?
• what exists in the market?
• Identify/Scope components
• balance genericity vs. (size, complexity, )
• select variability
• Implement Components
• documentation / specification

35
CBD Production Activities (2)

• Verify Components
• Certification by 3rd party
• Packaging
• Distribution
• insert into repository

36
Concluding Remarks
37
Questions?

• You should know
• component design guidelines
• what domain engineering is
• how to read make feature-diagrams
• CBD process

Self-Study material - Chapter .. from Mili