1. Software Component Engineering v1.0, April 24, 2002 Frode L. Ødegård Ødegård Labs, Inc. http://www.odegard.com © 2002 Ødegård Labs, Inc. All Rights Reserved. Ødegård Labs, Inc.

2. Presentation Overview Where did the idea of software components come from? What motivates software components? Software components today (April 2002) –The good, the bad and the ugly Software Component Engineering as a discipline What can we expect in the near-term future (2-4 years)? Questions

3. “Software components (…), to be widely applicable to different machine and users, should be available in families arranged according to precision, robustness, generality and time- space performance.”

4. M. D. McIlroy, “Mass produced software components” NATO Conference on Software Engineering, Garmish, Germany, October 1968 http://www.cs.ncl.ac.uk/people/brian.randell/home.formal/NATO/index.html

5. Motivation for components System design benefits –Parcel up understanding of how the system works, maintained by teams/people –Can reduce risks in system design due to improved knowledge management –Prediction of system performance can be easier –Modifying system design can be easier Program/project management benefits –Improved prediction of effort and rework –Improved prediction of schedule Reuse savings –Internal components can be reused to save on cost/effort/schedule –External components can be licensed (cheaper and better than do-it-yourself) Your mileage may vary!

6. Evolution of “component” idea 1968 1970s, 1980s 1985 1997 subroutines (McIlroy) modules, classes (Simula-67/C++ classes, Modula-2 modules, Ada packages) Software ICs (Brad Cox, BYTE Magazine) “components are binary units of… deployment” (Clemens Szypersky, “Component Software: Beyond O-O Programming”)

7. Modern definition of components Clemens Szypersky, “Component Software: Beyond O-O Programming”, 1997 “Software components are binary units of independent production, acquisition and deployment that interact to form a functioning system.”

8. “A Software Component is a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard.” Another definition of components.. George T. Heineman and William T. Councill. Component Based Software Engineering. Addison Wesley, 2001

9. Commercial use of components Widespread component models –OMG: CORBA –Microsoft: COM  DCOM .NET –Sun: Java  EJB  J2EE Early marketplace for components –www.componentsource.com –www.flashline.com –http://www.vbxtras.com/ –…–… Trend towards certification –ASQ: Certified Software Quality Engineer –IEEE: Certified Software Development Professional –Sun: Sun Certified Programmer/Developer/Web Component Developer for Java 2 –Microsoft: Microsoft Certified Application Developer (MCAD) and Solution Developer (MCSD) The good

10. Commercial use of components Marketing and Engineering not on the same page w.r.t. Components –Components require an investment: Licensing of external IP Design of good interfaces for reusable components Selection of component model (“Packaging technology”) Design for use in (speculative?) future products –How do we know that it’s worth it? Do we understand the risks? Will the ROI be sufficient? The bad

11. Commercial use of components Poor software development practices –Component design in actual practice has not progressed much since 1968 –Components have weak specifications –Validation of components is uneven –Companies struggle with spaghetti legacy systems –“Reuse” by cut-n-paste still very common, causes severe problems Transitioning to Component Based Software Engineering is hard –Many new standards developing, how do we pick the “right” one(s)? –Companies need to invest in education –Companies need to invest in tools –In spite of risk and cost, the alternative may be worse! –Management often does not understand that this is a paradigm shift The ugly

12. Paradigm shift: component reuse BeforeAfter CultureProject-focusedComponent-focused How we workCraftsmanshipEngineering What we makeProject-specific Programs Components with Predictable Quality StrategyTop-downBottom-up? Planning HorizonLength of project Lifetime of product platform

13. A New Discipline? Division of labor driven by economic considerations –Interchangeable parts caused revolution in manufacturing –Reuse of software components motivated by speed-to-market –Industries organize to maximize ROI –Professional roles shaped by needs of organization Software Professionals likely to continue specializing –Project/Program Management –Quality/Process –Testing –Usability –Programmer –Analyst –Architect Software Component Engineer Software Architect Software Requirements Engineer

14. Software Component Engineer KSAs Knowledge –Software Engineering Best Practices –Relevant industry and technical standards –Component technologies –Programming languages and development tools Skills –Write precise and complete component interface specifications –Design components using appropriate development tools –Validate component design using static checking tools, Inspection, etc. –Write implementation code using appropriate tools –Verify implementation against design using Inspection, testing etc. –Validate implementation against specification –Write and execute quality/test plans Abilities –Critical thinking –Problem solving –Sees the big picture

15. What Should We Expect From a Component Engineering Method/Process? Independent of particular component model Extensible – adaptable to future technologies and techniques Well-defined activities for component specification, design, implementation, verification and validation Well-defined list of artifacts that are consumed and produced Well-defined metrics for activities and artifacts Standardized templates, rule sets and checklists Tool support for improved productivity Supporting documentation and courseware

16. Some Existing Methods/Processes Product-line oriented methods –FODA –FAST –PuLSE –KobrA Object-oriented method frameworks –Rational Unified Process –OPEN –Catalyst Other methods –Clean Room –Ødegård Labs: Darwin Process Framework

17. Darwin: Component Engineering Process Identify Component Requirements Architecture Component Concept Doc.Component Interface Spec. Component Design Spec. Source codeVerification ReportValidation Report Specify Component Interface Validate Component Interface Design Component Validate Component Design Implement Component DesignVerify Component Implementation Validate Component Implementation

18. Requirements Capture Design/Select Architecture High-level evolutionary plan Select and plan next step Execute planned step Deliver to real users Evaluate feedback “micro-projects” Darwin: Evolutionary Delivery Identify Analyze Plan Track Resolve Learn risks

19. Darwin: Domain Engineering Process Domain Engineers Architecture Groups Common understanding of domain requirements Spawns new architectures Anticipated future product family needs Product Marketing Engineering Product Family Architecture Feedback from product teams Product Family Requirements Architecture support, training, documentation, …

20. Near-Term Future of SCE Certification trend will extend to software architects and software component engineers Design/development tools will support better specification and verification –Contract-based interface specifications will be everywhere –Architecture-level design tools will let you plug components together safely –Architecture and Component Design tools will become collaborative –Static checking tools will improve (see ESC Project) –Model checking will be used for verification of many components Component technologies will continue to improve –Load-time proof-checking (proof-carrying code) –Improved support for fault-tolerance and mobility Abstraction levels will continue to rise, but so will complexity Marketing and Engineering will develop a better understanding of component tradeoffs

21. Conclusions Software components are motivated by economic factors similar to those that have influenced other engineering disciplines Software component “packaging technology” has improved vastly since 1968, but design and implementation is still mostly ad-hoc Software component engineering evolving as a distinct discipline –Implications for career planning Software components raise challenging questions for executives –Is your company an intelligent customer of component vendors? –Is your company going to offer components to its customers? –Is there a software component capability gap between you and your competitors?

22. Questions? Speaker: Frode L. Ødegård (frode@odegard.com) Organization: Ødegård Labs, Inc. (http://www.odegard.com)