Using the reference view, for each of the package we would to get a first impression of its main responsibilities. 
Please do not spend more than 5-10 minutes per task.
Please keep track of the questions that you are asking yourself why looking at the view

1. Can you identify the main abstractions/classes of each package? 

Yes.


2. Can you identify how these main classes interact within the package and within the application? 
   Are there classes doing most of the internal/external references? 

Compiler-ParserNode: MessageNode heavily uses other classes from the package, and it is also used by three other classes from the package. (It is strange that Dictionary has a black border, because it should be a stub)

Compiler-Kernel: Parser is the most greedy of all because it uses both many internal and many external classes. Encoder is a class that heavily uses external classes, and it is used by the Parser. Quite a large number of external application classes are used.

Compiler-Test: Just one class that uses Array.

Compiler Support: There is no internal interaction inside the package. DecompilerContructor is the class that uses all sorts of Node classes.


3. How would you qualify the references from MessageNode ? 
   Compare it to MethodNode?
      
(It was difficult to find MethodNode, because I basically needed to hoover around over all classes. If you expect people to look for names, something needs to be done about it. For example, a search box that selects the classes that match the query.)
MessageNode has only references internal to the package, while MethodNode has only external references.


4. Do you identify some misplaced dependencies with packages outside the compiler application?

No.


5. Under the assumption that a package containing classes that are referred to by other packages should be loaded first, can you identify a load order for the application?

Compiler-Kernel should be loaded first. (This is not a very strong question, because this can be easily detected automatically)


6. How would you qualify the cohesion of Compiler-Support?

Everything in this package is about DecompilerConstructor. So, I would say the package is rather single-minded.


7. Using the hierarchical view, what can you say about the shape of the Compiler-ParseNode package?

There is no subclassing. All classes inherit from Object.


8. Can you tel l us something about the ParseNode hierarchy?

It is strange that all these classes inherit from Object. I expected to see stronger inheritance, because I expected at least a common interface for traversing the Nodes to be shared in a common superclass.


9. Do you think that you would have got the answer that you wrote down about the application without the help of visualization?

no.