Download presentation
Presentation is loading. Please wait.
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.
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.