Web-based Integrated Development Environment

1. Web-based Integrated Development Environment Application Design Document

2. Roles & Responsibilities • Academic adviser: Dr. Mayer Goldberg • Technical adviser: Mr. Guy Wiener • Project Team: • SuzanaVaserman • David Fleish • Moran Zafir • Tzvika Stein

3. Table of contents • Background • System Requirements • System Architecture • Main classes and their relationships • User Interfaces • Open questions • Task list

4. Background (reminder)

5. Current Situation • Developers working on a software project, nowadays, use code management tools to organize their code (e.g. SVN and Clear Case). • The actual code creation and modification is done locally on the developer’s machine.

6. Current Situation – Problem Domain • The code must be downloaded and uploaded from and to the code repository – time consuming. • A developer’s final version of the code might have conflicts with the version on the server at upload • time – conflict resolving can be tedious. • Developers must have all the software required for developing installed on their machines – require licenses which raise expenses.

7. Current Situation – Problem Domain (Cont.) • As a result of high software demands, both for developing and for testing, hardware demands for developing machines might rise as well – expenses increase. • Sometimes, developers working on the same project aren’t necessarily at the same physical location, which makes it hard to cooperate and communicate with one another – communication issues slow the developing process.

8. System Requirements

9. System Requirements • In order to overcome the issues we just mentioned we intend to develop a web-based IDE in which: • There will be only one valid version of the code at any given time. No local versions. No check out and check in. • All editing of the code will be done within the web browser and stored directly on the central server. • Programmer’s view of the code is always the same for all programmers.

10. System Requirements (cont.) • All resources required for developing the application will be located on the server. • No special hardware or software requirements on the developer’s side, other than a web browser. • An integrated chat should encourage users to communicate with one another for better cooperation and coordination.

11. System Architecture

13. The Client Architecture • A standard web browser is used to interact with the application. • The client has to send different query requests to the server : • Retrieve directory structure upon expand. • Retrieve users associated with active project. • Retrieve modifying users of open files. • Etc ..

14. The Client Architecture (cont.) • Initiate update check requests regularly : • Directory structure updates • Open files updates • Chat messages updates • After each response from the server the client has to • modify the client’s view

15. The Controller Architecture • The controller is the middle tier that interprets and processes requests from the client and accesses the database. • The Controller and Database sits on the same computer • The controller consists of 2 components : • Web Server • Application Server

16. The Web Server Architecture • Emulates the serverwith apache software. • Receives requests from the client • Delegates the requests to the application server • Sends application server responses back to the client.

17. The Application Server Architecture • Consists of physical files and logical objects in the system • Receives and process requests from the web server and executes specified transactions on the database • Data requests - Directories content, association between users and projects, etc… • Update requests – Files change • Updates both Database and physical files • Dynamic updates - users log in, log out, open files, close files, Updates logical data.

18. The Database Architecture • Stores users and projects related data • (except physical files and dynamic associations) • Receives requests from the application server and returns desired records. • Maintains properties for first system setup • Uses MySql to manipulate data

19. The Database Architecture (cont.) • Links between user and associated projects. • Links between user and created files. • Links between tags and associated data. • Links between run configurations and files. • Links between users and permissions

20. Main Classes & Their Relationships

29. User Interfaces

30. Login

31. Project Selection

32. Work Bench

33. Work Bench

34. Work Bench

35. Work Bench

36. Work Bench

37. User Creation

38. Project Creation

39. Project Deletion

40. Run Configuration Definition

41. Execution of Run Configurations

42. Permissions

43. Project Manager Selection

44. User Types Management

45. Open Questions

46. Open Questions • The programming language we are going to support and the tools we are going to use for compilation and execution • Will we support simultaneous connections of a certain user to a certain project • How to keep consistency between the File System and the DB

47. Task List

48. Application • Data base • Build data base • Create data base controller • Project management • User management

49. Application (cont.) • File management • File operations • File tags • Refresh file structure • Search file • File editing/viewing • File configuration

50. Application (cont.) • Chat • Logging in and out of the system • System cleanup