Browse Prior Art Database

Code Repository Access and Administration through Forward and Reverse Engineered model data

IP.com Disclosure Number: IPCOM000030028D
Original Publication Date: 2004-Jul-23
Included in the Prior Art Database: 2004-Jul-23
Document File: 2 page(s) / 30K

Publishing Venue

IBM

Abstract

Proposed is a system for enhancing version control software by leveraging software models. First, the version control software will update the model from source changes automatically and push model changes into the repository using code generation. Second, the version control software will allow an administrator to tie access control lists to model artifacts, providing a layer of abstraction to the real source artifacts..

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

Code Repository Access and Administration through Forward and Reverse Engineered model data

Currently, in large technology projects, there is need to provide and maintain documentation for the technology code that speaks to a level above code comments and api doc. These documents provide a system-view of what the technology plans to accomplish in the form of block diagrams and interfaces. Sometimes this documentation is related to, or kept as, a formal model. This is useful because it provides a canonical representation of some of the relationships between code artifacts and the general flow of the technological process. This form of documentation can be very necessary, because it facilitates parallel development efforts: Product A can be dependent upon Product B, but can start development before Product B is finished or really close to finished.

This documentation often changes as the product is being developed. Implementation details create changes to the overall architecture which cause updates to the high-level documentation. The problem is that Product A needs to know immediately how things have changed with Product B, so that they can keep in synch. In addition, Product B may discover that they have a need for Product A to do something differently. Both of these issues of change management are generally handled by having english-language documentation that is maintained in parallel to the code, and usually lagging behind it. Oftentimes, this documentation is inaccurate or just wildly out of date.

There is also the issue that, oftentimes, changes are made to the high-level structure without that being the intention. This is problematic, because the high-level documentation becomes unreliable. There is currently not a direct way of inhibiting changes to the model at the source repository level.

We propose that model of the code is maintained in the repository, without it merely being a file in the repository. The repository would maintain the relationship between the model and the code. In this fashion, pieces of the model could be declared as inviolable "API" elements, and would block developers from committing changes to the code that changed these APIs, while still allowing them to change the architecture of areas that were declared malleable. Similarly, the repository would alert developers when they were affecting a change to the model with a code check-in. In addition, the model would be updated by this type of check-in, or the check-in could be moderated because it was changing the model. This would allow for more...