Archimedes An open CAD platform based on RCP Hugo Corbucci, Mariana Vivian Bravo and Alfredo Goldman Instituto de Matemática e Estatística Rua do Matão, 1010 Cidade Universitária, São Paulo, Brasil

{corbucci,marivb,gold}@ime.usp.br ABSTRACT Years ago, the task of creating a software required several tools that were unique to each language and platform. Over time this changed, and since the popularization of Integrated Development Environments (IDEs) like Eclipse, a single tool can aid the production of code to many languages and platforms. Users can benefit from any contribution to that tool. Computer Aided Design (CAD) systems are complex programs used to design all sorts of physical projects, from microships to airplanes. Just like software development years ago, each CAD software is unique and can hardly be used by several areas. Because this problem is very similar to the one software had, a platform for CADs would improve the quality of those applications. Archimedes is a CAD system that aims to become such platform. This paper will present what is Archimedes with more details and how it is designed. It will also comment on how it used the extension points from Eclipse’s Rich Client Platform (RCP) to create a flexible and reusable system for CADs.

General Terms CAD platform

Keywords RCP, CAD, Eclipse, Archimedes, Open source

1. INTRODUCTION Computer Aided Design (CAD) software are powerful tools used in a wide variety of areas, such as engineering and architecture. They allow for 2D and 3D modeling of houses, airplanes, chips and basically any product that that can be designed with drawings. A lot of CADs also do physics simulations and other kinds of calculations to support the user’s task. With this diversity of uses CAD tools have, it is difficult to create an application that suits everybody’s needs. Thus there are many commercial programs available on the market that focus on specific professions.

Eclipse Technology eXchange Workshop at OOPSLA 2007 Montreal, Canada

Since these professionals often work together (for example, engineers with architects), the interoperability desired between different software products is not always achieved. Another important issue is that for some areas there are not as many tools as for others, and so professionals have to use software that is not so focused on their needs. A similar situation has already happened with programming tools. Some tasks are alike no matter what language or kind of application is being developed, for example version control, editing the source code, running a program. However some specific details change, making it impossible, for example, for C programmers and Java programmers to share the same application unless this application is a simple text editor. Tools like Eclipse have solved this issue for software developers: more than an IDE (Integrated Development Environment), it is a base to build IDEs. The plugin system promotes the reuse of components for similar tasks, diminishing the effort to create an IDE for a new language. Also, the views and perspectives allow the programmer to build his own working environment to suit their needs, regardless of language and kind of application being developed. At the core of Eclipse is its Rich Client Platform (RCP), a framework for developing any kind of plugin based application. A variety of tools has been developed with this platform, ranging from bit-torrent ([3]) and financial applications ([4]) to a couple of geographic information systems (GIS) ([7] and [5]). The framework is constantly under improvement and validation by the community. Since the problems described so far for CADs and IDEs are so similar, it would be expected that a similar solution existed for CAD but it does not. CADs are focused on one area’s problems and do not share development effort. Therefore, no framework has emerged from any CAD product. However, RCP has been created to support any application and could very well be the base for the CAD framework. Hence Archimedes is a rich client application for general purpose CAD being developed to become a platform for CAD systems. The next section presents a brief history of Archimedes and an overview of how the software works. The third section describes the model developed so far for the CAD platform and how it can be extended. After that, the fourth section

lays out steps for the future and the last section presents a conclusion.

2. ARCHIMEDES In this section, a small description of Archimedes ([1]) history will be presented and then it will be followed by a technical description of the system’s design in order to make it simpler to understand the modifications required on the software to transform it into a general CAD platform.

2.1 A brief history The first idea to develop Archimedes comes way back from 2001. For several reasons, the development only begun in the late 2005 by a team of students from the University of S˜ ao Paulo ([8]). By that time, the main goal was to end up having an open source application for architects in contrast to the engineering focus most software have. Archimedes had to ensure that users would not have to relearn how to do their jobs and, at the same time, make a migration to other platforms such as Mac OS X or Linux possible. Considering those constraints, the team chose Java as the programming language to leverage its portability. Also, in order to grant a natural look to the software and to improve the graphical performance required, SWT with OpenGL ([6]) was chosen. Having made those choices, the focus of the program was quite clear: to offer an open source alternative to the widely adopted AutoCAD ([2]). This software is based on two dimensional drawings being used mainly to create technical plants of almost anything. Therefore it is very used as a more sophisticated drawing table. Thanks to this approach, it is able to create a microchip for a computer processor as well as an airplane or a building. Archimedes was first planned to be much more restrictive in the sense that it was focused on architecture problems because the team was aware that trying to implement the needs of several areas at the same time was not reasonable. The original team spent six month, from march to july 2006, working on the project with the support of an eXtreme Programming (XP) Laboratory ([10]) course at the university. This experience made the software evolve along with the users requirement following XP’s practices. Those changes transformed Archimedes’ first goal. By the end of 2006, users requests made the team realize that Archimedes was loosing flexibility with its narrow focus on architecture. In the next subsection, the system’s design at the end of 2006 will be shown so that, in section “Creating a CAD Platform” (3), the reader will understand better what were the changes required to make the software more flexible.

2.2 System overview The software is based on a command prompt with a drawing area (Figure 1). Commands are input through the keyboard and the parameters can be given as text or with the mouse, by clicks on the drawing area. This allows the user to change his work context quickly without having to search for actions in big and complex menus. What follows will describe the interface layer responsible for interaction with the user.

2.2.1

The interface layer

To handle two kinds of input in the same way, the data received by mouse is transformed to text. This information, just like that obtained from the keyboard, is sent to an input controller (InputController). These texts can be used to activate a command, send parameters to this command until it ends and then execute the action it will generate. From the system’s point of view, what is executed is the action, that implements the Command pattern ([9]). The class that generates this action is a Command factory, like the Template Factory ([9]), therefore called a CommandFactory. For example, to create a line, you must first activate the line factory, then two points must be defined as parameters and finally the action that will create the line. To process this information, the InputController depends on its state. It was, therefore, implemented following the State Pattern ([9]). There are two main possibilities: • IdleState: There is no active factory In such case, the InputController asks the command parser (CommandParser) for the factory associated with the user’s input. If there is such a factory, it is activated and the state changes. If not, the state remains the same. • ActiveState: There is an active factory If that is the case, the active factory should deal with the input. The translation of text to model objects is done by Parsers because many factories accept the same kind of parameters (for example, points). Thus, on each step, the factory informs which Parser should handle the next input and awaits for it to return a specific object. When the factory is over the InputController returns do idle state. Once the user sends all the necessary parameters to a factory, it creates a Command that is received by the InputController. It then sends the command to the main system controller (Controller), leaving the interface layer. How this command is handled and what are the objects involved will be described in the next section. An important note is that the flow from the interface level to the model level can only be made through the controller layer according to the MVC pattern ([11]).

2.2.2

Model layer

Upon recieving a Command, the Controller executes it on the current drawing, which will hold information for undoing the action if necessary. This drawing (Drawing) is the main work unit of the model. It contains work layers (Layer) that contains elements (Element), like lines, arcs, etc. The model system uses the drawing as a Composite ([9]) delegating all the render requests to the child elements on the tree. That way the drawing is rendered from the components.

Figure 1: Archimedes’ user interface An almost complete UML of the system described so far can be seen on Figure 2.

date system and the help one, the team had to develop a perspective and an editor.

This architecture was flexible enough to let the team add their own elements and factories with very little change in the rest of the software. However, to any external developer the software had to be rebuilt in order to add their changes.

The next three subsections will comment about the use of those extension points and the the following subsections will discuss the extension points provided by Archimedes.

With the desire to make the software more flexible, it was decided that Archimedes should have a plugin system so that people could use the software as a base to build their own CADs. The main team’s development would still focus on architecture but they would work to keep the specific ideas apart from the core application.

3.1

ActionSet

The action set extension point allows a plugin to contribute to an application menu, toolbar or status bar. Most plugins use a combination of this extension point with others defined by Archimedes in order to make their work available in the interpreter as well as through menus and icons. Besides the basic fields of this extension point such as icon, menu and toolbar path, it is recommended to use optional fields. For After looking into some possibilities, such as creating Archimedes’ example, the field enablement is used by RCP to discover own plugin system, the team chose to use RCP. The next when the action should be enabled thanks to the selection session will discuss the creation of this rich client applicasystem implemented by Archimedes’ core. The helpContion. textId can help the user find information on the action if it has a help topic. This extension point is also the one used to define new submenu when needed.

3. CREATING A CAD PLATFORM

Before starting to create a CAD platform, Archimedes’ team had to discover what were the core features necessary for CADs. Futhermore, other teams or developers should be able to profit from this work without having to rebuild everything from scratch. Extension points are the solution to this problem implemented in RCP and therefore used by Archimedes. The extension points’ system allows anyone to create a small piece of software and define which parts of it can be incremented and refined. Archimedes’ architecture is heavily based on this system. The team used a lot of extensions already defined by the original platform. Besides the up-

3.2

ImportWizards and ExportWizards

The import and export wizard extensions allow plugins to insert their own wizards. Only the import wizard will be described here since all comments about it can be applied to the export wizard almost exactly. That extension point allows the user to benefit from the import system existing in the platform by organizing wizards in categories. This is the way the user discovers what formats are currently available for import. Archimedes’ core used those extensions to add its own wizard that facilitates the creation of wizards by other plugins. This implementation specifies exactly that the other wizards should import a Drawing.

Figure 2: An overview of the system’s core

3.3 Perspective and View So far, every plugin mentioned only added contributions to the interpreter interface or to menus related to those actions. There are, however, great modifications that can be made on the interface. The perspective extension point allows plugins to contribute with an interface layout using any view. With it, developers can implement their specific user interface and override the default one without having to rewrite any code of the controller or model layer. The view extension, on the other hand, can be used to create new interfaces. It may be used to develop interface elements to list information about the current drawing or to provide a way to link a project with another or simply to list a certain kind of elements ordered by position. Any of those views may improve the user’s experience by organizing and displaying data in a better way.

3.4 Factory The first thing anyone might want to add to an interpreter based CAD software are some commands that the user can type to perform actions. Those CommandFactory are the ones discussed previously on section (2.2.1). Allowing someone to create and add factories makes it possible to improve the user’s interface. This way, one can have a fully customized CAD system created on top of Archimedes with only commands that are needed by the main users. The extension point created allows the developer to specify what should be the command’s name and its prefered shortcut. The class loaded when the factory is activated must implement CommandFactory and should as such must spec-

ify parsers and receive Objects. At last, they must produce some sort of Command in order to perform any action on the drawing.

3.5

Exporter and Element Exporter

Any software would be highly limited if there was no way to transmit the information to other people or even to other programs. When persisting any sort of graphical information, there are several very different ways to save the data such as bmp, pdf or xml. From within Archimedes, there are objects that contain all the information in memory and exporting means just translating those objects into the chosen format. Rigorously, this does not require any extension point. However, since new formats may be added as plugins, in order to be able to list all available export formats, the platform must know which ones are available on runtime. Also, exporting a drawing depends obviously on exporting its content. This, however, is not that simple since one only knows at runtime which elements are available for the user. Therefore, Archimedes’ team came up with a solution that uses a dynamic map to discover which elements have the exporter for that format loaded at runtime. Again, this requires some sort of registration for those elements’ exporters which is the reason why there are element exporters. The element exporter extension point defines what component should be responsible for exporting a given element to a specified format. The flow required to export the drawing is controlled by the main exporter and it delegates the work of exporting an element to the respective element exporter.

3.6 Importer

5.

To import a drawing from a file is not as simple as exporting it. The main problem resides in the fact that one may not be able to use a divide and conquer approach to parse the file. Consider the parsing of a bitmap image having to result into a vectorial drawing. Nowadays, there are techniques that allow such parsing given certain restrictions. Some of them, however, are based on scanning the full bitmap field and then, with all the information collected, suggest a resulting drawing. It is, therefore, impossible to identify an element and delegate its parsing to a specific element importer.

Developing a platform focused on an activity quite different from the traditional text-based approach over RCP came out to be a very good experience. It enabled the team to understand what it takes to abstract and generalize the features that someone may have to extend to do what they wish. It did so with an extensive use of design patterns trying to rely only on interfaces and as few implementation as possible. It resulted in a very adaptable and extensible software on which most of the current work is done only by adding plugins to increment the complexity of its elements or to add user commands.

Another problem with the import system is that the file being imported might contain elements that are not available at runtime. This can happen since elements can be added as plugins and one computer might have some plugins while others do not. Yet one should not be forced to download a plugin in order to open files. Considering such restrictions, there are two choices left: 1. Give an error and not open the file 2. Warn the user and open an incomplete file Since CAD users frequently merge drawings that contained work done in parallel, the second choice seems more acceptable. For example, there might be an hydraulic office working with an electricity office. Each would have their specific build of Archimedes and still be able to exchange and merge their files. Therefore, the importer system was conceived as a monolithic component that receives an input stream and must return a drawing without any other specification of import flow or element delegation. To solve the dependency issue between elements, Archimedes’ core contains a small element factory that uses reflection to instantiate registered elements.

3.7 Element The solutions for the importer and exporter extensions motivated the team to add an element extension point. It was not needed previously since the core worked with an interface without having to know anything about the specific elements it was handling. With time, the extension point became a bit more useful since it started specifying the factories used to create the element.

4. STEPS FOR THE FUTURE Currently, the team would like to improve the import and export systems since it seems that their design is not good enough yet to minimize the work needed when adding a new import or export format or making an element supported by some format. Also, the absence of certain plugins on Archimedes causes problems that are not well solved so far. Once the software contains enough features to be used by an architect, it would be a good test to have another team working on the platform to develop some other CAD system focused on engineering or geoprocessing and testing what needs to be adjusted on the core to ensure such work. Only then, it will be possible to say Archimedes is really a platform for CADs.

CONCLUSIONS

There is, however, still much to do. Extensive testing and adjustments have to be made to transform Archimedes into a better platform and hence support several kinds of software. It would then allow interaction between those software, provide another choice to certain professionals or even area specific application to some work areas whose main product is to create plans and projects. A greater involvement from the community could also improve the software’s evolution.

6.

REFERENCES

[1] Archimedes. http://www.archimedes.org.br/. Archimedes home page. [2] Autocad. http://www.autodesk.com/autocad. Autodesk’s page for AutoCAD. [3] Azureus. http://azureus.sourceforge.net/. Azureus home page. [4] Eclipse trader. http://eclipsetrader.sourceforge.net/. Eclipse trader home page. [5] Kalypso. http://www.kalypso-simulation-platform.org/. Kalypso home page. [6] Opengl. http://www.opengl.org/. OpenGL web site. [7] udig. http://udig.refractions.net/confluence/display/UDIG/Home. uDig home page. [8] University of s˜ ao paulo. http://www.usp.br/. University of S˜ ao Paulo web site. [9] E. Gamma, R. Helm, J. Vlissides, and R. Johnson. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, first edition, 01 1995. [10] A. Goldman, F. Kon, P. J. S. Silva, and J. Yoder. Being extreme in the classroom: Experiences teaching XP. Journal of the Brazilian Computer Society, 10(2):1–17, 2004. [11] D. Schmidt, M. Stal, H. Rohnert, and F. Buschmann. Pattern-Oriented Software Architecture, Volume 1: A System of Patterns, volume 1. John Wiley & Sons, 1 edition, 08 1996.