Developing Engineered Product Support Applications
description
Transcript of Developing Engineered Product Support Applications
2000-Aug-31 SPLC1 Talk 1/25
Developing Engineered Product Support Applications
H. James Hoover, Tony Olekshy, Garry Froehlich, Paul Sorenson
Software Engineering Research Laboratory, Computing Science,University of Albertawww.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
2/25SPLC1 Talk2000-Aug-31
Outline
• Engineered Product Domain
• Common Application Product Line Requirements
• Frameworks
• Killer Best Practices
• Conclusion
2000-Aug-31 SPLC1 Talk 3/25
Our Context
EngineeredProductManufacturer
EngineeredProductPurchaser
SoftwareBuilder
Product Tools
Requirements
2000-Aug-31 SPLC1 Talk 4/25
Application Domain Context
Engineer’s Requirements
Engineering Standards
Product Catalog
Ordering of Engineered
Product
Tool Support
Engineered ProductSizing and Selecting
Domain Variability
Platform Variability
Workflow Variability
2000-Aug-31 SPLC1 Talk 5/25
Business Process Context
2000-Aug-31 SPLC1 Talk 6/25
Application Requirements
• Product Specific
• Engineering Process
• Generic Support
• Uncertainty Everywhere
2000-Aug-31 SPLC1 Talk 7/25
Engineering Tool Manifesto
Consistent
Observable
Verifiable
Auditable
Extensible
Thou shalt be:
2000-Aug-31 SPLC1 Talk 8/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?
2000-Aug-31 SPLC1 Talk 9/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
2000-Aug-31 SPLC1 Talk 10/25
Engineering Requirements
Consistent
Observable
Verifiable
Auditable
Extensible
•Preserve internal & displayed values.
•Trace calculation internally.
•Use external program to verify.
2000-Aug-31 SPLC1 Talk 11/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.
2000-Aug-31 SPLC1 Talk 12/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!
2000-Aug-31 SPLC1 Talk 13/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.
2000-Aug-31 SPLC1 Talk 14/25
User Agents
Forms/Wizards
Business Objects
Domain SpecificServices
FoundationServices
UI Manager
Persistent ObjectManager
DB-Centric PLA
2000-Aug-31 SPLC1 Talk 15/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.
2000-Aug-31 SPLC1 Talk 16/25
Killer Features
• Engineering Features
• Core Features
• Persistence Features
2000-Aug-31 SPLC1 Talk 17/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
2000-Aug-31 SPLC1 Talk 18/25
EAF Calculation Block
Inputs OutputsExternals
localsX, Y Z
A B
T
T = AX+BYZ = T + 2
2000-Aug-31 SPLC1 Talk 19/25
EAF Worksheet
U
X
Y
C.A C.B
C:
C.T
D.A D.B
D:
D.TZ
X
2000-Aug-31 SPLC1 Talk 20/25
2000-Aug-31 SPLC1 Talk 21/25
Workflow
2000-Aug-31 SPLC1 Talk 22/25
Core Features
• Trouble Stack
• Data Signatures
• Configuration Report
• HTML Reports and Displays
• Apalon markup language
• Handbook writer’s assistance
2000-Aug-31 SPLC1 Talk 23/25
Persistence Features
• Object Model, ID, Foreign Keys
• Concurrent Transaction Consistency
• Referential Integrety
• Journalling, Roll-forward, Revision Control
• Replication
• Schema Conversion
2000-Aug-31 SPLC1 Talk 24/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.
2000-Aug-31 SPLC1 Talk 25/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.