Navigation:  Introduction > Framework Design

ClearCanvas Workstation is an open source project.  As you may know, most open source projects fail.  There are many reasons for this.  We won’t get into all of them here, but sufficed to say, one of the reasons is that the barrier to entry can often be prohibitive.  This may be because the application isn’t well designed, or documentation is lacking, or you have to understand a lot about the code before you can even begin to contribute.  To minimize this barrier to entry, the CC Framework was designed with the following goals in mind:

This is quite a tall order to fill.  Framework development, as we have discovered, is remarkably difficult. We invite you to help us determine how well (or how poorly) we’ve met these goals, and how we can improve.  We talk a little bit more about these objectives below.

User Experience

Our experience in clinical settings has shown that software developers are often not the best judges of what makes a good PACS viewer.  We have learned that frequent consultation with users, be they radiologists, technologists or other clinicians, is key to product usability.  More often than not, usability is not measured by the number of bells and whistles a product has, but by the subtleties that developers don’t always notice, like the number of mouse clicks to perform an action or the amount of light coming from a toolbar or menu.  Our hope is that clinical users who experiment with ClearCanvas Workstation will be able to provide developers like us the usability feedback that we require to continually improve the user experience.

Ease of Participation

What is probably most intimidating to a developer who wants to contribute to an open source project is a monolithic code base, a code base that you have to have a good working knowledge of before you can begin to contribute.  To avoid this situation, we decided to implement a plugin architecture.  That is, new functionality can be added dynamically at run time in discrete binary modules that don’t disturb the main code base.  Good examples of a plugin architecture can be found in applications like the Firefox web browser, or the Eclipse integrated development environment for Java (in fact, a number of concepts in the CC Framework are based on the Eclipse model.)

Ease of Use vs. Flexibility

Simple APIs and object models are great, because they’re easy to use.  The downside is that if you want to do something unusual that the API author didn’t intend, it can be very difficult or perhaps even impossible.  Conversely, really flexible APIs that allow you to do just about anything are often difficult to use and out of reach to the less-experienced developer since they often employ a great deal of abstraction and indirection.  To provide the best of both worlds, we’ve chosen a relatively flexible API, but have attempted to hide as much of the complexity as possible by providing easier-to-use interfaces as well as code templates.

Accommodation of Developer Skill Set

Not everyone has experience in the same languages.  Some prefer C++ style languages such as C# or Java.  Others prefer rapid development languages such as VB.  It would be unfortunate if a developer was unable to contribute simply because he/she wasn’t fluent in a particular language.  In part, this is why we have chosen to develop in Microsoft’s .NET environment.  .NET allows developers to write plugins in the .NET language of their choice.

Extensibility

To ensure that we have the flexibility we need, the plugin architecture is such that everything is a plugin and that plugins can extend other plugins.  The executable itself is nothing more than a boot loader that starts up the first plugin.

Performance

With the increasingly large image sets being generated by today’s modalities, the ability for users to view and process all those images efficiently is extremely important.  In the Framework, we've tried to hide these optimizations where appropriate so the developer doesn't have to worry about them.

Model/View Separation

From the very beginning, CC Workstation was designed using what is known as the Model/View/Controller (MVC) pattern.  That is, the domain objects (the Model), the UI representation of those domain objects (the View) and the objects that manipulate the domain objects (the Controller) are all separate.  This approach, combined with the plugin architecture, allows for very modular development.  The separation of the View from Model is particularly important because presentation layers change all the time.  For example, with Windows Vista comes the Windows Presentation Foundation, or WPF.  Ultimately, this will deprecate what we now know as Windows Forms.  If the model and view are too tightly integrated, adding support for WPF would be significantly more difficult.  Fortunately, in the CC Framework, model and view are implemented as separate plugins.  So, in principle, adding support for WPF (or any other UI toolkit) can be done simply by writing another plugin and dropping it in.

Robust DICOM Networking

DICOM support in the framework is now provided by our native .NET toolkit, which we based on the public domain toolkit by Colby Dillion (thanks Colby!).  Previously, we used a combination of an augmented version of Colby Dillion's toolkit and the well-known open source OFFIS DCMTK toolkit by the University of Oldenberg.  Having these great open source libraries to build off of has been invaluable in the development of the native .NET toolkit.