Component-Based Software Engineering Component Engineering at Philips Electronics Paul Krause

A Talk in Four Parts v Prologue v Requirements Modeling for Families of Complex Systems v The Koala Component Model for Consumer Electronics Software v Epilogue

Part I The Prologue v Why is Philips interested in Software? v The need for Quality v What is Quality?

Philips Electronics makes Software? v Philishave - 35k of software v Mid end TV > 4M of software v Development teams > 100 v Distributed development  e.g. TV development sites at Brugge, Eindhoven, Southampton, Vienna, Bangalore, Singapore, Briarcliffe, Knoxville

The Need for Software Quality v Embedded software follows Moore’s Law  doubling in size every two years v Diversity of products and their software is also increasing rapidly v Development time must decrease significantly  Reliability  Flexibility  Extendibility  Reusability.

What is Quality (or what is it not)! v “Quality means conformance to requirements” BUT! v Requirements contain >15% of all errors v 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 v To achieve quality products we need to look at all aspects of our development processes v 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 II Requirements Modeling for Families of Complex Systems v 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 v Introduction v Context v Documents v Family issues v Experience v Conclusion

Introduction: Product families v Deal explicitly with commonalities and differences v Advantages in  Marketing  Development  Manufacturing  Maintenance

Introduction: Goals Requirements specifications for product families should v specify what can be expected from the products v be agreed on by all stakeholders v be sufficiently precise to avoid misunderstandings v deal explicitly with commonalities and differences v form a solid basis for further development v without unnecessarily limiting the designers’ freedom

Context: Medical imaging X-Ray CT MR Ultrasound

Context: Medical imaging: X-Ray Cardio/Vascular Universal Radiography and Fluoroscopy Radiography Surgery

Context: Market and product characteristics v Mature market  complex systems v Potential hazards (radiation, electricity, mechanics, …)  high demands on products and process v Relatively few systems, many configurations  systems cannot all be tested thoroughly

Context: Project characteristics v Vast range of expertise needed v Many (>100) developers, some new to the domain v Carried out jointly by several departments v Time to market important v Long project duration (several years) v Long lifetime of architecture (>10 years)

Documents v Commercial Requirements Specification (CRS)  positioning of system family in market v Systems Requirements Specification (SRS)  features mentioned in lists and tables v Functional Requirements Specification (FRS)  detailed descriptions of use cases (in English) v Requirements Object Model  concepts and their relationships (in UML)

Documents: Example model XrayBeamToDetectorPosition SourceImageDistance Detector CircleShutter Diameter Speed XRayBeam Shape Intensity Spectrum Exposable RectangleShutter Height Width XSpeed YSpeed Tube Voltage Current 11 Generates Shutter Detector Shapes Object Shapes XRaySource 1 0..* 1 11

Documents: Example use case Use case CloseCircleShutter: v 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 v Specialization v Multiplicity ImagingSystemXRayDetector 0 …* XRayDetector FilmDetectorIITVDetectorSolidStateDetector v Attributes XRayDetector MaxResolution : Int MaxFrameRate : Int

Family issues: Expressing variation: Use cases v Behaviour of use cases may depend on model, including the above variation mechanisms. v Different systems may support different sets of use cases Result: v Precise and detailed specifications for the domain v Concise specifications for individual systems

Experience v Tried out in one large development project and several small feasibility studies v Large FRS 15 chapters500 use cases v Large requirements model 100 diagrams1000 relationships 700 classes1500 attributes v Solid basis of shared knowledge v Effort well spent v Object model relatively immune to changes

Conclusion We learned: v Early construction of a requirements object model provides an explicit, shared map of concepts. v Developing use cases and object model hand in hand leads to precise use cases and a complete model. v Overlapping groups allow many participants and parallel work, while maintaining consistency. v Not the individual technique counts, but the way they fit together.

Part III The Koala Component Model for Consumer Electronics Software v 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 v Motivation - the need for components v The Koala model v Coping with evolution v Conclusions

The need for components v Consumer Electronics products are members of complex family structures v Exhibit diversity in:  product features  user control style  supported broadcasting standards  hardware technology v Need to create new products by extending and rearranging elements of existing products

The need for components v Object-oriented frameworks enable multiple applications to be created from shared structure and code  but changing the structure significantly is difficult v 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 v Components  units of design development and reuse v Interfaces  a component communicates with its environment through interfaces  an interface is a small set of semantically related functions v A component provides functionality through its interfaces v To do so, it may also require functionality through its interfaces

Koala’s graphical notation CFrontEnd cfre pprg pini rtun rif IProgram CBackEnd cbke pprg ppic pini rcol rscr IPicture CTunerDriver ctun ptun pini ri2c CHipDriver chip pcol pini ri2c CHopDriver chop pscr pini ri2c pif fastslow m II2c pini IInit ITuner IIfIColor IScreen CTvPlatform

Configurations and Compound Components v 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 v 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 v Able to introduce component orientation in a domain that is resource-constrained v Graphical notation helpful in design discussions v More than 100 software developers within Philips are currently using Koala, on an increasing diversity of products

Part IV Epilogue

We have seen: v how the need to deliver quality products in a volatile and complex market place has driven developments in Software Engineering v how UML can be exploited to strengthen the requirements process for families of complex systems v a component model that enables new configurations to be rapidly developed for novel products

Global concerns Mainstream TV Singapore System House Eindhoven Upmarket TV Brugge Projection TV Knoxville Software Centre Bangalore Philips Semiconductors Third Parties Digital TV Briarcliffe Set Top Boxes Paris TVCR Vienna Hard Disk/CD-R Hasselt

v Software Engineering issues are vitally important v But this is not the whole story:  co-ordination  collaboration  communication  people management  planning  strategy  technology Conclusion