FH Augsburg - FB Informatik 1 CADUI'96 - 5-7 June 1996 - FUNDP Namur Software Life Cycle Automation...

FH Augsburg - FB Informatik 1 CADUI'96 - 5-7 June 1996 - FUNDP Namur

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

Design EnvironmentDesign Environment

Christian Märtin

Fachbereich InformatikFachhochschule Augsburg

D-86161 Augsburg (Germany)


IntroductionIntroduction

• 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 • AME´s life cycle for automated model refinement• Future work


Integration of the life cyclesIntegration of the life cycles• OO technology as the common denominator

UI Design

Support

Problem

Domain

Design

Support

(e.g. OOD)

UI

Implemen-

tation

Support

Problem

Domain

Implemen-

tation

Support

Runtime

Code

Generation

Support

(Problem

Domain

and

UI Parts)

SupportingTechniques

and Tools for Problem

Domain

Requirement

Analysis

(e.g.OOA)


Unifying specification and generationUnifying specification and generation

• Balancing the ratio of flexibility vs. automation– The designer´s 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


AMEAMEArchitectureArchitecture

• Three levels:– modeling

– construction

– implementation

• OO representationscheme

• Target applications:– Business domain

OODevelopTool ODE

Model Base

AME

Object-Oriented

Model

Representation

Model Base

Presentation

and Layout

Dynamic

Behavior

Construction

Structure-

Refinement

AME/C++-

Code

Generator

KAPPA-PC

Runtime

Environ-

ment

UIMS

Inter-

face

AIOs, User Profiles

Env. Profiles

Structural and

Presentational

Knowledge

Domain Code

Fragments


AME life cycle modelAME life cycle model

Links to

external

CASE tools

Links to

external

CASE tools

Links to

external

CASE tools

Adding

OOD-Features

manually

(e.g. Structure of

Menu-Hierarchy)

Adding

Interaction

Objects

manually

OOA-

Modeling:

Specification

of Domain

Classes

Semi-automatic

Specification

of UI-Dynamics

Automatic

Generation of

Layout-Prototype

Generating C++-

Source Code /

Embedding Domain

Functionality

Automatic OOA

to OOD

Structure

Generation

Automatic AIO

SelectionActivity 1:

Analysis

Activity 2:

Global Design

Activity 3:

Detailed Object Design

Activity 4:

Generating

User Interface Behavior

Specification

Activity 5:

Adaptation to Specific

Users and Environments

Activity 6:

C++-Program Generation

and Compilation


OOA ModelingOOA Modeling

• Example OOA model specification– attributes

– operations

– gen/spec relations

– aggregations

– associations

– message channels


Generating the window hierarchyGenerating 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


Assigning interaction objectsAssigning 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


UI behavior specUI behavior spec

• AME exploits– OOA/D-messages, relational

OOA/D patterns, embeddedcode fragments

to automatically specify – menu/command activation,

inter-object communication,method code integration

• Designer adds domainspecific dynamics


Layout generationLayout generation

• Layout simulation– choosing dialogbox

and window typesautomatically

– standard set oflayout alternatives

– user/env. profiles– additional forward

chained rule sets– interactive layout

modification


Target application generationTarget 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


Conclusions and future workConclusions 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


Thank you for your attention!

FH Augsburg - FB Informatik 1 CADUI'96 - 5-7 June 1996 - FUNDP Namur Software Life Cycle Automation...

Documents

Transcript of FH Augsburg - FB Informatik 1 CADUI'96 - 5-7 June 1996 - FUNDP Namur Software Life Cycle Automation...