January 20, 2008 – 4:06 pm
Object-oriented software processes involve four basic stages, which occur over and over again in an iterative cycle: inception, elaboration, implementation, and transition. For the layman this means think-it, design-it, create-it, and deploy-it. You may wonder where testing comes in; the answer is that testing is performed during the entire process. The goal of any object-oriented software process is to build extensible systems efficiently using reusable components.
Where does OO process fit into web development?
Usually on the server-side. There are many languages and platforms which facilitate the OO process. Java and JSP, C# and ASP, etc… . These languages rely heavily on server components to dynamically render HTML. This is great for applications which require a lot of server feedback. What about a website which simply lets the client do something interactive without a lot of server feedback?
Choose your weapon…
There are two primary methods of creating client-side Rich Internet Applications, Javascript and Flash.
If you choose Javascript you must then choose between a variety of often conflicting libraries or you must implement everything on your own.
If you choose Flash you must then choose a version of the authoring program which meets the budget and licensing constraints of the project.
Will these frameworks enforce OO practices and foster reuse of code?
These frameworks are not restrictive enough to guarantee that code you produce will work with code someone else produces, even code written in the same framework. Flash allows the developer to package code for distribution, but Javascript does not enforce a single distribution paradigm nor any type of contract between library developers and library users. What you end up with is a large variety of independently created libraries, very few of which work together.
For example, there are Javascript libraries designed to be used programtically, and there are Javascript libraries designed to interact with pre-created DOM nodes with particular attributes (such as a unique “id”). Toolkits such as Dojo often employ both techniques. A Javascript library designed to interact with pre-created DOM nodes may not be easily adapted for programmatic use, or it may. Large Javascript libraries such as Dojo don’t often work with other third-party libraries. Dojo 0.4 doesn’t work with Dojo 1.0, though many components have updated versions. There are many guides to help ease migration from Dojo 0.4 to Dojo 1.0.
Imagine if Java 1.6 forced developers to rewrite old libraries for compatibility.
Distributing libraries in Javascript is difficult because Javascript does not enforce namespacing and scoping. It doesn’t even require that an attribute or method exist as a member of a class. There is simply no way to guarantee that your code will not conflict with or corrupt code imported from third-party libraries. Even worse, if the library does work there is no explicit contract to guide your usage of the library because Javascript doesn’t support types, interfaces or classes. Documentation is often sparse or non-existent, and even when good documentation is made it must be written in a separate place or a third-party program must be used to scrape for inline documentation, creating a wide variety of documentation formats.
So what do I do?
You must pick and choose the right tools for the job. You’ll need a set of libraries which provide the functionality you’ll need and that have been shown to work together. You’ll need a utility to scrape the code for inline documentation or you’ll need to write your documentation elsewhere. You’ll need to work closely with your co-workers to ensure that your methods and objects will work together. You may wish to find another utility for performing unit tests.
So let’s just bring it all together.
When we were designing Milescript, we wanted a framework which provided a class based inheritance structure and enforced namespacing and scoping at compile-time rather than at runtime. We chose the Java structure for its simplicity and widely accepted syntax and semantics. We also wanted a static-typing system to enforce contracts between code suppliers and code users. We wanted to be able to easily specify interfaces for working with existing code bases, rather than having to implement adapter classes which create unneeded overhead. Most importantly, we wanted the entire tool-chain to be integrated, ensuring that my libraries, tests and documentation will be usable by others without compatibility concerns. Backwards compatibility is inherent in the design which ensures that my libraries will never become obsolete.
Milescript has several deployment options.
I can deploy my code as a library, and it will create an indexed archive file dubbed a “mar.” These libraries have been compiled in order to guarantee their interoperability with other Milescript libraries. Naming and scoping schemes are used to avoid conflicts, and condensed names are mapped to their original names in meta-data files stored in the “mar” but not served to the client. This ensures that my library will be reusable by myself and by others (even those using legacy Javascript).
I can deploy my code as a statically-linked application and the Milescript Compiler will build a Javascript file which consolidates all used code from all imported libraries. If I didn’t use a particular widget or class, then it is not included. I do not have to use a separate utility or a separate process to build my production code. Applications could be as small as a few kilobytes or as large as a few megabytes.
Back to Object-oriented Process
So now let’s revisit creating a client-side Rich Internet Application using an Object-oriented process, but this time let’s use Milescript.
Our analysts will create specifications, our developers will implement them and the testers will, well test.
Here I show the four stages and some tasks to be performed by each role during each phase.
The specifications can be easily adapted to Milescript “interfaces” by the developers. This ensures that the contracts between code suppliers and code users are guaranteed to be met.
The testers develop unit tests which ensure that the output of each method or function agrees with the specifications produced by the analysts.
During the Transition phase, all of the specifications and implemented packages are compiled into a library and the documentation and unit test artifacts are packaged for reuse.
Later the libraries, documentation and units tests can be brought together to create statically-linked applications which include only the needed components.
Here’s a brief look at how the Milescript artifacts interact.
Due to the static-typing and Java-style class and package structure, the Milescript Compiler is able to create a distributable format that guarantees interoperability with other Milescript libraries. It also provides a host of other tools such as code condensation and logging, but that will all be covered in another article.
For now, we have seen that the Milescript Compiler enforces the principles and practices required to adhere to an Object-Oriented Process.
Posted in Milescript, Point5u | No Comments »