I worked with Java Swing for quite some time now. However Swing is said to be dead since a couple of years, it seems that nobody notified some companies about that. I don’t feel a siginificant movement away from Swing. But that doesn’t mean that there will be none in the next years, so it’s wise to be prepared for the next iteration of de-facto-user-interface-standard. After thinking and reading about some promissing candidates, I decided to bring myself up to date with JavaFX. Oracle is pushing the framework massively and the showcase looks impressive. With JavaFX 2.0 it is possible to code the whole user interface (UI) in Java without a special script language. The Scene Builder could be the stepping stone into broad application, just like Netbeans Matisse and Eclipses WindowBuilder has been in some companies. These are steps in the direction of good usability of the framework. Of course JavaFX will clash with “real” web technologies like JavaScript. I cannot predict if the majority of web applications in huge firms like the one I work for will be JavaScript- or Java-based in a couple of years. For me, that is reason enough to take a good look at JavaFX.

Having decided to catch up with JavaFX, I thought about what to code. Like many developers, I used to play games a lot. Open-world games in which the world is developing itself and the player is just a part of it have always fascinated me. So I decided to code one on my own. In my simulation, there should be some natural eco system like growing ressources. These ressources should be used by some developing culture. As you see, my ideas are pretty rough and abstract at this time. I will make up my mind in the process of coding, so don’t expect my decisions to follow a clear path.

The main goal of this exercise is to learn JavaFX and, in the process, do some software engineering. I will document my architecture decisions and think (i.e. blog) about my experiences during development. Hence, this is the first of a series of articles about what I will call “SimFX”. This working title elaborates my plans: An open-world simulation with JavaFX.

First Architecture Decision

According to Stefan Zörner, the architecture of an application is the sum of decisions that can not be taken back easily in the further process of development. The main source of problems in later phases of development are the non-existing documentations about these decisions. It is not enough to stipulate the final decision; the process which led to that decision has to be documented, too. This way, new developers in the team can understand the basic decisions easily and can also comprehend, why certain alternatives weren’t choosen. I agree with Stefans thoughts because I myself have often been asking questions about legacy systems and was answered often enough the famous sentence “This evolved over time”. Of course, this statement has absolutely no value to a newbie.

At this early point, I made one important decisions that I want to document here.

Exchangable UI

As I said, the main goal of this project is to code some JavaFX. Maybe I want to port the application to another UI framework in the future to deepen my understanding of that framework without having to write a whole new business logic. This raises the question how the structure of the application should look like to be able to switch the frontend in the future.

After having defined the problem (“How to structure the application to be able to switch the frontend in the future?”), the limiting factors have to be researched. I already choose to code the business logic in Java and I want to reuse this logic for every new UI. Hence, I can only port to frontends for systems that are capable of running Java, too. This shouldn’t be a problem because my target platforms are most likely PCs that run Windows or Linux. This is the only technical limitation I can think of right now … did I miss something?

The third part of documenting a decision is to write down the assumptions. Concerning the exchangable UI, I assume that UI frameworks are easy to decouple from the business logic. The opposite of this would be a framework that totally controlls the execution path of an application.

I also assume that all frameworks I want to use in the future have different APIs. Hence, there has to be an intermediary part of the application that bridges the gap between my business logic and the API of the UI framework.

The second and last assumption concerns the risks of isolating the business logic from the UI. There sure is the risk that I will never implement another UI, which would render the separation logic and the intermediary part useless. If this becomes reality sometime, this part of the architecture was just a finger exercise.

The fourth part of the decision is thinking about alternatives. The only alternative to isolating the business logic from the UI is not to do so. I simply reject that alternative.

The last step in the documentation is to decide: I hereby decide that there should be some kind of adapter that separates the UI from the business logic. Hence, the overall architecture has to look something like this:

So, what do you think of this project? Are my thoughts concerning the architecture comprehensible?