developing engineered product support applications n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Developing Engineered Product Support Applications PowerPoint Presentation
Download Presentation
Developing Engineered Product Support Applications

Loading in 2 Seconds...

play fullscreen
1 / 25

Developing Engineered Product Support Applications - PowerPoint PPT Presentation


  • 65 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Developing Engineered Product Support Applications' - mervin


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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

Work supported by Natural Sciences and Engineering Research Council of Canada and National Research Council of Canada

V1.3

SPLC1 Talk

outline
Outline
  • Engineered Product Domain
  • Common Application Product Line Requirements
  • Frameworks
  • Killer Best Practices
  • Conclusion

SPLC1 Talk

our context

Requirements

Tools

Product

Our Context

Software

Builder

Engineered

Product

Manufacturer

Engineered

Product

Purchaser

SPLC1 Talk

application domain context
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

application requirements
Application Requirements
  • Product Specific
  • Engineering Process
  • Generic Support
  • Uncertainty Everywhere

SPLC1 Talk

engineering tool manifesto
Engineering Tool Manifesto

Thou shalt be:

Consistent

Observable

Verifiable

Auditable

Extensible

SPLC1 Talk

engineering requirements
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

engineering requirements1
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

engineering requirements2
Engineering Requirements

Consistent

Observable

Verifiable

Auditable

Extensible

  • Preserve internal & displayed values.
  • Trace calculation internally.
  • Use external program to verify.

SPLC1 Talk

engineering requirements3
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

engineering requirements4
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

product line architecture
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

slide14

User Agents

Forms/Wizards

Business Objects

Domain Specific

Services

UI Manager

Persistent Object

Manager

Foundation

Services

DB-Centric PLA

SPLC1 Talk

framework design goals
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

killer features
Killer Features
  • Engineering Features
  • Core Features
  • Persistence Features

SPLC1 Talk

engineering features
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

eaf calculation block
EAF Calculation Block

A

B

Externals

Inputs

Outputs

X, Y

Z

locals

T = AX+BY

Z = T + 2

T

SPLC1 Talk

eaf worksheet
EAF Worksheet

C:

X

X

C.A

C.B

Y

C.T

D:

D.A

D.B

Z

U

D.T

SPLC1 Talk

workflow
Workflow

SPLC1 Talk

core features
Core Features
  • Trouble Stack
  • Data Signatures
  • Configuration Report
  • HTML Reports and Displays
  • Apalon markup language
  • Handbook writer’s assistance

SPLC1 Talk

persistence features
Persistence Features
  • Object Model, ID, Foreign Keys
  • Concurrent Transaction Consistency
  • Referential Integrety
  • Journalling, Roll-forward, Revision Control
  • Replication
  • Schema Conversion

SPLC1 Talk

conclusion
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

conjecture intuition
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