SCAD has been around since 1983 (with advent of lotus 1-2-3). This development methodology was never widely adopted because companies such as Lotus or Microsoft never promoted it as such. The marketers within these Fourth International Conference I.TECH 2006 companies designated these packages as “end-user” products and it was more profitable for them to segment the market in this fashion.
With the advent of Microsoft Office and Visual Basic for Applications (VBA), SCAD took a giant leap into being recognized as serious application development tool. But Microsoft continued to resist the complete independence of VBA from the Office application by refusing to create runtime versions of Excel or Word.
Having recognized this gap in the market, several alternatives have emerged to fulfill a demand for SCAD.
The best, most reliable, fastest, and most Excel-compatible of these products is Formula One e.Spreadsheet Engine. It is geared toward delivering enterprise reporting applications, which presently are the most visible adoption of SCAD. Formula One is implemented in Java and can be used as a component in Java desktop applications and applets.
In the following sections we introduce our implementation of a web-based spreadsheet engine. Unlike the applications mentioned above the architecture of our application is not restricted to particular language or environment. We employ only ubiquitously adopted standards and loosely coupled component architecture that allows building of extremely portable and flexible application that can be deployed in many different usage scenarios.
System Architecture Fig. 1 depicts general architecture of our system. It comprises of 3 tiers – user interface layer, application layer and persistent storage layer.
Application layer comprises all algorithms and internal data structures that are involved in spreadsheet management and processing. Upon client requests (that come from the user interface layer) it fetches the data from the persistent storage layer and builds internal data model of the manipulated spreadsheets. Then it uses these data models to re-calculate the spreadsheets values based on the user changes and sends the updated data (user changes) back to the persistent storage layer and forth (recalculated fields values) to the user interface layer.
Persistent storage layer contains database logic for storing, retrieving organizing and managing internal application layer’s data structures on persistent media. This layer is normally implemented with the help of some kind of data management systems. In practice they can be relational databases or xml databases. The communication protocols can be SQL and XPath or XQuery correspondingly. It is even possible this layer to be implemented with web services as well. The later will decouple the application layer from the need to know the exact representation of the database back-ends used.
Software Engineering Persistent Storage Layer SQL SQL SQL XPath XPath XPath XQuery XQuery XQuery ApplicationLayer HTTP HTTP HTTP HTTP SOAP SOAP SOAP SOAP REST REST REST REST User Interface Layer Fig.1. 3-tier architecture of our system is suitable for small and middle-size deployments.
Implementation Our implementation of afore mentioned architecture complies with the following basic requirements:
• Many different people must be able to use it from any physical location provided Internet connection and a contemporary version of widespread web browser is available.
• The engine must support at least 3 different user roles (groups of users):
o Spreadsheet Designers - they can create/import and edit spreadsheets’ definitions.
o Regular Users – they can use available spreadsheets i.e. just filling the data in the cells that are not locked.
o System Administrators – manage all of the aspects of the system that are not application specific – installation, deployment, maintenance, support, etc.
• The data entered by the regular users must be kept separated from the spreadsheet definitions so that it can be reused in different spreadsheets and/or other related applications.
• Ajax version must be able to work on IE and Firefox. If it is possible Opera and Safari must be supported as well.
• The system must be able to import MS Excel spreadsheets and convert them into its internal form – reuse already created spreadsheets and use MS Excel as a primary design tool until comparable web based spreadsheet designer is developed.
Fourth International Conference I.TECH 2006 The current version of our implementation is a standard 3-tier web application that utilizes the following technologies:
• Application layer – this layer contains all of the algorithms and data structures that implement the core spreadsheet engine functionality. Upon client requests (coming from the user interface layer) it fetches the data from the persistent storage layer and builds internal data model of the manipulated spreadsheets. Later it uses these data models to re-calculate the spreadsheets values based on the user changes and sends the updated data (user changes) back to the persistent storage layer and forth (recalculated fields values) to the user interface layer. Currently this layer consists of PHP pages (for stateless services) and Java servlets (for statefull services that manipulate big data models). The implementation uses REST services. Although REST is not a standard but an architectural style, its light-weighted, requires fewer resources, and is simpler and faster for quick-and-dirty implementations. Later we can convert inter-layer communications to the complete SOAP, WSDL, WS-I stack if it is needed. This layer contains also all of the algorithms and data structures that dynamically build user interface pages (screens) of the system. Another responsibility is getting and validating request parameters from the user interface layer and reformatting the response data if it is needed.
• Persistent storage layer – it uses relational database storage. It was tested with MySQL and SQL Server, but as it uses standard SQL queries it should work with any complaint relational database system. This layer contains also a tool that creates spreadsheet definitions from existing MS Excel spreadsheets.
Figures 2 and 3 show the same spreadsheet opened in MS Excel and its converted version opened with our application. Our conversion tool preserves not only computational logic and cell merging but also visual formatting as much as possible. It is required as our tool has not full-featured visual designer yet. We use MS Excel for initial creation of the spreadsheet visual representation.
Fig. 4 shows another spreadsheet opened in IE with the help of our web application. This screenshot depicts one unique feature of our system – it can show the cell’s formula as tooltip when the mouse pointer hovers over the corresponding cell. Although it is currently not implemented, the same technique can be used for visualization of other types of information – for example, displaying the inter-cell dependencies as a tree rooted in the current cell with a nodes and leafs the cells it depends on in the corresponding order and level.
Fig.2. A complex spreadsheet opened within Microsoft Excel.
Software Engineering Fig.3. The spreadsheet from fig. 2 converted and managed by our system. Opened within Internet Explorer Fig.4. One unique feature of our system is showing cell formulas as tooltip when mouse hovers over the cell.
Fourth International Conference I.TECH 2006 Conclusion and Future Work In this paper we presented our implementation of web-based spreadsheet engine. It employs many contemporary technologies for building scalable and responsive web applications. Several improvements and additions need to be implemented in order to make a system more usable and user friendly. Among them are - support more browsers (Opera, Safari); support more MS Excel features and formulas; add some unique features as the ability to use CGI scripts or web services in formulas (getting weather conditions, exchange rates in real-time); many other optimizations and improvements.
Software Engineering 1. Introduction Imagination is extremely refined work of the human mind. It is the easiest medium for to creation out of nothing.
Human mind constantly works on creating something that has never existed before and does not now exist. This is the approach with which any professional creator of Digital Art, or in other words, creator of design will gain success. Digital culture is neither new nor determined by technology, but rather that technology is a product of digital culture. The term "digital" originally referred to data organized in discreet units in any system, linguistic, and numerical systems included.
Since the use of computers became an everyday occurrence the wide variety of software has been emerging to assist designers. From the simplest and primitive up towards professional graphics editors computer software has undergone the complicated evolution and development. I shall not mention vector graphics editors; however I’d prefer to concentrate on bitmap graphics editors, which are mainly used to produce images.
Graphic information is stored in computer memory in "bitmap" or "raster" formats such as JPEG, PNG, GIF and TIFF. Besides that, every company that creates graphics editor sets up its own format of storing raster graphics.
I would like to start the review of graphics editors with RIP editors, those that currently represent solely historical interest. Among the first editors the following deserve mentioning Deluxe Paint, Personal Paint and Photogenic.
2. Deluxe Paint Deluxe Paint (DPaint) is a bitmap graphics editor created by Dan Silva for Electronic Arts (EA) . The original version was created for the Amiga OS and was released in November 1985.
DPaint was the product of an in-house art development tool called Prism. As Silva added more features to Prism, it started to have market-place potential. When the Amiga was released in 1985, DPaint was quickly released for it. It was quickly embraced by the Amiga community and became the standard graphics development tool for the platform. Amiga manufacturer Commodore International later struck a deal with EA to have DPaint (and later its four "sequels", versions 2, 3, 4 and 5) bundled with every new Amiga sold. This deal lasted until Commodore's bankruptcy in 1994.
Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.