Fourteen tips
to better your PSPSM [1]
Tip #6
Daniel M. Roy
(President STPP, Inc.
SEI visiting scientist and
transition partner)
Abstract: Fourteen tips are proposed to better use the PSP framework so that
improvement is made easier and PSP is routinely used on the job. Tips for PSP
support tools and about expanding the PSP to small teams are added to make the
transition to Team Software Process (TSP-SM[2])
even smoother.
6. Better your design
If
architects engineered their buildings the way we design computer software, the
first woodpecker that comes along would destroy civilization.
Anonymous.
Most of the PSP exercises benefit from the best possible design: mathematics. This is probably why I so often see even experienced programmers dig into the assignment by “designing on the fly”. Assignment 6A (computing prediction intervals) was designed by Watts to teach a painful lesson and, therefore to motivate students to put into practice the concepts offered in the design and verification lectures of the PSP class.
Design really is “where the rubber meets the sky”. Therefore, you will get a lot of mileage on the job from improving your PSP for design. I once asked Fred Brooks what I should concentrate on teaching with PSP. “Design, teach design!” he said without hesitation. So, this is the way to address the essential complexity of software engineering! [Brooks-87]. On the job, designing is probably the most important activity since fluffy requirements have to be reconciled with real world systems constraints of all sorts such as costs, schedules, performance, functionality, etc.
I often hear gripes about the PSP design templates. Why not use UML I am asked? Why not indeed. What do you think a scenario template is? Of course it’s a UML use case scenario! And since the PSP concerns one individual there is no need for a large Use Case diagram. However, base or reused code (such as 1A, 4A and 5A) can be seen as actors during the design of complex programs such as 6A to do a better conceptual design. Incidentally, Cunningham and Beck’s Class-Responsibility-Collaboration (CRC) cards are a great tool to do this same kind of things on the job. In any case, PSP assignments are so small and the user interface is so trivial that the whole artillery of Use Case and CRCs would be an overkill for them. A must read reference for all this by the way is the marvelous book by Martin Fowler “UML distilled” [Fowler-00].
In my opinion, UML state transition diagrams (Harel’s statecharts) should replace SEI’s ad-hoc graphs that do not even identify the initial state. However, Watts’ state machine template nicely complement STD graphics by adding the rigor of Boolean logic. Unfortunately, PSP assignments are stateless (except for 2A and 3A; 8A with a stretch).
Being typically pure functions, the subprograms of the PSP may appear to not easily lend themselves to a true OOD approach. I do not believe this to be true. When I took the class I made good use of “Booch’O’Grams” (sorry Grady, I know you hate this name. I mean Component Diagrams). I found it to be a good idea to build a hierarchy of math packages to foster reuse between assignments. Figure 6-1 is my entry in UML package diagram format. This notation nicely complements Watts’ templates by offering a high level graphic overview of the static structure of the program. I use it at conceptual design time.
Figure 6-1: Package diagram for 1A
The class data clearly shows that a clear and complete view of the project at conceptual design time is crucial for the estimation of size and effort. In particular, a one liner build plan describing the order in which the components will be developed and assembled is extremely important. This is what is called the implementation strategy in the class. It blossoms as a full fledged activity of high level design with PSP3. A correct strategy for 10A like the one suggested in the PSP3.0 exercise for instance can drastically reduce the effort necessary by making scaffolding software unnecessary.
As for Watts’ Functional Specification Template, I think it adds semantics as well as a welcome rigor to UML class diagrams. A class is an abstraction of a family of things that have a lot in common. For instance, computing sums of product is an extremely common problem in software engineering. We find this in filtering, parametric estimates, costs aggregates, etc. even statistics. A Vectors class offering public methods such as sum of Xi*Yi is quite useful for PSP assignments. It also has the nice property of returning sum of Xi**2 when X=Y. Figure 6-2 shows such a class diagram for 1A.
Figure 6-2: Class diagrams for 1A
The semantics part of the functional specification template is very useful to connect the API static level documentation of the class to its detailed behavior as documented in the logic specification and state specification templates. There are important concepts here, quite similar to the separation of concern offered by package specification and package body in Ada. The functional spec template shows the class/object API and behavior at a high level of abstraction sufficient for the user of the class or one of its instance. Incidentally, this is why I often recommend the functional spec template to those of my customers who have to reverse engineer legacy software. The implementation details laid out in the logic spec template can also be useful for that purpose. One of my customers at the Lawrence Livermore National Laboratory where nuclear weapons are designed once told me that he had found an error in a legacy module by writing its logic spec template and then, simply reviewing it. I did not ask if this error had to do with a nuclear weapon safety software!
Another major concept in software engineering that is embodied in the PSP templates is that of layers of abstraction. Taking the stairs to the upper floor would be either dangerous if the steps were too high or tedious if they were too low. In the same vein, the notation used during the various stages of design and implementation must allow for refinement steps of the optimum size. I found the following hierarchy of design notation useful during the class:
Package diagram -> Class diagram ->
Functional Spec Template -> Logic Spec Template
Beyond PSP, on the job, design is king. In particular, we should all strive to design for reuse if we could not design with reuse. Of course, this calls for an architectural design phase that is not part of PSP (PSP3.0 features an HLD phase but by then, it is too late for the PSP assignments). By architecture, I mean the structure of the network of the software components, their rules of interaction and their data structures. I like Robert Firth’s definition “Architecture is the combination of good engineering with good taste”. For a good practical look at the subject I recommend [Gamma-95].
In any case, we must stop re-inventing the wheel with every project. It is by thinking in terms of domain analysis, architecture, and canonical design that we will marry good engineering with good taste. In other words, it is by becoming lazy that we will finally end the software crisis. Designs and implementations of the highest quality are the major entry criteria for true reuse. That calls for a strict design process including methods, notation, forms, templates, standards and, of course reviews. It all starts with our PSP for design and that is why bettering it should be our highest priority.
Bibliography
[Brooks-87] Frederick Brooks, “No silver bullet, Essence and accident of software engineering”, Computer, July 1987
[Fowler-00] Martin Fowler, “UML distilled, second edition”, Addisson-Wesley, July 2000
[Gamma-95] Eric Gamma et al. “Design Patterns, elements of reusable OO software”, Addison-Wesley, 1995.