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.