executable visual software modeling – the zoom approach
TRANSCRIPT
Executable Visual Software Modeling – The ZOOM Approach
Xiaoping Jia DePaul University
243 S Wabash Ave Chicago, IL, USA
Adam Steele DePaul University
243 S Wabash Ave Chicago, IL, 60616
Lizhang Qin DePaul University
243 S Wabash AveChicago, IL, [email protected]
Jordan Liu DePaul University
243 S Wabash Ave Chicago, IL, 60616
Chris Jones DePaul University
243 S Wabash Ave Chicago, IL, 60616
ABSTRACT In this paper, we introduce a new executable visual software modeling approach called ZOOM (Z-Based Object Oriented Modeling). ZOOM extends a subset of UML-2 notations by providing formal semantics, UI modeling notations and a formal integration mechanism. ZOOM allows visual software modeling in both graphical and textual views for its structural, behavioral and UI models. Through a pre-defined event model, ZOOM integrates these models, and provides the runtime execution semantics for both code generation and software animation.
Keywords Visual Modeling, UML, Model Integration, Model Animation
1. Introduction Visualization is playing a more and more significant role in software engineering. The Unified Modeling Language 2 (UML-2) [13] is one widely accepted notation in this area. UML-2 is a family of graphical notations, backed by a single meta-model, that help in specifying and designing software systems, particularly software systems built using the object-oriented style. Visual software languages have several advantages over their non-visual counterparts. First, visual software languages provide an easy way for people to communicate. Software designers draw sketches to represent different aspects of a system, and those graphical diagrams help other people understand the design. Second, by combining sketches the visual design for a software system can be treated as a blueprint for implementation. This technique emphasizes the completeness of the visual design. One recent trend is to use UML-2 as a programming language. This especially makes sense when considering Model-Driven Development (MDD). MDD [1, 2] is a methodology where all vital parts and aspects of a system under consideration are described using formal models. Instead of requiring developers to detail a system’s implementation using a programming language, MDD lets them use models to describe the system’s functionality and overall architecture. Visualization of the software model’s design is considered an important component in MDD. ZOOM (Z-based Object-Oriented Modeling) is a formal foundation we propose to support MDD. As with UML-2, ZOOM provides both the graphical and textual representations for all the model constructs. Unlike UML-2, which separates a system into several loosely related views, ZOOM provides a mechanism to merge those views together along with their formal semantics. This approach helps overcome some of the problems with UML-2,
specifically, problems of intra- and inter-model consistency. While UML-2 provides many different graphical views of a software system, it does not inherently enforce the consistency between these views. Such tasks are left to the modeler or the modeling software. In contrast, a ZOOM model has three integrated parts: structural models, behavior models and user interface (UI) models. Ultimately, an event model, processed through an event-driven framework, integrates these parts. ZOOM supports visualization during the software design process by two means. First, ZOOM provides a set of graphical model notations to specify the software’s functionality as well as the user interface. Second, ZOOM integrates the execution semantics with the models. This means the software models designed by ZOOM are executable, and modelers are able to get a visual validation and verification of the design by animating the models. Our research on ZOOM involves many components, such as new visual modeling notations, knowledge-based model compilation and event based model integration. In this paper, we present the visual model notations with the integration mechanism and present how this approach shows the benefits of visualization in software engineering.
2. ZOOM Visual Modeling Notations 2.1 Overview Model-driven development (MDD) is the notion that we can construct a model that can then be transformed into a real system. MDD moves the development focus from third generation programming language code to models, specifically the visual models in some modeling notations, such as UML-2. While UML-2 is widely used as a visual modeling language to support MDD, it has several weaknesses. UML-2 is not specifically purposed for MDD, so the models in UML-2 are informative without definitive views. Also, while UML-2 provides multiple visual views to present similar aspects in a software design, it lacks an inherent mechanism to enforce the consistency between these views. Similarly, UML-2 lacks the user interface or system interface design notations. To overcome the obstacles associated with the existing modeling notations, we propose to enhance the existing UML-2 models and meta-model by including support for formal syntax and semantics. This new formal notation is called ZOOM. ZOOM stands for Z-based Object-Oriented Modeling. It is based on the formal specification notation Z[3, 4, 5, 6], which is
Functional Requirements
Structural Model
Behavioral ModelDerive
Derive
Derive
ZOOM-M
ZOOM-FSM
ZOOM-UIDL
UI Model Device Profile
User Preference
Web Phone
Event-Driven Framework
Knowledge-based Model Compilation
ToolsRules
TemplatesModel
TransformationAnd
Code Generation
UI Generation PDA
Desktop
Figure 1. ZOOM Architecture
in turn based upon set theory and mathematical logic. Although widely used to specify software systems, one of Z’s deficiencies is that its specification is limited to mathematical logic and does not provide useful mechanisms to support OO modeling such as classes or inheritance. ZOOM extends Z to support these object-oriented concepts. Another deficiency of Z (and the other Z-Based OO extensions) is the lack of visual notations for its constructs and absence of notations to specify the user interface. ZOOM provides visual representations of models that are consistent with UML-2, and extends those notations to support UI and formal action design. Figure 1 shows the overall architecture of the ZOOM models for a software system. The functional requirements derive the structural and behavioral models and are the only requirements for a modeler to consider. User interface design is derived not only from the functional but also user interface requirements. Those UI requirements are normally incorporated in the device profiles. ZOOM provides a pre-defined event model, which is processed by an event-driven framework, to bind the structural, behavioral, and UI models together. The integrated ZOOM model will be processed by the Knowledge-based Model Compilation Tools resulting in different implementations of the software system based on the specific platform and / or knowledge base. For the software modeling notations, we arbitrarily partition the software design into three components: structural models, behavioral models and UI models. The separation of a system into these three parts is an application of the well-known paradigm in software engineering of “Separation of Concerns”, which formally separates the system based on special purpose concerns [7]. This separation allows each aspect of the system to be specified separately, making each aspect easier to write, understand, and change with less impact on the other aspects. For example, under this separation, modelers can modify the user interface based on profiles and user preferences without changing the structural or behavioral models. The other advantage of this separation is that we use different formal specification languages to describe different aspects of the system. Using a specific language, which is developed and aimed at a specific need, makes the modeling process more accurate and more formal. Each ZOOM model has dual representations including a textual specification and a visual view. The visual representations are consistent with common UML-2 diagrams, such as class, use case and state machine diagrams, but also include formal semantics and
extensions. This enables the use of popular tools to design and maintain ZOOM models. Modelers will appreciate the ability to use available tools to construct their models and to then add formal specifications to those models. Unlike the models in UML-2, the ZOOM models are executable with its formal execution semantics. All three components in ZOOM can be independently animated, and the whole software system can be visually animated with the event-driven framework.
2.2 Structural Models The structural model defines the functional part of the system using object-oriented concepts. These models provide not only the class relations and hierarchies, but also a precise specification of the functionality of each entity. Structural models are specified by using ZOOM-M language. Graphically, we make the visual modeling notations consistent with UML-2 class diagram. Textually, we design ZOOM-M syntax to be consistent with many Java language constructs. The main characteristics of ZOOM-M include formalism, the use of object-oriented constructs, and side-effect free operations. ZOOM-M is strongly typed with a semantically rich type system that supports inheritance and generic types [9]. ZOOM-M includes a pre-defined library that contains a collection of pre-defined structural models, including Set, List, OrderedSet, Bag, Relation, Map, Pair, Tuple, etc. Through this library and the quantified / iterator expression grammar, ZOOM-M is able to specify everything that Z can specify. Each ZOOM structural model is called “struct”. Structs are defined with formal specifications including class invariants and operation pre- and post-conditions. These constraints are a key element of Betrand Meyer’s principle of design by contract[10, 11], which provides elements of the ZOOM foundation. The use of such constraints can improve the quality of software documentation as well as its precision[12].
+userID+userType+password+information+friends
User
+contactsFriendList
+userID+firstName+lastName+email+chatLog
Contact
+itemsLog
+firstName+lastName+street+city+state+zip+phone+email
PersonalInformation
+systemName+users
Messenger
1*
1
1
1
1
1
* 1
1
+message+date+time+fromUser+toUser
LogItem
1*
(a) Graphical View of A Structural Model
(b) Graphical View of A Behavioral Model
(c) Graphical View of A UI Model
Login
UserID
Password
OK Cancel
Status:
Current User
Add Contact
Chat
Change Information
Buddies
/ trig
gerE
vent
(“evS
ucce
ss”)
, log
inD
ialo
g.hi
de(),
mai
nDia
log’
.use
rID =
= lo
ginD
ialo
g.us
erID
,m
ainD
ialo
g.bu
ddie
s.se
tVal
ues
( mes
seng
er.lo
adB
uddi
es( l
ogin
Dia
log.
user
ID) )
,m
ainD
ialo
g.sh
ow()
Idle
LoginSuccess
LoginFail
UIC
ance
l
UIO
k [!
mes
seng
er.u
sers
.exi
sts(
u @
u.us
erID
==
logi
nDia
log.
user
ID&
u.pa
sswo
rd =
= lo
ginD
ialo
g.pa
ssw
ord)
]
/ log
inDi
alog
.pas
swor
d.em
pty(
),lo
ginD
ialo
g.st
atus
.set
Text
(“Log
in F
ail!
Re-
Logi
n”)
/ log
inD
ialo
g.st
atus
.set
Text
( “En
ter t
he u
ser i
nfo.
”),lo
ginD
ialo
g.sh
ow()
UIO
k[m
esse
nger
.use
rs.e
xist
s( u
@u.
user
ID =
= lo
ginD
ialo
g.us
erID
& u.
pass
wor
d ==
lo
ginD
ialo
g.pa
ssw
ord)
]
LoginCancel
/ tr
igge
rEve
nt("e
vLog
inFa
il");
lo
ginD
ialo
g.hi
de();
Figure 2. A ZOOM Model Example
Figure 2 shows the graphical view of an Instant-Messenger (IM) system designed using ZOOM. Although the example has been simplified to conserve space, it illustrates most of ZOOM’s software modeling capabilities.. In this IM example, User, FriendList, Contact, Log, PersonalInformation and Messenger are the basic entities in the system. As with typical object-oriented design approaches, these entities should be specified as autonomous structs with proper attributes and operations. Part (a) in Figure 2 shows the graphical view of a simplified structural model for the above scenario.
2.3 Behavioral Models The behavioral model is the central communication mechanism
that links the structural models with the UI models. It uses an extended and formalized state machine diagram to specify the dynamic aspects of a system.
In UML-2, there are five kinds of diagrams used to specify the different behavioral characteristics of systems. Among these, State Machine diagrams and Activity diagrams are widely used. Although these two views can be used to illustrate behaviors, they have their own weakness when considering a fully automatic MDD approach. A state machine diagram represents the lifecycle of an object, therefore it is good for specifying the control object, but it lacks the ability to show the collaboration of multiple objects. An activity diagram defines the behavioral logic of one activity based on data
flow, but more closely resembles a low-level programming constructs rather than a high-level abstraction of the design.
We introduce ZOOM-FSM as the behavioral modeling language to provide a suitable specification notation in support of high-level behavioral design. Graphically, the representation of the behavioral model is an extension of the UML-2 state machine and activity diagrams. In behavioral models, states and transitions build the main framework for system behaviors, while actions are defined by either ZOOM-M expressions or extended activity diagrams. This approach makes it easier for practitioners to understand and design the behavioral models.
In the behavioral model, when the activity is specified using ZOOM-M expressions, its action and its corresponding result are specified by pre- and post-conditions in a way that is similar to that used in the structural models. ZOOM-FSM provides the following major extensions to UML-2.
ZOOM-FSM introduces variable declarations in state diagrams. It also allows state diagrams to have multiple object attributes.
ZOOM-FSM introduces variable declarations in a state declaration.
For a state machine declaration, ZOOM-FSM introduces optional “extends” semantics. For each type of state
machine, it can “extends” a struct type defined in structural models. When a state machine S “extends” type T, a new state machine instance in S will start working if a new structural instances of T is instantiated, also a pre-defined “this” attribute is associated with the state machine instance.
Each action in behavioral model can be defined using pre / post-conditions, ZOOM-M / ZOOM-E or the defined activity diagram.
ZOOM-FSM improves orthogonal states, allowing dynamical orthogonal branches attached to an orthogonal state.
ZOOM-FSM provides a “post” action, which is used to fire new event to behavioral models, and introduces a way to explicitly specify the target state machine when needed.
ZOOM-FSM introduces the parameter passing from state action to activity diagram, and the optional variable naming mechanism in activity diagram.
ZOOM-FSM introduces an event mapping mechanism. This event mapping can map the selection or combination of a set of events to a single signal event.
These improvements combined with ZOOM-M, defines a formal and powerful behavioral modeling notations. ZOOM-FSM overcomes the deficiencies of UML-2. For the IM example, the behavioral model should include several finite state machines for different user behaviors. For instance, the main FSM will stay in the Idle state after login, waiting for the user’s command, and change states to specific FSMs based on the user’s input. Some essential FSMs might be Main, Login, AddContact, Chatting and ChangeInformation. Part (b) in Figure 2 shows part of a simplified behavioral model for the login process.
2.4 User-Interface Models Unlike UML-2 and OMG’s MDA notations, ZOOM separates UI models from other aspects. This comes from the intrinsic characteristics of the UI aspect being separated from the structural and behavioral aspects. This separation is useful even when we consider external systems. In ZOOM, we consider all external systems as a special type of user. Those external systems, for example, a database system, communicate with the designed software through the same mechanism as the human users do. The UI typically has a tight coupling to a specific platform while other aspects are typically platform-independent [15]. ZOOM uses a specific visual UI modeling notation to achieve this separation of concerns rather than mixing the UI design as part of programming. One advantage of this separation is that it is easy to change a UI view by only changing the UI models, thus leaving other aspects unchanged. This is especially important while developing multi-platform software systems. Another advantage is that it is convenient for a modeler to model the software system from the bottom-up. While a UI model is typically composed of several nested sub-UI models, each of them can find the structural and behavior counterparts as a subset of the whole structural and behavioral models. A second advantage of this separation of concerns is that we overcome the difficulties of specifying the UI together with the
structural model; In its present form UML-2 fails to enforce this separation of concerns, trusting instead in the capabilities of the modeler or the modeling tool.
ZOOM defines UI models in three different views: the physical view, logical view, and event view.
• The physical view describes the specific layout of the UI widgets with their visual attributes. This view is platform dependent. The specific profile of the platform contains both the hardware and software constrains. Model compilation tools or animation tools will generate the visual appearance based on the physical specification of UI models and the platform profile.
• The logical view defines the logical data group relationship that is independent from the physical layout. The logical data groups are specified using the structural models. This UI logical definition establishes one link between the UI models to structural models. Logical definition separates the physical layout from the internal data structures
• The event view declares the events that can be generated or consumed by the UI models. Those events will be the intrinsic power to drive the application a runtime.
When designing the visual UI, ZOOM-UIDL is used. ZOOM-UIDL provides a visual representation of the UI model and is easy for designers to learn.
We introduce the ZOOM-UIDL (User Interface Description Language) visual language to specify UI models in a formal way. ZOOM-UIDL contains two aspects: the abstract UI modeling (AUI) for the logical view and the concrete UI modeling (CUI) for the physical view. Syntactically, ZOOM-UIDL is a hierarchical description framework containing a set of predefined AUI schemas. Designers can use these schemas to construct abstract UI models. CUI models are tied to a specific run-time environment, and described using a platform specific description language. We only discuss AUI modeling in this paper. The goal of AUI is to use a simple and minimal set of UI schemas to represent the majority of concrete user interface functionalities. Some AUI schemas work as a proxy between the software system and the real user interface. They store the most critical information and indicate the status of the UI rather than the layout information. ZOOM-UIDL uses XML as its textual syntax. Like XML, user interface models are often represented using a tree structure. Additionally XML makes it easy to exchange tree-style data and is easy to understand. Each AUI schema has a corresponding structural model, which is pre-defined in ZOOM library.
Figure 3 shows a simplified version of AUI schemas in their structural views. There are two important Component types: fixtures and inputs A fixture is the super type of all the UI widgets, which do not have a input capability. An input is the super type of all the UI widgets which can pass UI events to the system. The AUI modeling process is to design XML structures by utilizing AUI schemas, which can be used in both composition and inheritance.
-name-lang
UI
+show()+hide()
-id-owner-visible-enabled-present-feedback-attributes
Component
-compnents-exgroups
Group
-valueFixture
Input
-valueButton
-selectedBiState
-groupExclusiveBiState-value
-type
Field-min-max-position
Analog<T>
-options-mode
OptionList
-value-owner-selected
OptionListItem
-root-mode
Tree
-children-value-selected-expanded-parent
TreeNode
1
*
11
1
*1*
Figure 3. AUI Schemas
UI models are important components when modeling a software system using ZOOM. In the IM example, all the visible parts belong to UI models. They may include Login, Main, AddContact, Chatting, and ChangePersonalInformation dialogs. Part (c) in Figure 2 shows part of a simplified UI model in its graphical view, including the Login and Main dialogs. While the structural and behavioral models satisfy the functional requirement for an Instant-Messenger system, such UI models design the logical view for user interface. Furthermore the same model can be implemented in different platforms, such as a desktop computer, a mobile device or even an embedded system.
3. Model Integration and Execution 3.1 Overview
The pre-defined event model, which is processed by an event-driven framework, coordinates the activities between the structural, behavioral and UI models. Events are used in the behavioral model to specify the dynamic nature of the system. Upon receiving specific types of events, the behavioral model’s finite state machine (FSM) will perform pre-defined operations by triggering changes in the various models. The event-driven framework satisfies the inter-view consistency requirements, and works as a mechanism to bind the structural models, behavioral models and UI models together.
In the rest of this section, we define the event-driven framework in detail with an example of the Login scenario of the Instant-Messenger we described above, and explain how the event-driven framework works as a run-time mechanism to support the execution of integrated ZOOM models. In this example, we use the structural, behavioral, and UI models defined in Section 2. The graphical views of these models are shown in Figure 2.
The example scenario is shown in Figure 4. First, the initial Login dialog appears, waiting for the user to login as shown in Figure 4(a). When the user provides valid credentials, the Main dialog is shown as Figure 4(c), with the current user id and buddy list set. If the user fails to provide valid credentials, the system will ask the user to re-login as shown in Figure 4(b) with the preservation of the last entered user id. If the login process succeeds, an evSuccess event is generated. If the login process is cancelled by the user, an evLoginFail event is generated.
3.2 The Components of the Framework Figure 5 shows the structure of the event-driven framework in
ZOOM. The shaded parts indicate the run-time components of the framework while the un-shaded elements indicate the design-time components. Both of these components are discussed in greater detail below.
At design time, the structural models include both AUI models and Requirement Structural Models. The AUI models are the reflection parts for AUI Schemas, and are provided by pre-defined ZOOM library. For example, the Button struct is the reflection of the Button schema. Modelers cannot modify and actually do not need to modify those. The Requirement Structural Model is derived from the functional requirement and is designed by modelers.
The UI models are specified by ZOOM-UIDL. Each UI model not only defines the physical layout for the widgets, but also represents a logical view in a tree form and is used at run-time to instantiate UI model instances. Each node of the logic tree is an instance of a UIDL schema, which in turn defines that at run-time each UI model instance contains a tree structure of AUI instances.
Login
WilliamUserID
****************Password
OK Cancel
Status: Enter the user info.
Login
WilliamUserID
Password
OK Cancel
Status: Login Fail! Re-Login
Current User William
Add Contact
Chat
Change Information
Buddies Jack (Away) Mark (Online) Mike (Online) Penny (Away) Steve (Busy) Weny (Out to lunch)
(a) Initial Login Dialog (b) Re-Login Dialog (c) Main Dialog
LoginFail
LoginSuccess
Status label: one instance of TextBox schema in ZOOM -UIDLPhysical view changes during the transition from LoginFail to Idle
OK and Cancel button : instances of Button schema in ZOOM-UIDL
Raising the events when user clicks them.
Figure 4. The Login Scenario for Instant-Messenger Example
ZOOM-UIDL UI Model Behavioral Model
AUI Schema
Structural Model
AUI Model Requirement Structural Model (RSM)
UI Instance FSM Instance
Structural Model Instance
AUI Instance RSM Instance
event
eventcode
generation
instance of instance of
instance of
ZOOM-FSM
ZOOM-M
Run-time System
derives
Event passingOperation invocationInstance ofDefines grammar
Code generation
operation invocation
automatic update
SD
R1
R2
R3
MD
Figure 5. The Integration for ZOOM Models
At run-time, structural model instances are instantiated from the structural models, which contain instances of both AUI Models and Requirement Structural Models. Similarly, behavioral model instances and UI instances are instantiated from behavioral models and UI models respectively.
Each UI instance is the logical representation of a physical view in a tree structure. By default, each tree node has a corresponding AUI instance. Each AUI instance reflects the status of corresponding physical component.
When the user triggers UI events on UI instances, these events are transmitted to behavioral model instances, which are a set of FSMs.
The FSMs perform state transitions based on these events. Simultaneously, FSMs may trigger more events and send them back to behavioral model instances.
Behavioral model instances interact with structural model instances. Since user input is reflected by AUI instances, behavioral model instances can get those inputs by accessing those instances. Conversely, since behavioral model instances can manipulate those Proxies, the state changes will be reflected by the UI physical views automatically.
3.3 The Design Time Code Generation Before the specified model can be executed, two static steps for
code generation are conducted at the design time. These two steps are specified as SD and MD in the Figure 5.
SD stands for the code generation for the schema definition and MD stands for the code generation for the model definition.
Step SD: The code generation for UI schemas
As described above, each AUI schema has a corresponding pre-defined struct in the structural models. This process is completed when we define the event-driven framework, and is only conducted once. These generated structural models cannot be modified by the modelers, and unless the AUI schemas change, they remain fixed. We use the Button schema as an example. Figure 6(a) shows a simplified specification for the Button schema, and Figure 6(b) shows the corresponding generated Button struct specifications. < ... > <xs:element name="Button">
<xs:complexType> <xs:attribute name="whenclick"
type="xs:string"/> <xs:attribute name="text" type="xs:string"
use="optional"/> <xs:attribute name="selected"
type="xs:boolean" use="optional"/>
<xs:attributeGroup ref="COMPONENT-ATTRIBUTES"/>
</xs:complexType> </xs:element>
< ... >
(a) A simplified version of Button schema in UIDL public struct Button extends UIComponent { public String whenclick; public String text; public boolean selected; }
(b) Button struct
Figure 6. Button schema and Button struct
Step MD: The code generation for UI models Unlike Step SD, which is only executed once, Step MD is
executed multiple times when a UI model is put into the event-driven framework. For each UI scenario defined by modelers as the UI model, an implicit AUI struct is automatically derived in the structural models, and an instance will be automatically instantiated during the run-time which can be used in all FSMs without declaration.
For example, for the LoginDialog model as specified in Figure 2, a corresponding struct type TLoginDialog is implicitly generated as part of the structural models. Figure 7 shows a simplified version of TLoginDialog struct based on the model defined in Figure 2. Since the LoginDialog UI model includes two buttons, each of which is a reference to the Button schema in AUI, the automatically generated TLoginDialog struct has two variables of type Button as shown above. public struct TLoginDialog {
public Fixture status; public Field userID; public Field password public Button okButton; public Button cancelButton; }
Figure 7. AUI struct of LoginDialog
A system variable called loginDialog with type TLoginDialog will be instantiated automatically as follows:
public TLoginDialog loginDialog;
This loginDialog variable is a global variable and can be used in all FSMs.
3.4 Execution Model The execution model for the Event-Driven Framework includes
three steps. These steps are shown as the numbered links starting with ‘R’ in Figure 5, and are only applied during execution time. They form an execution cycle and drive the system. More detailed discussions for those steps are described below. In the rest of this section we focus on the login fail scenario as the example.
Step R1: Interaction from the UI instances to the FSM instances
Step R1 carries out the interaction from the UI instances to the behavioral model instances. This interaction is conducted using events. There are several different levels of events defined in the system. Hardware events have the lowest level and have a tight coupling to the specific run-time platform. When the user interacts with the user interface, hardware events are generated. These hardware events are turned into pre-defined UI events based on the UI component type. This process is done by a platform specific virtual machine. The type of UI events that can be triggered for each UI construct is defined as part of the UIDL schemas. Ultimately, UI events are turned into FSM events and feed into the behavioral model instances. The conversion from UI events to FSM events is defined as part of UI models. For example, the initial Login dialog is shown to the user as in Figure 5(a). After the user enters the login information and clicks the OK button using the mouse, a mouse-click event is triggered. This process is handled by the operating system. The mouse-click event is a low-level event, and is turned into the ButtonClick event, which is defined as one UI event for the Button schema in ZOOM-UIDL. The Button schema defines a set of supporting events such as ButtonClick. Finally, this ButtonClick UI event will be turned into UIOk event by the following definition and sent to the FSMs.
Step R2: Interaction starting from the behavioral model instances
Step R2 carries out the interactions starting from the behavioral model instances. There are two destinations: the behavioral model instances themselves and the structural model instances.
In the behavioral models, the modeler could specify the actions that raise events with our ZOOM-FSM language. For example, the following code in the behavioral models raises a new FSM event called evLoginFail:
ActionDef …triggerEvent ("evLoginFail "); ...
Such action specifications can appear in the state action or the
transition action in the behavioral models. The behavioral model instances also interact with the structural
model instances. This interaction is established in two steps. First, at the design time, modelers can declare state attributes using the struct type defined in the structural models. These attributes are called state variables, and will be instantiated at run-time. For example
State Machine: InstanceMessenger
State / Transition / Action Definition…
FSM Fields: …
Messenger messenger; …
declares an instance called messenger for the struct type Messenger. Second, when the transition is triggered during the execution process, an FSM can alter the states of these attributes by operation invocations that are specified as transition or state actions. This mechanism ensures the separation of structural model instance changes from the FSM, and makes the status of an FSM stable.
As an example, we continue the execution process illustrated in Step R1. When then UIOk event generated in Step R1 arrives at the behavioral model instances with current state Idle, the FSM will try the following transition.
Idle LoginFail[! messenger .users.exists(
u @ u.userID == loginDialog .userID & u.password == loginDialog .password )]
This transition specification declares a transition guard within the
square brackets when UIOk event is received. The guard utilizes functions provides by Messenger, User and LoginDialog to verify whether the user entered valid user information or not. If the user entered incorrect login information, the active state will move from Idle to LoginFail. According to the behavioral model in Figure 5, the FSM will perform the transition from LoginFail to Idle automatically with the companion action as follows.
IdleLoginFailloginDialog .password .empty();loginDialog .status .setText (
"Login Fail ! Re-Login")
These actions do two jobs by operation invocations. The first is to
clear the password textbox in loginDialog, and the second is to set new status label information.
Step R3: Interaction from the UI Proxies instances to UI physical views
Step 3 carries out the update process of UI physical view. Since we separate the UI models from the behavioral models, we need to design a mechanism to communicate from the behavioral models to UI models. As described in Step R2, the behavioral model instances can alter the status of structural model instances. When the operation applied to the AUI instances, the status changes automatically affect the corresponding physical views.
This process can be conducted in two ways, and ZOOM supports both of them. One approach is to implement platform specific
virtual machines. The virtual machine automatically synchronizes the memory with their physical views. The other approach is to use ruled-based code generation. When generating code through the model compilation process, the knowledge base combines the software models with the environmental requirements, and then uses matching rules to generate the VM free binary codes. The VM approach is easy to implement, and can generate the smaller codes than the second approach, so it is good for the first-step modeling phase. The rule-based approach is part of our knowledge-based model compilation research, and can generate more efficient execution codes. The rule-based approach also provides a better expansion capability, which will not be presented in this paper.
We continue the login fail example. As described in the last paragraph of Step R2, the password textbox and status label variables are altered. Those changes are automatically reflected in the physical view as shown in Figure 5(b). Similarly, if the login process succeeds, the action with the transition from LoginSuccess to Idle will make the UI physical view to Figure 5(c).
3.5 Benefits The event-driven framework integrates the three loosely coupled
aspects of the ZOOM model as a whole, and provides an executable model for the software execution. This approach defines a simple solution for complicated model integrations. Modelers can use ZOOM to visually specify the structural, behavioral and UI aspects separately in a formal way, and then put them into the event-driven framework. After specifying the event mappings from UI events to FSM events, a whole software system model is established.
The approach is adequate for both design needs and run-time execution needs. At the design time, it allows modelers to focus on modeling the specific aspects of a system without considering the coupling relationships between different parts. This makes the whole modeling process flexible and iterative, relieving modelers of the burden of considering other related aspects when they wish to focus on only one specific aspect. Our approach also provides an abstract framework for run-time execution. Within this run-time environment, events and behavioral model instances play important roles in execution. In addition, finite state machine concepts are adequate for many types of software systems including concurrent and distributed systems.
The event-driven framework approach is feasible, not only because it provides a design concept for putting three ZOOM components together, but because it defines an abstract virtual machine model for different platforms. In ZOOM, modelers define the UI and FSM events, which might be quite different from the physical events during run-time. The events in the event-driven framework are abstract concepts in the model, and might have different implementations on different run-time platforms.
Animator – Integration ModeAnimator – Integration Mode
Choose Application InstantMessenger Start Pause Stop Exit
Instances in scope
InstancesloginDialog
status: “Login Fail! Re-Login”userID: “William”password: “”
messengersystemName: “Instance Mesusers: [ ("William", "3ef8ab31a
mainDialoguserIDbuddiescharButtonaddButtonchangeButton
NotLogin
Login
Idle
LoginCancelled LoginFailed
LoginSuccess
LoggedIn ChangeInformationAddContact
Active State IdleButtonClick: chart buttonDialogClick : main dialogMouseDrag: buddies listbox
Event Generated
Event Received ListBoxUpdate: buddies list
Chating
Current User William
Add Contact
Chat
Change Information
Buddies Jack (Away) Mark (Online) Mike (Online) Penny (Away) Steve (Busy) Weny (Out to lunch)
(a) Main Screen of the Animation of ZOOM Application
(b) The Physical Layout of UI Animation
Animator – Struct ModeAnimator – Struct Mode
Choose Struct PersonalInformation
Restart Clear Log Exit
- Restart Animation for PersonalInformation- execute setFirstName name: Sam- execute setLastName name: Chen- execute addFriend name: Jordan- execute addFriden name: Frank
Available OperationsaddFriend
Animate
name: Frank
Complete Parameter
Status
lastName: ChenfirstName: Sam
email:
street:city:state:zip:phone:
friendList: { "Jordan", "Frank"
(c) Animation of ZOOM Structural Models
Event View
Logical View
Physical View
Figure 8. Visual Animation for ZOOM Models
During the code generation phase, the code generator uses the event-driven framework as the basis for code generation without concern for the specific target platform. When executing the generated code, a platform-dependent virtual machine is used. All virtual machines
are instances of the event model, making it easy to develop code generation tools for different platforms.
4. Prototypes and Animations ZOOM supports the visual animation for both partial models and
complete models. Unlike UML-2 or other visual modeling notations, the intrinsic formal characteristic of ZOOM provides an executable semantics for each aspect of the models. This makes the animation feasible.
We have completed significant work on designing the notations and implementing the tools to support modeling in ZOOM. In order to illustrate the feasibility and advantages of ZOOM approach, an experimental prototype was developed, which includes several components: basic language supporting tools, such as the parser, type checker etc; an interpreter, which provides the interpretation mechanism for the animator; a translation engine for the behavioral models and a set of rule-based tools for UI generation. The translation engine, which is for the preliminary code generation simulation, takes the behavioral models and action semantics as inputs, and then generates executable Java code. The translation engine also provides an underlying architecture for this executable code with built in support for persistence, generation of signals and events, transition and state priorities, threading and concurrency. The rule-based UI tool is developed with two separate rules for Java Swing and SWT frameworks. This UI tool takes the UI models as input, generates the executable java programs in Swing or SWT framework with different physical representations.
Meanwhile, we also developed a prototype of the model animator, which can virtually execute the user-defined models, especially the partial models. The animator includes a partial implementation for the VM approach discussed earlier. It shows the advantages of using the VM approach by helping designers validate their initial designs. The animator can animate the UI models, behavioral models or structural models separately, or the integrated models as a whole.
Figure 8 shows some screen shots of the animator when it is animating the IM models. In the integration mode, the animator shows all the information for the current system status. In Figure 8(a), the left-top area shows the event view of the system for the events generated or consumed by the UI model along with the specific widget; the left-bottom area shows the logical views of the UI models in the form the instances of AUI structs; Figure 8(b), shows the physical view of the system, and a modeler can perform the interaction with a specific input, for example by entering the information in text field or clicking a button. The active state machine is shown visually on the right part of Figure 8(a).
Figure 8(c) shows the standalone mode of the animator for the structural models. Since the structs in ZOOM models are modeled in a formal way by providing the pre- / post-conditions for each operation, the animator can show the execution result for the specified operation. This animation provides a powerful way for modelers to validate their design on basic functional objects.
When the animator works in FSM Mode, The instances associating with the active state are also shown. Modelers are able to choose to feed the events by hand or to have them be randomly generated by the system. The events here are the FSM events, which is in a much higher abstraction level than those events in UI models.
5. Related Work and Comparison In ZOOM modeling notations, each functional component in the
system has to be described using the structural modeling technology. Each dynamic aspect of the system has to be specified by using the behavioral models. Unlike UML-2, ZOOM uses a
unique modeling view for each aspect, which can help to maintain the consistency within the system. This separation of models makes modelers to enjoy the similar advantages as the Model-View-Controller (MVC) patterns in OO programming. But the ZOOM approach cannot be regarded as a variation of MVC pattern. There are several key differences.
ZOOM model notations provide the concrete modeling mechanisms at a system level, while MVC only defines the implementation framework for defining low level programming APIs. In MVC, each part in the framework is a class or an interface. When programmers implement the MVC pattern, they write the code which has the interface conforming to the MVC rules. In ZOOM, each part is a model that specifies one aspect of the target system. Designers only need to focus on the functional design for those models using ZOOM specification languages, they do not need to concern about defining the interface to communicate each other. The communication mechanism is a predefined model integration framework that is the main focus of this paper.
Another difference is that MVC uses method invocations or function calls for communication, while in the ZOOM approach, we use the events to achieve the same goal. Those events are defined at a more abstract level. They are extensible and also work as the gateway to interact with external systems.
ZOOM modeling notations are not another version of UML-2 with OCL. One critical difference between ZOOM and UML-2 is that ZOOM ensures that all of the views of the software system have strong and formal constraints that bind them together [8], which is similar to some MDD implementations using UML-2 + OCL, but in a more integrated way. This is a crucial element of our vision of formal models. Under ZOOM, each aspect of the model is precise and can be checked mathematically for consistency. To support this formalism, ZOOM currently only supports a small yet sufficient subset of the existing UML-2 diagrams.
Another distinguishing benefit of the ZOOM approach compared to UML2 + OCL approach is that by providing the framework, ZOOM not only supports the code generation phase in MDD well, but also provides the executable semantics to the modeling notations. Modelers can execute their design at an earlier stage and avoid many potential problems. Compared with Executable UML (xUML) [14], which is an MDA compliant methodology that aims to make a limited set of UML state chart models executable, the ZOOM behavioral model can specify more general and complex system interactions. ZOOM-FSM also provides greater formal specification capabilities than ASL used in xUML.
The third advantage over OCL is that ZOOM provides a formal foundation both in syntax and semantics. While the OMG does provide a formal syntax to UML and OCL, it lacks formal semantics. With this formal nature, the structural models in ZOOM make the MDD process more powerful and more convenient by providing a set of automatic tools, such as validation tools, verification tools, unit test generators and automatic code generators.
The ZOOM approach is better than the Z specification language in several aspects. ZOOM provides the modern Object-Oriented constructs and support MDD. This overcomes the deficiencies of Z that limit representation to the mathematical logic. Although there are some approaches to support Z OO extension, such as Object-Z, ZOOM defines a standard way to formally define the dynamic aspects and UI aspects of the software system. ZOOM structural
model has the same capability to do functional specification as Z or its OO extension. ZOOM behavioral models, UI models, under the event-driven framework, provide the executable semantics for the whole system, and support a later model compilation to generate codes, which are out of Z capability.
The ZOOM event-driven framework approach does not only provide an alternative way for UML-2 to support MDD, it also has several advantages. As mentioned in previous sections, ZOOM separates the model design into three separate parts, and use event-driven framework to make them consistent. ZOOM also supports better code generation by providing the formal semantics to its modeling languages.
The work reported in this paper is also closely related to research efforts on modeling languages and associated tools support. The following literature to one degree or another is related thematically but does not employ an event driven framework specifically. Nevertheless, some of these works do provide support for model driven development.
France [16] presented a translation of a UML class diagram to a Z specification. Dupuy [17] developed an Object-Z specification from an object model in OMT [18]. However, none of this work provides a formal basis for the languages used, and translation rules are described informally at the model-level.
Levendovszky [19] proposed an approach based on graphic transformations to transform UML design models to implementation. UMLAUT [23] is a generic UML transformation framework, which can be used for design pattern generation and aspect weaving among others. The framework is built upon the UML meta-model and allows the definition of new transformations, which can be stored in a transformation library
Kohler, et. al. [21] presented an approach for code generation from state charts. Their approach adapts the idea of a generic array-based state-table but uses object structures to represent the state-table at runtime. They use objects to represent states in a state chart and use attributes to hold the entry and exit actions.
Carlsen [22] presents an extension of an event model. A computable notation, the event language, based on this, it could be used to construct a complete user interface framework. The framework forms the runtime component of a User Interface Management System. The event language allows the modular construction of complex event systems.
6. Conclusion
We introduce a new executable visual modeling language ZOOM, which is a formal and object-oriented approach to support MDD. ZOOM separates software modeling into three models: the structural, behavioral and UI models. This separation of concerns allows each aspect of the system to be specified separately, and makes it possible for us to use an appropriate formal specification language to specify each of these unique aspects.
Modelers use the three loosely coupled models in ZOOM to model the software system. ZOOM provides a pre-defined event model, which is processed by an event-driven framework, to coordinate the activities between the structural, behavioral and UI models. The event-driven framework satisfies the consistency requirements between different views of the system, works as a
mechanism to bind those views together at design time, and provides the execution model for run-time execution.
In our current research status, a prototype for visual animation of ZOOM models was developed, which can animate the partial models or the integrated application.
References [1] Object Management Group (2001) Model Driven Architecture (MDA), 9 July 2001 draft, edited by J.Miller and J. Mukerji, available at http://doc.omg.org/ormsc/2001-07-01 [2] D.S. Frankel, Model Driven Architecture: Applying MDA to Enterprise Computing, OMG Press, 2003 [3] J. Woodcock, J. Davies, Using Z Specification, Refinement, and Proof, Prentice Hall Europe 1996 [4] J. B. Wordsworth Software Development with Z Addison-Wesley 1992 [5] J. M. Spivey, The Z Notation: A Reference Manual, 2nd Ed., 1992 [6] Edmund M. Clarke and Jeannette M. Wing, Formal methods: state of the art and future directions, ACM Computing Surveys, 28(4): 626-643, 1996 [7] C. Lopes, W. Hrsh, Separation of Concerns, technical report, Northeastern University, 1995 [8] William E.McUmber and Betty H. C. Cheng, A general framework for formalizing UML with formal languages, Proceedings of the 23rd International Conference on Software engineering, 433 – 442, 2000 [9] X. Jia, The ZOOM Notation - A Reference Manual, Technical Report, DePaul University, 2004 [10] Bertrand Meyer. Object-Oriented Software Construction, 2nd Ed. Prentice Hall PTR, Upper Saddle River, NJ, 1997. [11] Bertrand Meyer. Applying ‘design by contract’. 25(10):40–51, oct 1992. [12] Jos Warmer and Anneke Kleppe. The Object Constraint Language. Addison Wesley, Boston, MA, 1999. [13] Object Management Group, UML 2.0 Superstructure Specification [14] Mellor, Stephen and Balcer Marc, Executable UML: A foundation for model-driven architecture, Addison Wesley, Boston, MA, 2002 [15] Paulo Pinheiro da Silva and Norman W. Paton, User Interface Modeling in UMLi, IEEE SOFTWARE, 20[4]:62-69 2003 [16] R. B. France, J.-M., Bruel, M. M. Larrondo-Petrie, and M. Shroff. Exploring the Semantics of UML type structures with Z, Proc. 2nd IFIP conference, Formal Methods for Open Object-Based Distributed Systems(FMOODS’97), pp. 247-260, Chapman and Hall, 1997. [17] S. Dupuy, Y. Ledru, and M Chabre-Peccoud, Integrating OMT and Object-Z, Proceedings of BCS FACS/EROS ROOM Workshop, 1997. [18] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-oriented modeling and design, Prentice-Hall, 1991.
[19] Agrawal A. , Levendovszky T., Sprinkle J., Shi F., Karsai G., Generative Programming via Graph Transformations in the Model-Driven Architecture, OOPSLA, Workshop on Generative Techniques in the Context of Model Driven Architecture, Seattle, USA, 2002 [20] Ho, W.-M., Pennaneac’h, F., Plouzeau, N., UMLAUT: A Framework for Weaving UML-based Aspect-Oriented Designs, Proceedings of TOOLS 33, St. Malo, France, 2000, 324-334 [21] H.J. Kohler, U. Nickel, J. Niere, and A Zundorf, Integrating UML diagrams for production control systems, Pro. 22nd International Conf,. on Software Engineering(ICSE2000), Limerick, Ireland, 2000, 241-251 [22] N. V. Carlsen , N. J. Christensen , H. A. Tucker, An event language for building user interface frameworks, Proceedings of the 2nd annual ACM SIGGRAPH symposium on User interface software and technology, p.133-139, November 13-15, 1989, Williamsburg, Virginia, United States