Software Life Cycle Automation for Interactive Applications: The AME Design Environment

1
Software Life Cycle Automation for Interactive
Applications The AME Design Environment
Christian Märtin Fachbereich Informatik Fachhochs
chule Augsburg D-86161 Augsburg (Germany)
2
Introduction

• Concurrent support for automating the design of
  the UI and the domain parts of interactive
  systems
• Unifying specification and generation approaches
• AME architecture and scope
• AMEs life cycle for automated model refinement
• Future work

3
Integration of the life cycles

• OO technology as the common denominator

4
Unifying specification and generation

• Balancing the ratio of flexibility vs. automation
• The designers choice at each life cycle activity
• accept the intermediate model as proposed by the
  system
• partly modify or extend the intermediate model
  interactively
• integrate reusable components into the
  intermediate model
• Model refinement knowledge
• standard knowledge for standard design problems
• optional domain or user specific knowledge for
  adaptation
• experience of the designer
• technical knowledge for automated system
  integration

5
AMEArchitecture

• Three levels
• modeling
• construction
• implementation
• OO representationscheme
• Target applications
• Business domain

6
AME life cycle model

7
OOA Modeling

• Example OOA model specification
• attributes
• operations
• gen/spec relations
• aggregations
• associations
• message channels

8
Generating the window hierarchy

• Mapping of complex OOA classes to windows, if
  possible
• expanding gen/spec relations
• exploiting attributes, attribute types, grouped
  attributes
• exploiting aggregations (to simple OOA classes)
• adopt simple OOA classes as OOD classes
• Creating the menu- and command hierarchy
• exploit target environmental constraints and
  synonym lists
• assignment of OOA operations to menu entries or
  buttons

9
Assigning interaction objects

• Exploiting qualified attribute types, if
  available
• map the attribute type to a specific OOD object
  pattern
• assign AIOs to the OOD objects
• If not activate a number of rule groups
• exploit content oriented meta data
• exploit synonym lists to find the correct
  qualified data type
• exploit the cardinality of attributes and/or
  operations
• refinement of already assigned AIOs
• Apply user or environment-specific rule groups

10
UI behavior spec

• AME exploits
• OOA/D-messages, relationalOOA/D patterns,
  embeddedcode fragments
• to automatically specify
• menu/command activation,inter-object
  communication,method code integration
• Designer adds domainspecific dynamics

11
Layout generation

• Layout simulation
• choosing dialogboxand window typesautomatically
• standard set oflayout alternatives
• user/env. profiles
• additional forwardchained rule sets
• interactive layoutmodification

12
Target application generation

• Scanning/Parsing the detailed specification
• Generating C-code, callbacks, defaults
• Integration of existing domain method code
• Integration of standard dialog boxes and behavior
• Integration of reusable major application parts
• Activating the Borland C-compiler
• As an alternative a UIMS interface exists

13
Conclusions and future work

• Benefits
• complete prototypical life cycle support for
  interactive system development
• automating many standard UI design tasks the
  time gained can be used for domain modeling and
  refinements
• Drawbacks
• AME needs a relatively long incremental learning
  process
• modeling system level dialog dynamics is time
  consuming
• Future
• Borland Delphi, multimedia, new domains, OO
  synergies

14
Thank you for your attention!