2. 2000-Aug-31SPLC1 Talk1/25 Developing Engineered Product Support Applications H. James Hoover, Tony Olekshy, Garry Froehlich, Paul Sorenson Software Engineering Research Laboratory, Computing Science, University of Alberta www.cs.ualberta.ca/~serl Avra Software Lab Inc., www.avrasoft.com www.avrasoft.com Work supported by Natural Sciences and Engineering Research Council of Canada and National Research Council of Canada V1.3

3. 2000-Aug-31SPLC1 Talk2/25 Outline Engineered Product Domain Common Application Product Line Requirements Frameworks Killer Best Practices Conclusion

4. 2000-Aug-31SPLC1 Talk3/25 Our Context Engineered Product Manufacturer Engineered Product Purchaser Software Builder Product Tools Requirements

5. 2000-Aug-31SPLC1 Talk4/25 Application Domain Context Engineer’s Requirements Engineering Standards Product Catalog Ordering of Engineered Product Tool Support Engineered Product Sizing and Selecting D omain Variability Platform Variability Workflow Variability

6. 2000-Aug-31SPLC1 Talk5/25 Business Process Context

7. 2000-Aug-31SPLC1 Talk6/25 Application Requirements Product Specific Engineering Process Generic Support Uncertainty Everywhere

8. 2000-Aug-31SPLC1 Talk7/25 Engineering Tool Manifesto Consistent Observable Verifiable Auditable Extensible Thou shalt be:

9. 2000-Aug-31SPLC1 Talk8/25 Engineering Requirements Consistent Observable Verifiable Auditable Extensible All tools have consistent behaviour and feel. How are: values and associated units displayed and entered? base units maintained within calculations? changes brought to the attention of the user?

10. 2000-Aug-31SPLC1 Talk9/25 Engineering Requirements Consistent Observable Verifiable Auditable Extensible The tool should ensure that the user is aware of what: has been completed remains to be done are effects of current action

11. 2000-Aug-31SPLC1 Talk10/25 Engineering Requirements Consistent Observable Verifiable Auditable Extensible Preserve internal & displayed values. Trace calculation internally. Use external program to verify.

12. 2000-Aug-31SPLC1 Talk11/25 Engineering Requirements Consistent Observable Verifiable Auditable Extensible Tools must be able to: check their inputs for tampering or corruption, produce outputs with the same properties. Want equivalence to a stamped and signed drawing.

13. 2000-Aug-31SPLC1 Talk12/25 Engineering Requirements Consistent Observable Verifiable Auditable Extensible Make it possible for the engineer user to extend the tool. But preserve all the preceding properties!

14. 2000-Aug-31SPLC1 Talk13/25 Product Line Architecture Our PLA is a set of domain specific application frameworks. Each sub-framework provides a small set of services. An application is a collection of services, with various degrees of coupling.

15. 2000-Aug-31SPLC1 Talk14/25 User Agents Forms/Wizards Business Objects Domain Specific Services Foundation Services UI Manager Persistent Object Manager DB-Centric PLA

16. 2000-Aug-31SPLC1 Talk15/25 Framework Design Goals Make it easy to evolve the UI and workflow. Preserve engineering integrity of the application under evolution. Support deployment-related activities. Anticipate refactoring of services between sub-frameworks.

17. 2000-Aug-31SPLC1 Talk16/25 Killer Features Engineering Features Core Features Persistence Features

18. 2000-Aug-31SPLC1 Talk17/25 Engineering Features Worksheet navigation Worksheet language Basis and Display Units Special Input Widgets Check Worksheets Worksheet version migration External Testing Hooks Database Access Keys

19. 2000-Aug-31SPLC1 Talk18/25 EAF Calculation Block InputsOutputs Externals locals X, Y Z AB T T = AX+BY Z = T + 2

20. 2000-Aug-31SPLC1 Talk19/25 EAF Worksheet U X Y C.A C.B C: C.T D.AD.B D: D.T Z X

21. 2000-Aug-31SPLC1 Talk20/25

22. 2000-Aug-31SPLC1 Talk21/25 Workflow

23. 2000-Aug-31SPLC1 Talk22/25 Core Features Trouble Stack Data Signatures Configuration Report HTML Reports and Displays Apalon markup language Handbook writer’s assistance

24. 2000-Aug-31SPLC1 Talk23/25 Persistence Features Object Model, ID, Foreign Keys Concurrent Transaction Consistency Referential Integrety Journalling, Roll-forward, Revision Control Replication Schema Conversion

25. 2000-Aug-31SPLC1 Talk24/25 Conclusion Didn’t develop all at once, important to support evolution. Architecture is more important than implementation (thick => thin). Framework embodies process and practices of domain and developer.

26. 2000-Aug-31SPLC1 Talk25/25 Conjecture/Intuition Architectures that survive variability over time survive variability over space. We should be building a best practices catalog of reference architectures. There may be no quantitative theory of architecture.