This document discusses the development of a cloud-based modeling environment that allows for collaborative diagramming and modeling. It proposes two main use cases: 1) an HTML-based educational diagramming tool and 2) modeling in the browser. Some key requirements and design challenges are outlined, including making the tools usable across devices, allowing for simultaneous collaboration, and handling constraints to prevent invalid model states. The proposed architecture includes an HTML/JavaScript client, a Python/TurboGears server, and a descriptor language to define modeling languages and apps. Prototypes are under development to test the approach.

1. Towards a Generic Cloud-based Modeling Environment Laszlo Juracz and Larry Howard Institute for Software Integrated Systems at Vanderbilt University Nashville, U.S.A. International Conference on Digital Information Processing and Communications, Ostrava, Czech Republic, July 7-9, 2011.

2. Our focus

4. cloud computing

6. components

7. widgets

11. Code

12. Simulations

13. Analysis

16. Accessible / usable on various devices

17. Share my stuff with others

18. Work on the same documents simultaneously, individually or in a collab. env. (virtual whiteboarding)

20. Accessible / usable on various devices

21. Share my stuff with others

22. Work on the same documents simultaneously, individually or in a collab. env. (virtual whiteboarding)

23. Cloud storage☻ ☹ ☻ ☻ ☹ ☻

25. Accessible / usable on various devices

26. Share my stuff with others

27. Work on the same documents simultaneously, individually or in a collab. env. (virtual whiteboarding)

29. Provides gateways to external services/processes (analysis, deployment, …)

30. Can be embedded / integrated / toolchained

31. Re-usable, generic☹ ☹ ☹

32. Design challenges

33. Use-case 1:HTML-based Educational Diagramming Tool

35. Smooth UX, intuitive UI, affordance

36. Device-agnostic performance

37. Suitable for educational apps

39. Interaction and integration with remote services

40. Handles user permissions

41. UI adapts to author/edit modesUser-centered design

44. Share / Publish

45. Version Control

46. Plugin architecture for extendibility

47. Provides interface

48. to interpreters

49. to other modeling services (validation, analysis, simulation)Optimistic locking, conflict resolution

50. Model visualizer for conflict resolution

52. Diagram- and model building is guarded by constraints:

53. Constraint-violating operations should be not allowed or

54. Should be Aborted and

55. Warning message should be issued

57. could not be entirely ported to the client-side (JS platform)

59. checked directly on the client side in JS

60. enforced construction-time, preferably in advance: it prevents constraint-validation by blocking the user from doing it.Complete validation, including remote interpretation should be triggered less frequently / manually.

62. Concept overview

63. Architecture HTML(5) / JS Python / TurboGears

64. Descriptor Language Instances

65. Library Package

67. UI is implemented in jQuery

68. Custom UI controls

69. User operations are logged, deltas are saved

70. LWC checking, operations can be rolled back

73. Client side core is under testing /development

74. Prototypes of educational apps built on the framework will be utilized in classroom experiments in fall 2011 (FBD, flowcharts)

75. Model visualizer will be delivered in 2012

76. Design of the server side module is getting finalized