When you open the JITTAC application you will be presented with 4 panels. It looks as follows

To create a new project, simply select the 'component' icon from the 'Palette' panel and drag and drop into the main center panel. Repeat this process for multiple components.

Next, click on the 'Properties' tab located in the panel at the base of the screen 'Name' each of your components as required.

Once you have complete this, select the icon over the 'components' folder, on the right hand side. This will allow you to generate the dependencies you feel exist between your chosen components.

To do this, simple click on your chosen component, drag and drop the the required component destination. You will notice that an arrow now connects from one component to the other, showing the dependency link between them. Do this for all required dependencies. Once completed, re-select the arrow icon located in the same area.

Next, map the source code elements, from the 'Package Explored' panel on the left hand side to the components. This can be a one to one mapping or a one to many to one mapping where many source code projects, packages, classes are mapped onto the one component. To do this simply select the project, package or class from the drop down menu and drag and drop it on the required component in the main center panel.

Notice that the tool provides you with real-time feedback which informs us of where the source code dependencies are, as expected by the architect, and where the source code dependencies are not as expected by the architect.

Arrows with broken lines depict the unexpected dependencies between components. Arrows with solid lines depict the expected dependencies between components.
JITTAC allows the architect to explore these inconsistencies in depth by bringing up the architectural relations view. In order to view this, simply select the ‘Architectural Relations’ tab from the panel at the base of the screen.

This view list the source and target for each dependency and allows the architect navigate to the corresponding line of code. To do this simply make your file selection from under the the ‘Source’ heading. The source code for your chosen selection will be displayed in the main center panel where you can make any necessary amendments to it.
When saved this change is reflected back to the architectural model.

You can also drag a source code project package java file from the 'Package Explorer' panel and use it to create a totally new component in your architectural model.

Simply select, drag and drop the required file from the 'Package Explorer' panel to the main center panel. This will allow you to explore the rest of the systems relationship, i.e. dependencies, to that source code entity.

If a developer wishes to make changes to the system by altering old code or adding new code auto complete will appear. The suggestions offered by autocomplete are re-ranked and color coded. Methods or fields that are accessible and are consistent with the architects model are placed first and colored green, methods and fields that are in software elements and are yet unmapped to the architectural model appear next and are colored amber and finally the methods and entities that can only be accessed in violation of the architects express model are presented last and in red. This gives the developer architectural awareness as he codes i.e. just in time.

If for e.g. a programmer wishes to save work which he know is in violation of the architects design he will be prompted with warnings in the left hand panel reflecting all of inconsistencies introduced. By right clicking on any of the lines of code in question he or she can go back to the architectural view and see the dependency highlighted in the architectural model giving them valuable contextual information on the violation he/she has introduced. They can then click on that edge and through the architectural relations view go back to the code making the navigation full round trip.

At this stage, after checking the context the developer may still be convinced that the dependencies required may be desirable, If so, he has the option of sending an email to the architect by again right clicking on the inconsistent line of code and selecting the option to email the architect. This bring up and email client with a message addressed to the architect, with all the information required to uniquely identify the line of code. Space is also left for the developers rational.

On seeing the email the architect is free to go into JITTAC and explore the consequences of the developers actions and can accept the inconsistency as a valuable addition to the architecture.