Software Engineering of Virtual World

1
Software Engineering of Virtual World

• Jinseok Seo
• Duknam Kim
• Junae Kim
• Postech VR

2
Contents

• Introduction
• ASADAL/PROTO
• LOD Engineering
• Software Reuse and FORM

3
Introduction

• Major Aspects of VR Application

Input Process
Input Devices
World Database
Simulation Process
Rendering Process
Output Devices
4

• Difficulties in VR Applications
• Importance of the time
• real-time simulation and rendering
• latency by input devices
• Complex and Interactive Behaviors
• messy programming code or slow script languages
• not easy to verify or validate
• Separation of Form and Behavior

5
Software Engineering of VR Application

• Incremental and Hierarchical Development
• Specification
• Verification validation
• Object-oriented and spiral process
• simulation and visualization
• VR Object Form Function Behavior
• Function computing components in an object and
  data between them
• Behavior dynamic state changes and interactions
• Form spatial properties

6
ASADAL/PROTO

• A CASE Tool for Real-time Systems
• Incremental and Hierarchical Modeling
• Form Simulation and Visualization

ASADAL/SPEC
ASADAL/SIM
ASADAL/ PROVER
ASADAL/PROTO
(Specification)
(Simulation)
(Form and Environment)
(Formal Analysis)
- Process specification - Simulation control
program - Simulation driver program - Data
analysis
- Object modeling - Environment simulation -
Interface to visual simulation
- MSD - DFD - Statecharts
- Reachability Graphs - RTTL
7
ASADAL/PROTO Framework
MSD
objects and their interactions
for spatial objects
for functional objects

• Concurrent consideration of form, function and
  behavior

8
ASADAL/PROTO Structure
9
(No Transcript)
10
Specification with ASADAL/PROTO
Statecharts
Unified Classes
MSD
DFD
VOS
11
Statecharts
State Diagram
Statecharts
Depth
Orthogonality
Broadcast Communication
12
Statechart Objects
state_label
State (label)
Transition (label)
transition_label
transition_label
Default transition (label)
parallel_state
And-line

Connectors
C
H
13
Depth

• Notion of depth, hierarchy, or modularity
• Stepwise, top-down, or bottom-up development

14
Orthogonality

• Concurrency in a natural way

15
Broadcast Communication

• Synchronization

16
State Hierarchy
state1

• state2, state3, and state4 are XOR-children
  of state1
• if state1 is the current state, only one of the
  XOR-children is the current state

state2
state4
state3
state1

• state2 and state3 are parallel children of
  state1.
• state4 and state5 are XOR-children of state2.
• When state1 is the current state, both state2 and
  state3 are the current state also.

state2 state3
state6
state4
state7
state5
17
Guard/Action Specificatoin (GAS)

• GAS is used in many parts of the ASADAL
  specification.
• Transition label
• more than one GAS actions are separated by ,s
  and executed sequentially
• In the state specification, process
  specification, etc.
• Each GAS statements are terminated by s
• GAS action is executed if the guard is satisfied
• Guard event_speccondition_spec

18
Event Specification

• Expression in the form of the parentheses,
  (and)s and (or)s of event.
• Satisfied when the given combination of the
  events is occurred at the moment.
• Events are instantaneous, that is, it shoud be
  sensed when occurred.
• eg)
• floorSensed/reached
• reached/currentFloora
• reached floorSensed/tr!(bottomReached)

19
Condition Specification

• Expression in the form of the (and)s and
  (or)s of conditions
• Condition values(true/false) are permanent like
  other variables.
• comparators

20
Action Specification

• Generaing events
• generate event in the action
• ev1condA/ev2
• Assignments
• sum mathscore englishscore
• Multiple actions are separated by comma(,)s
• ev1condA/ev2, ev3, a3

21
GAS Examples

• Tm(en(a), 3)!overweight doorClosed/tr!(movable
  )
• reachedlevelGaplt30/openDoor

22
Transition Labels

• All transitions except default transitions should
  have non-empty guard.
• Default transitions must have empty guard and
  action is otional

/ev
state1
state1
state1
state1
ev
cond
evcond
state2
state2
state2
state2
23
Condition Connector

• Exactly one outgoing flow should be triggered
  when a condition connector is entered

state2
evcond
state1
valgt50
C
val50
state3
vallt50
state4
24
History Connector

• When a history connector is entered, it restores
  the status of the same level states to be same as
  the status when the state nesting the connector
  is exited
• Outgoing transition from the history connector is
  used when theres no histroy saved in the
  connector

25
Deep History Connector

• It saves the status of every predecessors, not
  saving only of the same level children

in
moving
out
H
walk
idle
run
26
State Specification

• OnEntry
• 
  eventAconditionA/actionA
• ...
• During
• 5 /actionB // actionB is
  performed for every 5 time ticks
• OnExit
• eventBconditionB/actionC
• ...
• Processes activations can be specified as
  following in the action segment period /
  activate(process1, process2, ) where processes
  are activated sequentially.
• When period is omitted and the process to be
  executed is not a terminal process, it will be
  activated when the state is entered and
  deactivated when it exits.
• Statements are processed line by line.s

27
Syntactic Rules

• States should not be overlapped
• When a state has XOR children, there should be
  one child which is the destination of a default
  transition.
• A transition should start and end at a state
  except the default transition.

(x)
28
Operational Semantics of ASADAL Statecharts

• A Statechart is executed step by step.
• Very small(can be ignored) time is elapsed during
  a step.
• Every enabled parallel transitions are fired in a
  single step.
• Every change(events, data, conditions, current
  states) in a step make effect on the next step.
• Lifetime of an event is a single step.

29
Data Flow Diagram

• The Components

Process(name)
name
Controller(name)
name
Data Store(name)
name
Control Flow
label
Flow(label)
label
Data Flow
External Process(name)
name
30
The Process
Process(internal)
External Process
name
name
Identify the functions that the system is
carrying out.
31
The Flow

• Describes the movement of chunks, or packets of
  information from one part of the system to
  another part(process)
• ASADAL sees the data flow as a queue between the
  source to the destination process.
• Control flows are momentary. They are expired in
  a single step.

Control Flow
label
Data Flow
label
32
The Data Store

• Used to model a collection of data packets at
  rest
• When the data is operated at different times

order
order
How are they different?
33
Process Hierarchy

• should be balanced

A
process
A
C
decompose
C
B
B
B
34
Process Specification

• Lowest level process may specified by a
  computation specification
• Process computeDestination
• Input
• Int reachedFloor
• Int nextDestination
• Output
• Int direction
• Int cageControl
• Var
• Static Int tmpData
• Int i
• Int reachedF, destF
• Arrived(nextDestination)
  Arrived(reachedFloor) (5)
• reachedF Get(reachedFloor)
• destF Get(nextDestination)
• cageControl UP

35

• Statements
• assignments
• event generation
• tr!, fs!
• put action eg) put(a)
• if (condition) statements else staatements
• while(condition) statements
• Expression can include calling external functions
• eg) func1(a, b, c)

36
Controller
controller

• Controller makes the processes activate or
  inactivate.
• The behavior is specified by a Statechart
  diagram.
• A controller gathers DFD process information via
  events(exp. later), data, conditions existing on
  the DFD diagram.

request
A
C
order
B
37
State-Process Binding

• A process must have a state activating it.
• Parallel processes should be activated by
  parallel states

38
Visual Object Specification

• Physical properties and configuration
• Specified as attributes and equations relating
  them(shape, material, position, velocity,
  acceleration, force, etc.)
• VOS built-in library
• Motion hierarchy

39

• Inter-object Spatial Rules
• Inter-object Spatial Constraints

Class Transport Inherit FixedObject
Vect surfaceVelocity Bool active
... Rule On(MovingObject, Transport) and
activeTrue -gt MovingObject.velocity
Transport.surfaceVelocity EndClass
// AGVs should not interfere each
other. Constraint AGV agv1, agv2 agv1 ! agv2 -gt
not(interfere(agv1, agv2))
40
LOD Engineering of VR Objects
Object Identification / Polygon budgeting
Co-modeling and Simulation
Performance Estimation / Model Selection
41
Object Identification / Polygon Budgeting

• Polygon budget table for a system that can
  process about 7,000 polygons for a given frame
  rate
• Initial guidance for a more detailed object
  modeling process

42
Co-Modeling of Objects

• Initial Model
• Concurrent Refinement of Form, Function and
  Behavior

G0
G1
G2
G3
B0
B1
B2
B3
43
Behavior Refinement Operations

• Decomposition
• b1 Decomposition into OR states
• b2 Decomposition into AND states
• Addition
• b3 Addition of OR states
• b4 Addition of AND states

A
A
B
C
C
A
A
A
B
A
B
44
Switch Rule(Default Current State Decision)
45
Geometry Refinement Motion Hierarchy

• Motion of a child in a motion hierarchy depends
  on that of its parent
• Joint 1 moves when Link 1 moves
• When a gripper grips an object, the object
  follows the movement of the gripper

Joint 1
Link 1
46
Geometry Refinement Operation

• Decomposition g1
• Addition g2
• Replacement g3

R
R
A
C
B
A
A
B
R
R
A
B
47
LOD Model

• Definition 1 Geometric LOD Gn
• Gn gi (Gn-1)
• (the first non-null LOD is created by the user)
• Definition 2 Behavioral LOD Bn
• Bn bi (Bn-1)
• (the first non-null LOD is created by the user)
• Definition 3 An LOD Ln
• Ln (Gi , Bj)
• (Gi and Bj must be compatible)
• Definition 4 Bi is not Compatible with Gj ,
  when Bi refers the parameters or components
  those are not specified in Gj, yet.

48
Refinement Tree
49
Compatibility between G and B

• Compatible Behavior Models with Gi
• Compatible Geometric Models with Bi

50
Model Selection

• LOD model selection based on the performance
  estimation

51
Simple Example

• Virtual Town with Traffic

52
LOD 0
53
LOD 1
54
LOD 2
55
Simulation EnvironmentGeneral Connection
Module(GCM)

• API Set for connection between ASADAL/PROTO-genera
  ted Java Code and Visualization Program
• Server Module in Java
• Client Module in Java, Win32 Cand IRIX C
• Network transparent
• Platform and Programming Language independent

ASADAL- Generated Code
GCM Server
GCM Client
Visualization Module
network
Java 3D, IRIS Performer, OpenInventor,
WorldToolKit...
Java, C/C
Desktop PC, SGI Workstation
56
Simulation EnvironmentVisualization Program
57
Performance Estimation
58
Software Reuse and FORM
59
Problems with Current SE

• Products are built for specific applications
• Maintenance difficulty
• Reuse difficulty
• Brittle software
• Low productivity
• Low level reuse of developed systems and
  development knowledge
• Systems are not built for reuse
• Development and application knowledge are not
  codified or documented for reuse (Reuse depends
  on people)

60
Approaches to Software Reuse

• Domain Engineering
• Design Patterns
• Software Architecture
• Component-Based Software Engineering

61
Domain Engineering

• Model-Based Approach (SEI framework)

62
What is domain analysis?

• Domain analysis is "the process of identifying,
  collecting, organizing, and representing the
  relevant information in a domain, based upon the
  study of existing systems and their development
  histories, knowledge captured from domain
  experts, underlying theory, and emerging
  technology within a domain CMU/SEI-90-TR-21.

63
Why domain analysis?

• Domain analysis makes a necessary contribution to
  software reuse a focus on understanding the
  common (or different) capabilities of software
  within a domain and on ways to evaluate solutions
  (domain artifacts).

64
A New Model-based Method

• FORM Feature-Oriented Reuse Method with Domain
  Specific Reference Architectures
• A model-based method
• Focuses on architecture and component reuse
• Extended from the CMU SEIs FODA method

65
Method Concepts
Artifact Space
Feature Space
Capabilities
Subsystem model
Mapping
Operating Environment
Process model
Module model
Domain Technologies
Implementation Techniques
Reusable components
Composition rules, issue and decisions
Architecture and componentselection and
instantiation
Feature selection
Application Development
Application N
...
Application 2
Application 1
66
Feature Modeling
Feature model
of applications from the end-users
perspective. in which applications are used and
operated.(H/W, S/W platform,O/S, Interfaces with
different types of devices) that are commonly
used in a domain (e.g.. navigation methods in
the avionics domain). designers decision on
algorithms and data structures.
Capabilities
Operating Environments
Domain Technologies
Implementation Techniques
67
Feature Model
Capabilities
Operating Environment
User Group
Domain Technologies
System Analyst (Architect) Group
Feature Model
Developer Group
68
Feature Analysis
Abstraction
Feature Analysis
Validation
Domain Products
Domain Language
Feature Model
Identification
Organization
Classification
Abstracting
eliciting
Refining and resolving conflicts
categorizing
characterizing
constraining
planing
describing
connecting
69
Example(EBBS domain)

• 1?? - Identification

??? ???, ???? ?? ? ??? ??
??? ??? ???? ???? ???, ???? ???? ?? ??
?? ???, ?? ??? ?? ??
Feature Pool
?? ???(M), ?? ???(O), ?? ???(O) ??(M), ??(O),
???(O) ????(O), ???(O), ???(M) ?? ?? ????(O) ? ??
?? ??(A), ?? ?? ?? ??(A) ??? ?? ???(A), ?? ??? ??
???(A) ?? ???(A), ?? ??? ???(A) etc...
70
Example(EBBS domain)

• 2?? - Classification

Feature Tree
?? ???, ??, etc...
CA
Categorize Features
OE
?? ???, ?? ??? ???, etc...
DT
? ?? ????, etc...
IT
B-tree ?? ????, etc...
71
Example(EBBS domain)

• 3?? - Organization
• Grouping and Connecting
• ?? ?????? Gen/Spec, Composed of ??? ???? ??? -
  ?????, ???? ?? - ???? ?? ?? ??? ?? ??
• ? ??? ?? ??? Implemented by
• OE ???? ?? ???? ???? ??
• Composition rule
• ? ???? ?? ??? ??, Require, Mutex ? ??
• (?) ??? ?? ??? require ?? ??, ??? ???
• ?? ??? require ?? ?? ????
• ??? ?? ??? mutex ?? ??? ??? ??

72
Legend
?????
CA
???
Composed of
...
?? ??
??
Gen / Spec
...
??? ???
?? ???
Implemented by
...
???
?? ???
Mandantory
?? ??? ???
?? ??? ???
?? ??? ???
Optional
...
Alternative
???
? ?? ??
OE
???? ???
????? ???
...
?????
??????
?? ????
?? ??? ???
DT
?? ?? ??
?? ?? ??
?? ?? ??
...
???
???
? ?? ?? ??
?? ?? ?? ??
????? ?? ??
????? ?? ??
IT
?? ?? ????
??? ?? ??
...
Kermit
Super kermit
zmodem
Polling
Process Signal
Network Protocol
73
FORM Architecture Hierarchy
74
Domain Architecture Model EBBS
75
Mapping Feature Model to Reference Architecture
Non-functional Aspects
(Grouping of Components, Selection of Connectors)
Feature Model
Functional Aspects
Reference Architecture
(Composition of Components)
Decision Space
Artifact Space
76
Mapping Feature Model to Reference Architecture
77
Feature Selection for Hitel-POP
78
Feature Selection for Lion
79
Selection and Adaptation of an Architecture for
Hitel-POP
80
Selection and Adaptation ofan Architecture for
Lion
81
Selection and Adaptation of Processes for
Hitel-POP
82
Selection and Adaptation of Processes for Lion
83
Module ModelBoard with Text Display
Board Process
Board Control
Board
Read
Post
Capability
Board List Manager
Domain Technology
Multimedia Display
Text-Orieted Display
Domain Technology
Implementation Technique
Display Interface
Data Interface
ANSI
VT-Series
Dedicated Emulator
ANSI Display
VT-Series Display
Module Model Board process with ANSI and
VT display support
Feature Model for a system with ANSI and VT
display support
Legend
Skeleton Module/Object
Name
Name
Module/Object
uses/depends on
interface
interface
Name
inherits
Name
interface
interface
84
Module ModelBoard with Multimedia Display
Board Process
Board
Read
Post
Capability
Domain Technology
Multimedia Display
Text-Orieted Display
Domain Technology
Implementation Technique
Data Interface
Web Brower
VTX
Dedicated Emulator
Web Service
Module Model Board process with Web display
support
Feature Model for a system with Web display
support
Legend
Skeleton Module/Object
Name
Name
uses/depends on
Module/Object
interface
interface
inherits
Name
Name
interface
interface
85
Conclusion

• Software Engineering of Virtual Reality
  Applications
• VR Object Form Function Behavior
• Incremental Hierarchical Development
• Verification Validation in Analysis and Design
  Stages Using Specification Simulation
• LOD Engineering top-down approach in LOD model
  design
• FORM for VR reuse method for features of VR
  applications