ARCHITECTURAL FRAMEWORK FOR GENERIC MODELING AND DIAGRAMMING IN THE CLOUD

7/27/2019 ARCHITECTURAL FRAMEWORK FOR GENERIC MODELING AND DIAGRAMMING IN THE CLOUD

1/11

455

Architectural Framework for

Generic Modeling and Diagramming in the Cloud

Laszlo Juracz and Larry Howard

Institute for Software Integrated Systems, Vanderbilt University

Nashville, U.S.A.{laszlo.juracz, larry.howard}@vanderbilt.edu

ABSTRACT

KEYWORDS

modeling, diagramming, e-learning, cloud-

computing, web-applications, user-experience, collaborative, JavaScript.

1 INTRODUCTION

Diagrams have been used throughout

history to visualize ideas and depict

information. The earliest diagrammaticrepresentations were land-maps and

religious ideas, followed by graphical

abstractions of mathematical concepts.The number of diagram types rapidly

increased in the past century with the

evolution of computer software and userinterfaces (UI). It resulted in employing

diagrams extensively across multiple

disciplines [1].

Among these disciplines engineering

relies on diagrams the most heavily.Hundreds of standardized notations are

used from mechanical engineering tocomputer science to describe design

concepts and to communicate and

document technical specifications [2].The few dozen most common types are

node and connection-based, like

flowcharts, mind maps and electric

circuit diagrams. Others are lessconventional-looking, such as the Nassi-Scheinderman diagram (NSD) [3] used

in structured programming design or the

House of Quality (HoQ) [4] employed

2 RELATED FIELD

There is a well-developed market of free

and commercial software products for

International Journal of Digital Information and Wireless Communications (IJDIWC) 1(2): 455-465The Society of Digital Information and Wireless Communications, 2011(ISSN 2225-658X)

This paper is aimed at presenting a conceptof a flexible diagramming framework for

building engineering and educationalapplications. The framework was designedto serve as a platform for online services and

collaborative environments where userstypically work on remotely stored, shareddata through a browser-based user interface.The paper summarizes the commonrequirements towards such services,

overviews related approaches and givesinsights into some design challenges through

the analysis of two use-cases. The designproblem is examined from a user-centeredview: the key motivation of our research is

to find innovative, possibly device-independent solutions that enable seamless

user experiences. A generic frameworkbased on JavaScript and HTML5 on theclient-side, using novel, high-performance

JavaScript technologies on the server-side isproposed. This framework could be

employed for implementing a wide spectrumof software solutions from diagramming-related e-learning to cloud-based modelingenvironments.


2/11

456

authoring standard and commonly used

types of diagrams (flowcharts, UML

diagrams, mind-maps, wireframes etc.)and there are numerous tools supporting

model-based development technologies.Some of these offer solutions for custom

visualization by creating new componentlibraries or defining new skins for

diagram elements. The two most robust

diagram-creator applications for thedesktop are OmniGraffle [7] and

Microsoft Visio[8]. The visual

capabilities of these applications are

very impressive. Users can create newtemplates and stencils (visual libraries)

for authoring diagrams with custom

shapes and elements. Shapes can be alsointeractive, their appearance and the

layout of the diagram can be data-driven.

The Generic Modeling Environment(GME) [9] introduces the concept of

decorators for custom visualization.

Unfortunately all of these tools possess

the limitations of classical desktopapplications; they can import and export

several file formats and can be extended

through APIs but they do not provide

built-in features for collaborative work,cloud-based storage and version control.

The adaptation of their UI to different

tasks and use-cases is unfeasible.While it is hard to find any browser-

based modeling tools, there are a few

diagram editors implemented in Flashand HTML [10]. These applications are

simple and quick to learn. The advanced

ones have built in features for

collaboration. Since the authoreddiagrams are stored in the cloud space,

sharing them through a URL is easy and

comes natural. Their visual libraries arealso extensible. However, they do not

offer as sophisticated and flexible

solutions as the desktop applications

mentioned above. They are not designed

for integration into more complex

systems.

However the available tools andapproaches have built-in support for

collaboration, none of them allowdevelopers to work on separate instances

of diagrams and models in parallel.Versioning of models gained attention in

the recent years. Several research results

were published in this field [11].Although in this paper we do not discuss

and detail any server-side solution, our

framework is designed to support

optimistic locking by logging operationsand model changes [12][13].

We analyzed results of a research project

working on collaborative, web-baseddiagramming environments [14] for

learning. However some of the

requirements and goals Tolosa et al.identified are similar to those we

established for our project, they seem to

be addressing them on different fronts.

We are working in a lower-level solutionthat is suitable for not just diagramming,

but modeling as well.

Some of our work is based on results and

experiments with an earlier diagrammingapplication developed and published by

Roselli et al. in [15]

3 DESIGN CHALLENGES

The need of a generic diagrammingframework arose several times in the

past whenever we were conceptualizing

web-based authoring. The actual

functional requirements were gatheredfrom two distinct fields of application:

diagram-based e-learning and cloud-

based modeling services.

3.1 A HTML-based Diagramming

Tool for Education



3/11

457

The Graphical Representations to Assess

System Performance (GRASP) project

examines new and innovative ways forusing graphical assessments in

engineering education. This researchfocuses on, but is not limited to,

designing and implementing a set ofsoftware tools for web-based exercises

and carrying out experiments with them.

For simple construction-like GRASPexercises, there is a need for a browser-

based diagramming system, which

should be capable of handling an

extensible set of visual languages.The opening set of requirements toward

this new diagramming tool was based on

experiments with an earlier solutioncalled the Free Body Diagram Assistant

(FBDA) [15]. FBDA is an adaptive e-

learning application employed to teachfree body diagrams in biomedical

engineering classes. Although the new

system also could serve as a replacement

for the FBDA, it is anticipated to have amuch wider set of functionality and

usability.

The pedagogical strategy, system

architecture and the uses-cases of thenew design are very similar to those of

the predecessors (see in Fig. 1.).

Fig. 1.Authors create new problems through the

solution editor interface. Since the studentswork is diagnosed through comparing the student

diagram with an expert model, this step starts

with choosing the visual library and building the

expert diagram. When the expert diagram is

ready, the author imports it with the Course

Authoring Packaging Environment (CAPE) [16]

and deploys it to the experimental Learning

Management System (eLMS) [17] as a learning

module. The instructors can create problem

assignments and look up student records through

the instructor interface. Students work on the

solution in a browser-based student-editor; their

work is evaluated and adaptive feedback is

generated on the server-side.

Usability and User Experience. Mostof the differences and improvements of

the new system will emerge from a

HTML-JavaScript diagrammingcomponent, which is going to replace

both the old Microsoft Windows-

executable solution editor and the

browser-based student editor. These oldapplications were build in Adobe Flash.

The new editor interface is not just going

to provide a smoother user experience,but is desired to do it on a device- and

visual language-independent way: it

should work on desktop computers,hand-held devices and the same UI

should be suitable for different kind of

diagram-based assessments. The UI

should be intuitive and easy to learn andunderstand without guidance: it should

not cause interruptions for the user in

accomplishing the given task; affordanceand effectiveness are crucial factors [18].

Since the product needs to be optimized

to serve the users without changing their

behavior to accommodate the product,we based our development on user-

centered design (UCD) [19].

The design process started withanalyzing the old FBDA product based

on preliminary identified usability and

user experience goals. The outcome of

this analysis and the newly establishedrequirements yield a couple of different

visual concepts. Several low-fidelity

mockups were built during this phase ofthe development for testing and

evaluation (see Fig.2.).



4/11

458

Fig. 2. Diagram editor screen layouts with

different visual languages and modes: (a)

Diagram editor in author mode with and FBD

problem; (b)An electric circuit (EC) problem is

being composed; (c)Feedback is sent back to the

student during an EC solution exercise in

playback-mode. Note the exclamation marksmarking problematic elements; (d) Mockup

depicting the UI in a very similar state to (c)with

a different background color and an expanded

property panel for the currently selected resistor

component.

The requirement of providing a UI that is usable

on touch-screen devices ruled out a few

conventional UI elements, and called for

designing custom interaction patterns. For

example, tablet users do not get access to

keyboard buttons during editing but can use

gestures to trigger commands instead of shortcut

keys.

Extendibility and Configurability.Easy-extendibility has to be a primefeature of the new application: there

should be a descriptor language and a

framework defined for implementingnew visual libraries. This descriptor

language should be robust enough to

capture and model all of the common

engineering diagram types; furthermore

it should provide ways to specify howthe users can interact with diagram

instances of the given type in thedescribed e-learning environment.

Handling user permissions and

privileges is also an important

requirement. Although both authors andstudents interact essentially with the

very same UI, they use the application in

different modes. Diagram operations and

visualization are different in authormode and edit mode. The UI should be

adaptable to these modes and also,accessing the data behind the

presentation should be controlled.

3.2 Browser-based Modeling

Another system we have envisioned is a

cloud-based collaboration environment

for model integrated computing.

However, the first generation of thissystem is not planned to implement a

complete, web-based modeling toolkit to

replace existing desktop applications, itis our intent to provide some modeling-

related functions through the browser for

better usability and accessibility. Also,

in the scope of this project we areinvestigating fundamental challenges of

an entirely browser- and cloud-based

modeling environment.One of the key examples of related

functions is an HTML model-visualizer

component for browsing available

models in the model-repository. Thiscomponent is conceptualized to be

capable of visual rendering models

created in standard notations or in anyarbitrary DSML (with some limitations

on visual representation). Such a model-

visualizer also could be employed in theconflict resolution process of the version

control services (see Fig. 3.).

International Journal of Digital Information and Wireless Communications (IJDIWC) 1(2): 455-465

The Society of Digital Information and Wireless Communications, 2011(ISSN 2225-658X)


5/11

459

Fig. 3. Muckup of the HTML-JavaScript

conflict-resolver. In this concept, the direct

spatial context of the conflict would be

visualized. The user would be able to navigate in

the change log to better understand the intents of

the other designer.

On the long term, this visualizer component

could serve as the basis for an HTML-JavaScript

UI of a future, browser-based modeling

application. We gained tremendous experience

with using GME [9] and other desktop-based

modeling technologies. It is our interest to turn

this valuable experience into needs and

requirements towards a next-generation, entirely

cloud-based modeling environment, which

would provide some form of a version control

solution with conflict resolution, real-time model

sharing and collaborative authoring as built-in

features.

Usability versus Constraint Checking.Constraints enforce syntax and semantic

rules, therefore both diagram

construction and model building isguarded by constraints. Constraint-

violating operations should be not

allowed, aborted, or a warning messageshould be issued. It is desired that

interactive components of the UI

somehow inform the user of allowed edit

operations that would not result inconstraint violation.

A full-scale solution for this problem

would rely on analyzing the current state

of the model (or model components inthe scope) and generating a set of thepossible next states. This would involve

constant constraint checking and runningremote interpreters that could not be

efficiently ported to the client-side

JavaScript platform. Taking in

consideration that just a single complete

model validation itself is a heavyweight,time-consuming process, triggering such

a robust mechanism after each useroperation would cause a rather rough,

paralyzing user experience.

Lightweight Constraints.Our proposed

partial solution for the problems causedby constraint checking, is to make it

possible for DSML designers to define

lightweight constraints. Lightweight

constraints form an optimal subset of allthe constraints and rules. They are

written in JavaScript and are checked

directly on the client side in the browser.The authoring environment enforces

them construction-time, preferably in

advance: it prevents constraint-validation by blocking the user from

doing disallowed operations. This way

of using lightweight constraints is

related to correct-by-constructionmethodologies.

When lightweight constraints are

utilized, complete model validation,

(including invoking remote interpreters)can be triggered less frequently or

manually. If the validation process

returns that the model in an invalid state,context-aware, informative warning

messages, and guidance for resolving the

conflicting problem need to be offered tothe author. Assuming that the operations

on the model are journaled, conflicting

changes can be reverted, eventually

bringing the model back to a previousvalid model state.

In some cases it is hard to separate

certain aspects of the complex semanticrules, which are implemented by the

complete model validation. Instead of

the segmentation of logic (and the

corresponding code), some constraintscould be expressed as parameterized



6/11

460

rules or static configuration attributes

(e.g.: possible drop location on the

screen for a draggable object, or a set ofvalid ranges for a numeric object

property) on the front. Lightweightconstraints defined this they are

essentially redundant but practical.

Fig. 4.Frequent, lightweight constraint checking

mechanisms are run on the client-side. Remote,

complete constraint checking is triggered less

frequently, usually by saving operations.

4 CONCEPT OVERVIEW

Our effort to overcome the design

challenges we summarized above is

embodied as a framework-concept that is

built on a client-side HTML-JavaScript

core. This core is responsible foressential visualization tasks and handling

user interactions. Furthermore it alsoimplements client-side functions for

supporting version control, constraint

management and other modelingconcepts. Flexibility of the framework

relies on a meta-language concept,

which can be used to create new

libraries, and an extendible object-oriented JavaScript code-base, which

can be tailored for various applications.Further customization of functionality

and visualization can be achievedthrough a plugin-architecture. The

client-side core is designed to work with

a scalable server-side module, whichhandles user-management, collaborative

work, data storage, version control and

remote extensions.

Fig. 5.High-level framework architecture.

4.1 A Generic Meta-model for Visual

LanguagesBasic Concepts

Components and ComponentTypes.Inour concept, language elements of a

notation or DSML are called

ComponentTypes, elements of diagramand model instances are called

Components. The visual and interactive

aspects of Componentsare referred to as

Skins.

Properties and PropertyTypes.

According to our terminology, theattributes of Components are called

Properties. Properties are instances of

PropertyTypes, which are defined for thecorresponding ComponentType.

PropertyTypes are derived from three

basic types, depending on their role and

behavior:VariableTypeis the base type for atomic

PropertyTypes specified with an

arbitrary numeric or textual value and a

Quantity. Variables with quantities canbe primarily used to express physical

properties and have asymboland a set of

Units attached. Furthermore, an enum-like set of possible values (or closed

ranges for numeric properties), referredto as ValidRanges can also be definedfor VariableTypes. The predefined valid



7/11

461

ranges are taken in consideration by

lightweight constraint checking

mechanisms and are used to display andenforce limitations on the possible

values of the property by the UI controlsright before value changing operations.

Expressing limitations on the value of aproperty this way is an example for

defining redundant constraints in the

language specification. It poses somerisk of introducing an error causing

inconsistency but if supported on the UI,

can significantly increase usability.

Variables can also be bound to skinattributes. For example, if the magnitude

property of a vector component is bound

to the width property of the vector skin(visualized as an arrow), the value of

these properties are synchronized: if the

user resizes the arrow on the canvas, themagnitude property gets changed as

well. Similarly, when a new magnitude

value is set through the properties panel,

the width of the arrow reflects the valuechange accordingly. Bondable skin

attributes should be declared in the skin

along with the transformation functions

getting and setting the value from thehost (component) side.

ReferenceTypeis for expressing relations

between components. The targetTypeattribute specifies which type the

reference can point to, the visualizedAs

attribute tells the UI renderer how thereference instance should be visualized.

The framework is going to be shipped

with some essential visualization

methods such as ports with wires andcontainment. Library developers will be

able to build their own visualizers and

import them as plugins.

SetType defines a collection of

properties based on a member

PropertType specified in the

memberType attribute. The size of theset can be limited with the value of the

maxSize, which is used by lightweight

constraint checking similarly to

ValidRanges specified forVariableTypes.

Properties can be grouped with definingPropertyGroup structures.

PropertyGroups are usually semanticallytransparent but useful for controlling

visibility and organizing the presentation

of the properties on the ComponentInspector Panel(CIP).

Fig. 6. Model elements for describing visual

languages.

4.2 Component and Property

Visualization

The UI code of the framework is writtenusing jQuery [20] and custom-built

jQuery plugins. There is a set of built-in

controls provided, but for greaterversatility library developers have the

possibility to extend the basic visual

functionality and to import their custom

UI functions.Component Skins are implemented as

external assets. Designers can use

standard HTML technologies (includingJavaScript and CSS) to implement skins.These assets are processed as templates

by the component visualizer engine to

render components on the drawingcanvas. The context and the id of the

host component object are passed down

to the skin template. This facilitates



8/11

462

implementing hooks and event handlers

(such as on_AddTo, on_AfterAdded,

on_render, on_select etc.) in skinspecific JS code and also can be utilized

for tailoring the visual appearance of agiven component instance through CSS

rules. The definition of bondable skinattributes along with the value-

transformation functions usually takes

place in the on_AddTo event hander.Controls for transforming and interacting

with components can be added in the

on_select or on_render handler. There

are a few common controls shipped withthe framework (rotation, scaling etc.).

Custom controls along other language

specific utility functions can be importedin the library JS code.

Fig. 7. A UI mockup showing built-in controls

for rotating and resizing components.

The visualizer engine provides a genericsolution for direct manipulation of

component property values through the

CIP. If a property is configured to be

inspectablein the language specificationand has a Widget assigned, it gets

rendered on the CIP. There arenumerous widgets offered by the

framework for the most common valuetypes (TextField, SingleSelect,

MultipleSelect, TextArea, CheckBox).

Grouping can be used to maintain cleanand easily interpretable visual listings of

properties.

4.3 Visibility and Access Control

With utilizing the hiddenFor and

readOnlyFor attributes in the languagespecification, designers can define

access control rules. These attributes can

be set for ComponentTypes,PropertyTypes and PropertyGroups. The

attribute values can be single user role

identifiers or list of identifiers separated

with comma. Write access tocomponents and properties is primarily

handled in the client but also guarded on

the server side. Visibility is entirelycontrolled on the remote end: the server

filters and compiles the content being

pulled down according to the credentialsof the actual user. It must be noted, that

if some parts of the model or language

specification are not visible for the client

side, only the server module can docomplete validation.

4.4 Constraint Management

All the user operations affecting

property values and altering component

states are logged and managed by theOperationManageron the client side. A

user-operation is basically a series of

basic predefined actions and handled asa transaction: after each operation,

lightweight constrain checking is

triggered; if there is a constraint

violation, a warning message is returnedas response and the operation gets rolled

back. Lightweight constraint checking

can also be invoked under the hoodbefore a possible value or state change.

Essential rules for lightweight constraint

checking can be conveniently defined in

the library descriptor (see description ofPropertyTypes above). Custom rules and



9/11

463

validation can be attached to properties

as JavaScript code. Although, these

snippets have access to the property- andcomponent-registry, and can implement

robust verification, developers shouldpay attention to the usability factors:

massive, resource-intense validation,including remote mechanisms should

rather be specified in the libraries

onVerification event handler attributethan as lightweight constraints. Code

placed in onVerification is called when

the diagram or model is saved or

synchronized with the storage.

4.5 Libraries

Diagram notation- and DSML

specifications should be deployed as

library packages. Each library packagehas to contain an XML-based descriptor

of ComponentTypes, PropertTypes and

related artifacts (such as Quantities,

Constraints, etc.) using the meta-language we introduced above. Skins are

included in library packages as

standalone HTML files. Custom CSS

and JavaScript files containing plugin-codes and other assets (images etc.) can

be imported in the library descriptor and

should also be placed somewhere in thedirectory structure of the library

package.

Fig. 8.Contents of the library package.

4.6 Client-side Support for Version

Control and Collaboration

Operations logged by the

OperationManager are used as deltas by

collaboration and version controlfacilities running on the server. The

client side is intended to permitconnection to the server module through

a comet interface. This interface willallow the server to synchronize

operations among multiple clients

working on the same model or diagramcontinuously.

4.7 Server-side infrastructure

Above we introduced the concept of

lightweight constraints. In some cases

these constraints are expressed indirectlyin a redundant manner (for example

using the validRanges attribute).

However, the normal manner of defining

lightweight constraints is to provideconstraint functions written in JavaScript

for ComponentTypes and

PropertyTypes. These functions can bevery complex and can manipulate on

very large datasets. The size of the

dataset, and this way, the cost of running

a constraint function can depend ondynamic attributes, such as the size or

state of the given model instance.

Therefore, deciding if a constraintshould be checked remotely or locally

can change over time: fore example a

function, which earlier was designed tobe a lightweight constraint but turns out

to run slow under certain conditions will

need to be re-deployed to the server-side

and invoked as part of the less-frequentcomplete model validation. If the server

side infrastructure were capable of

executing JavaScript code, languagedesigners would not have to deal with

translating their constraints from one

programming language to the other.

This led us to change one of our designdecisions: originally we were planning

International Journal of Digital Information and Wireless Communications (IJDIWC) 1(2): 455-465

The Society of Digital Information and Wireless Communications, 2011(ISSN 2225-658X)


10/11

464

to use mainly Python frameworks on the

server-side but now we are currently

experimenting with available JavaScripttechnologies. Our new server-side

infrastructure concept is based on V8[21] with services written in Node JS

[22] and Express [23] using MongoDBin the backend.

5 CONCLUSIONS AND FUTURE

WORK

There is an increased need for cloud-

based, collaborative diagramming andmodeling environments in engineering

and engineering education today. It is

our goal to design and build a genericframework, which could provide a

foundation for developing such

environments.Our preliminary design work discovered

that usability, user experience,

extendibility and flexibility are the key

attributes of these applications. Amongother design challenges, we found some

of these attributes being in conflict with

modeling concepts, such as constraint

checking. To overcome the challengeswe designed a browser-based modeling

framework, introduced new concepts

and implemented a generic meta-modelfor authoring visual languages.

The framework is currently under

development. Implementation is carriedout in two phases. In the first phase, the

initial version of the HTML-JavaScript

core was implemented; it is being

integrated into the systems described insection 3. In parallel with this, the design

of the server-side module is getting

finalized, which will be implemented inphase 2.

Evaluations of experiments with

working, high fidelity prototypes show

positive results. Although some UIelements need to be fine-tuned for better

touch screen usability, our general

concept and approach appear to be

feasible for building basic diagrams. Weare looking for ways to address and

improve the user interface and theoverall user-experience. An educational

application built on the client sidearchitecture of the framework is going to

be tested and evaluated in real classroom

experiments during the upcomingmonths.

We made progress on designing the

server-side infrastructure. Our focus

moved towards utilizing newlyavailable, high performance JavaScript

server technologies. Using JavaScript on

both ends will increase flexibility andease the development of new visual

languages with complex semantics.

Acknowledgements. This research was

funded in part by the National Science

Foundation (NSF) under award 817486.

Capitalize the first letter of each word.Use a bold font.

6 REFERENCES

1. Tsintsifas, A.: A Framework For The

Computer Based Assessment Of Diagram-

Based Coursework. Loughborough

University (2002).

2. Lohse, G.L., Biolsi, K., Walker, N., Rueter,

H.H.: A Classification Of Visual

Representations. Commun. ACM. 37, 3649

(1994).

3. NassiShneiderman Diagram,

http://en.wikipedia.org/wiki/Nassi%E2%80

%93Shneiderman_diagram.

4. House Of Quality,

http://en.wikipedia.org/wiki/House_of_Quality.

5. Sztipanovits, J., Karsai, G.: Model-

Integrated Computing. Computer. 30, 110 -

111 (1997).

6. Van Deursen, A., Klint, P., Visser, J.:

Domain-Specific Languages: An Annotated

Bibliography. SIGPLAN Not. 35, 2636

(2000).



11/11

465

7. Omnigraffle,

http://www.omnigroup.com/products/omnig

raffle.

8. Microsoft Visio,

http://office.microsoft.com/en-us/visio/.

9. GME: Generic Modeling Environment,http://www.isis.vanderbilt.edu/Projects/gme/

.

10. Jay, A.: Five Best Online Diagramming

Tools,

http://www.smashingapps.com/2010/01/18/f

ive-best-online-diagramming-tools.html.

11. Altmanninger, K., Seidl, M., Wimmer, M.:

A Survey On Model Versioning

Approaches. IJWIS. 5, 271-304 (2009).

12. Schneider, C., Zndorf, A.: Experiences In

Using Optimisitic Locking In Fujaba.

Softwaretechnik Trends. 27, (2007).

13. Brosch, P., Langer, P., Seidl, M., Wimmer,

M.: Towards End-User Adaptable ModelVersioning: The By-Example Operation

Recorder. Proceedings Of The 2009 ICSE

Workshop On Comparison And Versioning

Of Software Models. P. 5560. IEEE

Computer Society, Washington, DC, USA

(2009).

14. Tolosa, J.B., Gayo, J.E.L., Prieto, A.B.M.,

Nez, S.M., Pablos, P.O. De: Interactive

Web Environment For Collaborative And

Extensible Diagram Based Learning.

Computers In Human Behavior. 26, 210 -

217 (2010).

15. Roselli, R.J., Howard, L., Brophy, S.: AComputer-Based Free Body Diagram

Assistant. Computer Applications In

Engineering Education. 14, 281290 (2006).

16. Howard, L.: CAPE: A Visual Language For

Courseware Authoring. Second Workshop

On Domain-Specific Visual Languages. P.

2002 (2002).

17. Howard, L.: The Elms Learning Platform,

http://w3.isis.vanderbilt.edu/Projects/VaNT

H/Index.htm.

18. Bose, G.: Affordance In Elearning,

http://elearning.kern-

comm.com/2006/09/affordance-in-elearning/.

19. User-Centered Design,

http://en.wikipedia.org/wiki/User-

centered_design.

20. Jquery: The Write Less, Do More, Javascript

Library, http://jquery.com/.

21. V8 Javascript Engine,

http://code.google.com/p/v8/.

22. Node JS,http://nodejs.org/

23. Express, http://expressjs.com/

http://code.google.com/p/v8/http://code.google.com/p/v8/http://nodejs.org/http://nodejs.org/http://nodejs.org/http://nodejs.org/http://code.google.com/p/v8/

ARCHITECTURAL FRAMEWORK FOR GENERIC MODELING AND DIAGRAMMING IN THE CLOUD

Documents

Transcript of ARCHITECTURAL FRAMEWORK FOR GENERIC MODELING AND DIAGRAMMING IN THE CLOUD