Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Ian Roughley on Jun 17, 2010
Architexa is a new Eclipse-based UML modeling tool that allows developers to quickly gain insight into code relationships through UML diagrams, and share what they find with others. The key to fast exploration of the code base is to provide 3 farmiliar diagram types to developers (layered, class and sequence diagram) and allow developers to build up the relationships and granularity as they explore and understanc the code base.
InfoQ recently spoke with Vineet Sinha, founder of Architexa, to find more out about the tool and how it can help developers work with ever-expanding code bases.
How does Architexa help developers where other UML tools are lacking?
We are focusing on coding needs as opposed to design needs. We therefore want to allow developers to easily understand code, and help them in tasks related to that understanding - in documenting what they have understood and in easily discussing those important code concepts with other developers that they are working on.
Layered diagrams are a powerful way to initially explore a code base. Could you explain them to our readers a little? Did the idea come from existing work, or did you evolve the concept and how?
Layered Diagrams in Architexa try to create the closest possible estimation to a Layered Architectural Diagram given your current codebase. We noticed that most Layered Architectural Diagrams are the main form of high-level diagrams used by teams on a project - and that they are often not easy to find on many codebases. Given that having such diagrams can help developers find parts of the codebase that they are most interested in, we wanted to provide a quick version of such diagrams for developers needs.
Architexa builds the Layered Architectural Diagrams by analyzing your code and trying to show modules, in such a way that a module is shown higher in a diagram if it depends on another module. Beyond this, we need to make guesses - modules are basically created by default based on the folder structure of a codebase. Further, most codebases often have cycles, and we have added sophisticated algorithms to work with such cycles but still provide effective layered diagrams.
Most of the tool suite was experimented and built during my PhD at MIT (CSAIL). Given that we tried to be thorough in building a good tool. The primary idea came from multiple sources - I spent a significant amount of time on (i) going through software documentation on multiple projects to see common properties, (ii) analyzing current tools that provided effective code views - while these mostly were very sophisticated and required training they did have a number of strengths and we were able to see the common patterns of usages of such tools so that we could simplify with few clicks, (iii) typical tree widgets which often show alot of information neatly collapsed for a user, and (iv) a wide variety of good tools to find techniques worth adopting in our diagrams.
Once we built the first prototype, we found a number of problems. Most of our major ideas worked but we realized real world problems (code often having cycles) and we developed techniques to not only address them (by layering ignoring some code cycles), but also to make it easier for users in such situations to easily work with them (to allow users to expand based on dependencies in such cycles, and to use color highlighting to show the modules that build on, are built using, and have cycle to the current module).
Architexa allows you to start from a blank slate of knowing nothing about the code base, and explore. Have you found usage patterns that you tend to use when exploring code bases? How do you use the tool in your day-to-day development/design?
We have found a number of usage pattens, and are actively investigating these to make the tool better. But most of the usage is dependent on the users task:
Is there a way to compare an existing diagram with a code base that has changed?
The use of diagrams when a code base has changes has a number of interesting possibilities. We support two use cases:
We are investigating to add more support here.
Manually generating diagram is a good way to explore the code base, but being able to automatically generate them during a build (similar to JavaDoc) can portrait the evolution of a system. Is this something that Architexa can also do?
Important diagrams often span multiple classes, and each important class often spans multiple diagrams, so putting them in JavaDoc does not make sense. We instead allow users to quickly just upload diagrams to a simple wiki-like server that we have. It allows you to not only share the pictures for those that want to see the diagrams using a web browsers but also allow us to include extra information so that others users with the Architexa client can easily continue the exploration that might have been made by some other author. These diagrams represent the important concepts in a codebase, and therefore have support not only for users commenting on them, but also for embedding them in different places, and are also versioned to show the evolution of the main concepts. We are investigating to add more support here.
What languages does the tool currently support?
This release includes Java support only. We have prototypes for C++.
Can the tool help illustrate components as well as core class interactions (i.e. MVC / web framework interactions)?
Yes. The goal for the suite is to show any relationship that is either explicitly in the code (method calls, inheritance, etc) or done so at runtime (calls to interfaces or base classes). We do this by using the static relationships, but allowing users to change the diagram in any way that might be implied based on the code.
Can you share any features that didn't make that first release, but will be coming soon, that readers may be interested in?
We have a large number of features in this release. While we do have more available for release, our main goal right now is to listen to what users think about what we have done and to fill the biggest holes.
For more information, visit the Architexa website at http://www.architexa.com.
The WebSphere Liberty Profile for Developers: An Introduction
Troubleshoot Java/.NET performance while getting full visibility in production
Early Access! Download JBoss Developer Studio 5.0 now, with packages for Mac, Windows or Linux!
Introducing SQLFire: a memory-optimized, high performance SQL database
VMware vFabric SQLFire - Test drive the data management system with memory speed, horizontal scalability and a familiar SQL interface
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
Andrew Watson talks about the work of the OMG, where CORBA is alive and well (hint: in your car), UML and UML Profiles vs. custom Modeling languages, DDS and other middleware, and much more.
Sohil Shah discusses creating iPhone and Android enterprise mobile applications based on cloud services using the open source platform OpenMobster.
Paul Sanford presents the transformations supported by data throughout its life cycle, and how that can be better done with Splunk, an engine for monitoring and analyzing machine-generated data.
A common “best practice” for unit tests is to only write a one assertion in each test. I intend to question this advice by showing that multiple assertions per test are both necessary and beneficial.
John Rauser presents the architectural and technological evolution of Amazon retail websites starting with 1994 and ending with adopting Amazon Web Services.
Michael Stal discusses system architecture quality, how to avoid architectural erosion, how to deal with refactoring, and design principles for architecture evolution.
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
No comments
Watch Thread Reply