Next Generation Tools for Object-Oriented Development
Goldman, Sachs & Co
Summary: The file has been the central container of work in software development for over thirty years. All of a project's structure and logic is ultimately reduced down to files and directories. The tools that surround software development are built around this concept, too. This article explores the concept of file structure, and contrasts it with an emerging view of Model Driven Architecture. (5 printed pages)
The file has been the central container of work in software development for over thirty years. All of a project's structure and logic is ultimately reduced down to files and directories. The tools that surround software development are built around this concept, too; compilers, linkers, and even language features rely on source code files as input. Version control systems mirror the file system's structure, maintaining a copy of every version of each file monitored. For decades this has been acceptable and has even become standard. Languages such as C are built upon file references in the source code via include directives.
In the mid-1990s, the idea of Object- Oriented development finally began to gain momentum. Languages like C++, once formerly constrained to small research projects, now became the mainstream. With this fundamental shift, the file-based system of development was dragged along as a relic of old. C++, like its predecessor, also uses file includes to resolve dependencies. Despite new techniques and languages for modeling and designing software, such as UML, in the end source files still needed to be created and linked to each other.
This linkage leads to a duplication of effort as models must then be translated into files and source code. Complex build scripts must also be written to ensure the proper building of the application. Should a model change, the source needs to be updated to reflect the change; conversely, should the source code change, the models need to be updated.
A number of different software solutions have been created to smooth the synchronization of these disparate files, but they're still developed under the fundamental notion that the file is the central unit of output. The file also proves to be a difficult challenge when working in a team environment. If multiple developers check a file out from source control, then the version control system must ensure that conflicting changes do not occur. If they do occur, then manual intervention is required to resolve the differences. The source control systems are limited since they rely on the file as the unit to control. The source control systems are completely unaware of the language structure contained within the file.
It seems clear that the file is a relic that has outlived its usefulness for software development.
In late 2001, a new methodology for software development began to emerge: model driven architecture (MDA). The fundamental principal behind MDA is that the model, not the code, should be the central focus.
Platform independent models are created in UML and then undergo various levels of transformation to eventually wind up as source code for a specific platform. It stands to reason then, that the model, not the file, should become the new unit of output. A model has many different views at different levels of abstraction. At the highest level, platform independent components can be specified in analysis; at the lowest level there is a platform specific implementation that reduces to a set of classes in code.
The available modeling notation allows for the definition of all necessary features needed to replace files; specifically, dependencies between classes can easily be marked by means of an association arrow with a dependency stereotype. Tools that support the creation of models should ideally allow for version control on each individual model element. Each element should have the ability to be checked in and out of a repository.
Similarly, the modeling tool should work with the repository to provide branching and merging support at the element level. For example, a developer should be able to connect to the repository and obtain a list of elements that meet a given need. The developer should then be able to branch the repository element for inclusion in a new model. At a later date, another developer might wish to reconcile differences between branched elements in different models. The development environment should support this.
One common example of when this functionality is needed is for bug fixes. If a bug in a model element is fixed in one project, then other projects that are using the same model element might wish to incorporate those changes; this should be an easy task to accomplish.
The solution to these problems is nothing short of a complete paradigm shift. The development tools must support the shift that languages have already made and fully support MDA development.
It is easy to argue that the source code is, in reality, just another model. The argument is exemplified by the existence of a language-independent Code Document Object Model (CodeDOM). When you get down to the basics, the source code and the UML classes are simply different views of the same underlying data. Any separation between them is an artificial construct that needs to be eliminated. A developer should be able to create classes as UML, complete with methods and attributes, and toggle between the UML and the source code. The source code should be available in many different languages—simultaneously.
This is largely possible today with CodeDOM, which is essentially an object-oriented metamodel that can be easily mapped to UML. The code structure is easily portable between most .NET compatible languages and the tools should support this. One artifact that must be eliminated is the source code file. It serves no function in MDA that cannot be better done by different means.
In place of source files, an IDE would instead connect directly to a project repository. The project would then list the objects directly, bypassing the need for files. This new functionality would work similarly to the "Class View" currently available in Visual Studio. The view would be organized by nested namespaces rather than directories and by classes, structs, and resources instead of files. When a developer double-clicks the class, the code is opened in the editor.
The Class View would also contain UML diagrams. A diagram would be able to be created at any place in the hierarchy, and the developer should be able to drag the classes onto the designer surface. Each namespace would have a default diagram and any number of supplementary diagrams showing different parts of the system. The tool would have a graphical view of the classes and their relationships in addition to a code view. Ideally, the code should not be stored in any single language; it should be stored as a model with additional CodeDOM structures.
Minor additions to the CodeDOM classes could enable the representation of all language features, eliminating the need for languagespecific code snippets. Each method in the model can contain languageindependent CodeDOM constructs which can then be translated into any supported language for easy editing. Just like there can be a split-view of design and HTML view in FrontPage, a development environment should provide a split-view of model and code.
When file-based development is replaced with model-based development, a new world of possibilities is opened. Rather than designing websites by creating web pages directly, Activity Diagrams can be constructed to model the user's interaction with the site. Upon compilation, the tools would generate the necessary output files to support the diagrams. Each activity on the diagram that requires a user interface would contain a UI design. For example, for any given activity, a web UI design and Windows UI design could be a part of the activity. The tools could allow the import/export of HTML files to allow designers the ability to use their own tools rather than the default IDE. After a designer is done, the HTML file would then be imported back into the activity.
This whole concept falls squarely in line with the new "Whitehorse" technologies Microsoft is including in Visual Studio 2005. Visual Studio 2005 will include support for Microsoft's Dynamic Systems Initiative (DSI) by providing a tool able to create a System Definition Model (SDM) linking components to hardware. Whitehorse includes a set of new designers in support of MDA called Software Factories [JG04]; a UML-like class designer is available for source code and logical application and infrastructure and designers allow developers to declare the application component structure, configuration and deployment settings early on in the design process. Like code files are now, these models are currently stored as files within the solution. All models should be stored within the repository directly with APIs created to access the models from the repository.
The source control system should also be cognizant of the inherent structure present in the model and code. It should support the check-in and checkout of model elements down to the function level. That way, two developers could work on different parts of a class without the potential for later reconciliation. The build tools also need to support this new environment. Rather than compile files, what they really need to do is compile a model. By way of a deployment model, classes would be associated with assemblies and executables. The compilers would look to the deployment model to determine the physical separation of the project's classes and resources, and to the class dependencies to resolve symbols. The build process would output many different files depending on needs; for a web project, the ASPX or ASMX pages would be created alongside the binary assemblies.
The build process would also read the SDM and generate the appropriate setup files and export the SDM for import into a deployment tool. For compatibility purposes, the tools should allow for the extraction and import of source code files in any supported language. A developer could select a given set of classes to export and the tool would generate the required files. A developer could then modify the files and then import them back into the project. The tool would automatically create the model elements and prompt for reconciliation changes if needed.
The modern development environment has not yet fully caught up to the object-oriented shift. All of the tools still rely on a file to be the container of source code. While some contain modeling capabilities as well, the models exist as different entities than the file and its code.
The tools need to evolve to support modern software development; they need to merge the model view and the code view into a single entity. While this may seem like a radical shift, and it is, the new tools will be natural to developers. Developers already expect their classes to be organized by namespace; they do not really care about which file or directory contains what code. If a developer changes a method signature, then he will want, and expect, to find all references to the method to fix them. Architects already construct models of software and systems so they can understand them.
[JG04] Jack Greenfield, The Case for Software Factories, JOURNAL3: Microsoft Architects Journal, Issue 3, July 2004.
Goldman, Sachs & Co
Oren Novotny is a software developer with Goldman, Sachs & Co with an interest in all technical things. Previously he was a solutions architect with Unisys Corporation. Oren is also a freelance consultant frequently helping in various open source projects.
This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal website.