Component-Based Software Engineering

Component Engineeringat Philips Electronics

Paul Krause

A Talk in Four Parts Prologue

Requirements Modeling for Families of Complex Systems

The Koala Component Model for Consumer Electronics Software

Epilogue

Part IPart I

The Prologue Why is Philips interested in Software?

The need for Quality

What is Quality?

Philips Electronics makes Software?

Philishave - 35k of software

Mid end TV > 4M of software

Development teams > 100

Distributed development e.g. TV development sites at Brugge, Eindhoven,

Southampton, Vienna, Bangalore, Singapore, Briarcliffe, Knoxville

The Need for Software Quality Embedded software follows Moore’s Law

doubling in size every two years

Diversity of products and their software is also increasing rapidly

Development time must decrease significantly Reliability Flexibility Extendibility Reusability.

What is Quality (or what is it not)! “Quality means conformance to requirements”

BUT!

Requirements contain >15% of all errors

Requirements typically grow at >2% per month Do you conform to requirements errors? Do you conform to new requirements? Whose requirements are you trying to satisfy?

Source: Capers Jones, 2000

Conclusion To achieve quality products we need to look at

all aspects of our development processes

In this lecture we will look at ways of improving requirements management; reducing time to market; increasing responsiveness to changes in the market

place.

Part IIPart II

Requirements Modeling for Families of Complex Systems

Based on presentation by Pierre America, Philips Research, and Jan van Wijgerden, Philips Medical Systems Presented at the 3rd Int. Workshop on Software

Architecture for Product Families, March 2000, Las Palmas de Gran Canaria, Spain.

Contents Introduction

Context

Documents

Family issues

Experience

Conclusion

Introduction: Product families

Deal explicitly with commonalities and differences

Advantages in Marketing Development Manufacturing Maintenance

Introduction: Goals

Requirements specifications for product families should

specify what can be expected from the products

be agreed on by all stakeholders

be sufficiently precise to avoid misunderstandings

deal explicitly with commonalities and differences

form a solid basis for further development

without unnecessarily limiting the designers’ freedom

Context: Medical imaging

X-Ray

CT

MR

Ultrasound

Context: Medical imaging: X-Ray

Cardio/Vascular

UniversalRadiographyandFluoroscopy

Radiography

Surgery

Context: Market and product characteristics

Mature market

complex systems

Potential hazards (radiation, electricity,

mechanics, …) high demands on products

and process

Relatively few systems, many configurations

systems cannot all be tested thoroughly

Context: Project characteristics

Vast range of expertise needed

Many (>100) developers, some new to the

domain

Carried out jointly by several departments

Time to market important

Long project duration (several years)

Long lifetime of architecture (>10 years)

Documents

Commercial Requirements Specification (CRS) positioning of system family in market

Systems Requirements Specification (SRS) features mentioned in lists and tables

Functional Requirements Specification (FRS) detailed descriptions of use cases (in English)

Requirements Object Model concepts and their relationships (in UML)

Documents: Example model

XrayBeamToDetectorPosition

SourceImageDistance

Detector

CircleShutter

DiameterSpeed

XRayBeam

ShapeIntensitySpectrum

Exposable

RectangleShutter

HeightWidthXSpeedYSpeed

Tube

VoltageCurrent

11

Generates

Shutter

Detector

Shapes

Object

Shapes

XRaySource

1

0..*

1

0..*

11

Documents: Example use case

Use case CloseCircleShutter:

When the CloseShuttersEvent is received from the ClinicalUser, then the Diameter of the Object CircleShutter is decreased with a fixed Speed, until either the StopShuttersEvent or the OpenShuttersEvent is received.

Documents: Structure of FRS

Divided into chapters according to areas of functionality: Different kinds of user (clinical user, field service. …) Different phases of workflow

Often coincides with areas of expertise of FRS authors.

Does not imply the same subdivision in design.

Examples: Administration Patient positioning Acquisition

Field service

Reviewing Printing Archiving

Family issues: Expressing variation: Object model

Specialization

Multiplicity ImagingSystem XRayDetector0 …*

XRayDetector

FilmDetector IITVDetector SolidStateDetector

AttributesXRayDetector

MaxResolution : IntMaxFrameRate : Int

Family issues: Expressing variation: Use cases

Behaviour of use cases may depend on model,

including the above variation mechanisms.

Different systems may support different sets of use cases

Result:

Precise and detailed specifications for the domain

Concise specifications for individual systems

Experience Tried out in one large development project and

several small feasibility studies

Large FRS15 chapters 500 use cases

Large requirements model100 diagrams 1000 relationships 700 classes 1500 attributes

Solid basis of shared knowledge

Effort well spent

Object model relatively immune to changes

Conclusion

We learned:

Early construction of a requirements object model provides an explicit, shared map of concepts.

Developing use cases and object model hand in hand leads to precise use cases and a complete model.

Overlapping groups allow many participants and parallel work, while maintaining consistency.

Not the individual technique counts, but the way they fit together.

Part IIIPart III

The Koala Component Model for Consumer Electronics Software

For more information, see article by Rob van Ommering, Frank van der Linden (Philips Research Laboratories, Eindhoven), Jeff Kramer and Jeff Magee (Imperial College)

Contents of Part III Motivation - the need for components

The Koala model

Coping with evolution

Conclusions

The need for components Consumer Electronics products are members of

complex family structures

Exhibit diversity in: product features user control style supported broadcasting standards hardware technology

Need to create new products by extending and rearranging elements of existing products

The need for components Object-oriented frameworks enable multiple

applications to be created from shared structure and code but changing the structure significantly is difficult

Component-based approaches let engineers construct multiple configurations with variations in both structure and content component - an encapsulated piece of software with

an explicit interface to its environment components - can be used in many different

configurations

The need for “requires” interfaces

A

B1

Product 1

A

B2

Product 2

Importing B1 into A:

• gives A access to B1

• but puts knowledge of B1 inside A

So A cannot also combine with B2

PROBLEM

A

B1

Product 3

B2

Take binding knowledge out of the components.• A requires an interface of a certain type.• B1 and B2 provide such an interface.• Binding made at the product level

SOLUTION

The Koala Model Components

units of design development and reuse

Interfaces a component communicates with its environment

through interfaces an interface is a small set of semantically related

functions

A component provides functionality through its interfaces

To do so, it may also require functionality through its interfaces

Koala’s graphical notation

CFrontEndcfre

pprg

pprg

pini

rtun rif

IProgram

CBackEndcbke

pprg

ppic

pini

rcol rscr

IPicture

CTunerDriverctun

ptun

pini

ri2c

CHipDriverchip

pcol

pini

ri2c

CHopDriverchop

pscr

pini

ri2c

pif

fast slow

m

II2cII2c

pini

IInitITuner

IIf IColorIScreen

CTvPlatformCTvPlatform

Configurations and Compound Components A configuration is a set of components

connected together to form a product all requires interfaces must be bound to precisely

one provides interface each provides interface can be bound to zero or

more requires interfaces

It may be useful to compose Compound Components from basic components But always, when binding interfaces there must be a

unique definition of each function, but a function may be called by many other functions

Conclusion Able to introduce component orientation in a

domain that is resource-constrained

Graphical notation helpful in design discussions

More than 100 software developers within Philips are currently using Koala, on an increasing diversity of products

Part IVPart IV

Epilogue

We have seen: how the need to deliver quality products in a

volatile and complex market place has driven developments in Software Engineering

how UML can be exploited to strengthen the requirements process for families of complex systems

a component model that enables new configurations to be rapidly developed for novel products

Global concerns

Mainstream TVSingapore

System HouseEindhoven

Upmarket TVBrugge

Projection TVKnoxville

Software CentreBangalore

PhilipsSemiconductors Third Parties

Digital TVBriarcliffe

Set Top BoxesParis

TVCRVienna

Hard Disk/CD-RHasselt

Software Engineering issues are vitally important

But this is not the whole story: co-ordination collaboration communication people management planning strategy technology

Conclusion