ComponentBased Software Engineering Component Engineering at Philips Electronics

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 - 35 k of software v Mid end TV > 4 M of software v Development teams > 100 v Distributed development v 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 v doubling in size every two years v Diversity of products and their software is also increasing rapidly v Development time must decrease significantly v Reliability v Flexibility v Extendibility v 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 v Do you conform to requirements errors? v Do you conform to new requirements? v 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 v improving requirements management; v reducing time to market; v 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 v Presented at the 3 rd 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 v Marketing v Development v Manufacturing v 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 MR Ultrasound X-Ray CT

Context: Medical imaging: X-Ray Universal Radiography and Fluoroscopy Cardio/Vascular 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) v positioning of system family in market v Systems Requirements Specification (SRS) v features mentioned in lists and tables v Functional Requirements Specification (FRS) v detailed descriptions of use cases (in English) v Requirements Object Model v concepts and their relationships (in UML)

Documents: Example model XRay. Source Tube Voltage Current 1 1 XRay. Beam Generates 1 Shape Intensity Spectrum Exposable Detector Shapes Detector Object Xray. Beam. To. Detector. Position Shutter Source. Image. Distance 0. . * Circle. Shutter Diameter Speed Rectangle. Shutter Height Width XSpeed YSpeed

Documents: Example use case Use case Close. Circle. Shutter: v When the Close. Shutters. Event is received from the Clinical. User, then the Diameter of the Object Circle. Shutter is decreased with a fixed Speed, until either the Stop. Shutters. Event or the Open. Shutters. Event is received.

Documents: Structure of FRS Divided into chapters according to areas of functionality: v Different kinds of user (clinical user, field service. …) v Different phases of workflow Often coincides with areas of expertise of FRS authors. Does not imply the same subdivision in design. Examples: v Administration v Reviewing v Patient v Printing positioning v Acquisition v Field service v Archiving

Family issues: Expressing variation: Object model XRay. Detector v Specialization Film. Detector v Multiplicity v Attributes Imaging. System IITVDetector 0 …* XRay. Detector Max. Resolution : Int Max. Frame. Rate : Int Solid. State. Detector XRay. Detector

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 chapters 500 use cases v Large requirements model 100 diagrams 1000 relationships 700 classes 1500 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: v product features v user control style v supported broadcasting standards v 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 v but changing the structure significantly is difficult v Component-based approaches let engineers construct multiple configurations with variations in both structure and content v component - an encapsulated piece of software with an explicit interface to its environment v components - can be used in many different configurations

The need for “requires” interfaces PROBLEM SOLUTION Product 1 Product 2 Product 3 A A A B 1 B 2 Importing B 1 into A: • gives A access to B 1 • but puts knowledge of B 1 inside A So A cannot also combine with B 2 B 1 B 2 Take binding knowledge out of the components. • A requires an interface of a certain type. • B 1 and B 2 provide such an interface. • Binding made at the product level

The Koala Model v Components v units of design development and reuse v Interfaces v a component communicates with its environment through interfaces v an interface is a small set of semantically related functions v A component interfaces provides functionality through its v To do so, it may also interfaces require functionality through its

Koala’s graphical notation pprg CTv. Platform IProgram pprg pini CFront. End cfre rif rtun pini ppic pini rcol IPicture pprg CBack. End cbke rscr m IInit ITuner IIf ptun pini CTuner. Driver ctun ri 2 c IColor pif pini fast pcol CHip. Driver chip ri 2 c II 2 c IScreen pscr pini CHop. Driver chop ri 2 c slow II 2 c

Configurations and Compound Components v A configuration is a set of components connected together to form a product requires interfaces must be bound to precisely one provides interface v each provides interface can be bound to zero or more requires interfaces v all v It may be useful to compose from basic components v But Compound Components 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 TVCR Vienna Software Centre Bangalore Digital TV Briarcliffe Hard Disk/CD-R Hasselt System House Eindhoven Upmarket TV Brugge Set Top Boxes Paris Projection TV Knoxville Mainstream TV Singapore Philips Semiconductors Third Parties

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