1 / 25

Developing Engineered Product Support Applications

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.

mervin
Download Presentation

Developing Engineered Product Support Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 Work supported by Natural Sciences and Engineering Research Council of Canada and National Research Council of Canada V1.3 SPLC1 Talk

  2. Outline • Engineered Product Domain • Common Application Product Line Requirements • Frameworks • Killer Best Practices • Conclusion SPLC1 Talk

  3. Requirements Tools Product Our Context Software Builder Engineered Product Manufacturer Engineered Product Purchaser SPLC1 Talk

  4. Application Domain Context Domain Variability Engineered Product Sizing and Selecting Engineer’s Requirements Ordering of Engineered Product Engineering Standards Tool Support Workflow Variability Platform Variability Product Catalog SPLC1 Talk

  5. Business Process Context SPLC1 Talk

  6. Application Requirements • Product Specific • Engineering Process • Generic Support • Uncertainty Everywhere SPLC1 Talk

  7. Engineering Tool Manifesto Thou shalt be: Consistent Observable Verifiable Auditable Extensible SPLC1 Talk

  8. Engineering Requirements • 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? Consistent Observable Verifiable Auditable Extensible SPLC1 Talk

  9. Engineering Requirements • The tool should ensure that the user is aware of what: • has been completed • remains to be done • are effects of current action Consistent Observable Verifiable Auditable Extensible SPLC1 Talk

  10. Engineering Requirements Consistent Observable Verifiable Auditable Extensible • Preserve internal & displayed values. • Trace calculation internally. • Use external program to verify. SPLC1 Talk

  11. Engineering Requirements • 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. Consistent Observable Verifiable Auditable Extensible SPLC1 Talk

  12. Engineering Requirements Consistent Observable Verifiable Auditable Extensible • Make it possible for the engineer user to extend the tool. • But preserve all the preceding properties! SPLC1 Talk

  13. 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. SPLC1 Talk

  14. User Agents Forms/Wizards Business Objects Domain Specific Services UI Manager Persistent Object Manager Foundation Services DB-Centric PLA SPLC1 Talk

  15. 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. SPLC1 Talk

  16. Killer Features • Engineering Features • Core Features • Persistence Features SPLC1 Talk

  17. Engineering Features • Worksheet navigation • Worksheet language • Basis and Display Units • Special Input Widgets • Check Worksheets • Worksheet version migration • External Testing Hooks • Database Access Keys SPLC1 Talk

  18. EAF Calculation Block A B Externals Inputs Outputs X, Y Z locals T = AX+BY Z = T + 2 T SPLC1 Talk

  19. EAF Worksheet C: X X C.A C.B Y C.T D: D.A D.B Z U D.T SPLC1 Talk

  20. SPLC1 Talk

  21. Workflow SPLC1 Talk

  22. Core Features • Trouble Stack • Data Signatures • Configuration Report • HTML Reports and Displays • Apalon markup language • Handbook writer’s assistance SPLC1 Talk

  23. Persistence Features • Object Model, ID, Foreign Keys • Concurrent Transaction Consistency • Referential Integrety • Journalling, Roll-forward, Revision Control • Replication • Schema Conversion SPLC1 Talk

  24. 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. SPLC1 Talk

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

More Related