Component-Based Software Engineering

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

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

3. Part I The Prologue • Why is Philips interested in Software? • The need for Quality • What is Quality?

4. 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

5. 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.

6. 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

7. 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.

8. Part 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.

9. Contents • Introduction • Context • Documents • Family issues • Experience • Conclusion

10. Introduction: Product families • Deal explicitly with commonalities and differences • Advantages in • Marketing • Development • Manufacturing • Maintenance

11. 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

12. MR Ultrasound X-Ray CT Context: Medical imaging

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

14. 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

15. 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)

16. 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)

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

18. Documents: Example use case Use case CloseCircleShutter: • When the CloseShuttersEvent is received from the ClinicalUser, then the Diameter of the ObjectCircleShutter is decreased with a fixed Speed, until either the StopShuttersEvent or the OpenShuttersEvent is received.

19. 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

20. XRayDetector FilmDetector IITVDetector SolidStateDetector • Multiplicity 0 …* ImagingSystem XRayDetector • Attributes XRayDetector MaxResolution : Int MaxFrameRate : Int Family issues: Expressing variation: Object model • Specialization

21. 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

22. 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

23. 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.

24. Part 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)

25. Contents of Part III • Motivation - the need for components • The Koala model • Coping with evolution • Conclusions

26. 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

27. 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

28. PROBLEM SOLUTION Product 1 Product 2 Product 3 A A A B1 B2 B1 B2 • Importing B1 into A: • gives A access to B1 • but puts knowledge of B1 inside A So A cannot also combine with 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 The need for “requires” interfaces

29. 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

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

31. 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

32. 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

33. Part IV Epilogue

34. 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

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

36. Conclusion • Software Engineering issues are vitally important • But this is not the whole story: • co-ordination • collaboration • communication • people management • planning • strategy • technology The End!