Codecharts: Roadmaps and blueprints for object-oriented programs

Chapter 7

Modelling Large Programs

The Feynman–Tufte Principle: A visual display of data should be simple enough to fit on the side of a van.

—Shermer, 2005

Chapter 6 was concerned with modelling individual classes and methods, their properties, and relations between them. This chapter focuses on modelling programs that are too large to be modelled in this manner. As the size of programs increases, so grows the need for abstraction and scalability (p. 12). This chapter focuses on the challenge of providing abstraction mechanisms that are sufficiently potent, expressive, and informative for modelling large programs without cluttering our diagrams with too many symbols. The symbols introduced in this chapter, listed in Legend 8 on page 72, are tailored to meet this challenge.

A 1-dimensional class constant may represent any (finite, nonempty) set of classes. For example, as the most radical abstraction of package java.util, the entire set of classes and interfaces in this package can be modelled using one 1-dimensional class constant, as depicted in Codechart 38. When modelling any program it is imperative to use an appropriate level of abstraction. Codechart 38a, for example, is too abstract if the problem was to model Java collections and their respective iterators, but it does serve as a good starting point for (semi) automated design recovery tools [Gasparis 2009]. Therefore we demonstrate below how same package can be modelled at different levels of abstraction, starting from ...